What is your definition of a 'Component' in a software Product?

Question

We are working on standardizing our Bugzilla application across all projects. The default installation has bugs grouped into Products which have Components and Versions.

We are united in our definitions of Product and Version but there is still some confusion/discussion/argument about what constitutes a Component.

How would you define a Component as far as it relates to classifying bugs in a project?

Answer 1

For bug tracking purposes, I would use Component to represent high-level areas that different developers tend to handle. For me, Component [in bug tracking] == Area of Concern.

For example, for a fictional EventPlanner application, I would list my components as:

• Calendar
• User Interface
• Printing

Note that this may be different than what I, as a developer, would typically consider a software component. For example, my EventPlanner app might have use Calendar API, but "User Interface" and "Printing" themselves are not software components.

Answer 2

A component is a subdivision of a product and it provides a subset of the functionality of the product.

For example, if Stack Overflow is the product here are some potential components:

• Questions
• Tags
• Badges
• Profiles

A bit of glue logic should piece the components together to form the project.

Answer 3

I would define Component similar to referencing a branch of code like a project within Visual Studio which could be a class library, console application, windows application, or website/web application.

Answer 4

A good definition that will serve your purpose.

Answer 5

Anything that's a "helper" object, something that does something small to support the larger functionality of the application, and can be reused in other Products.

For example, an EmailSender class, or an ErrorLogger, etc.

Answer 6

Whatever it is you're most interested in breaking down your Products into for purposes of bug tracking. It's more important that the distinction is useful to you than it be "correct" according to some concept that's not specific to the problem of bug tracking.

To me, any part of the code for which you can change the implementation without breaking other parts could qualify as a component. Something you can definitively point to and say, "This bug is there, and nowhere else."

If your product is a giant spaghetti code ball, you might not get any benefit from components. If you've decoupled very well, and you have a very large project, you might have hundreds of things that could qualify as "components", and you'll probably have to semantically group them to prevent the distinction from being more trouble than it's worth.

EDIT: In response to a comment on another answer, this model works best if the person filing the bugs has the necessary knowledge of the problem to do the filing. We always review (triage) reported bugs and file them ourselves. If you're leaving component selection up to the users, this idea won't work very well for you.

Answer 7

Dr. A. Richard Newton from the University of Berkeley who teaches a course called "Component-Based SoftwareState-of-the-Art and Lessons Learned" defines a software component as

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties

I dont think there is a better definition. So bug here could be at component level or at interface level i.e. composition level.