Estimation Considerations: Component Model
This guidance discusses estimation considerations for component modeling.
Relationships
Main Description

Here are the main factors to consider when estimating how long it takes to develop a component model:

  • How many scenarios are there for system use and what is their complexity?
  • How many business rules are there and what is their complexity?
  • How many non-functional requirements are there?
  • What is the level of knowledge of the staff involved? Have they done this kind of work before?
  • Is there any intellectual capital that can be reused? This includes both documentation and exiting components.
  • Are there any existing reference architectures or frameworks that can be utilized?
  • What modeling tools are available?
  • How many existing packages/components must be integrated with your system? Do these packages/components have well defined and well documented interfaces?
  • To what level of completion do you plan to develop the Component Model? Do you plan to maintain it throughout the subsequent life of the project?

The table below gives some estimating guidelines for building a component model.

These guidelines assume the following:

1. Approximately 50 well documented scenarios for system use, or use cases. If your requirements are not in use case format, add time to read the functional requirements and formulate scenarios for system use. 

2. Each use case has an average of 8 steps; half the steps have one alternative.

3. An Enterprise level modeling tool is available that supports UML and allows multiple users to work on it.  A tool has a large impact on the effort involved. Developing a component model is not just a matter of creating a few pictures with a drawing tool; it can be quite complex and time-consuming. A multi-user UML modeling tool with configuration management capabilities greatly reduces the effort.

4. All architectural artifacts (business rules, requirements, components and interfaces) are organized with unique identifiers. Identifiers allow you to make references between these artifacts without having to retype information.

Step

Estimating Considerations

Identifying candidate components

Allow one day to review the input work products and define an initial set of components.

Partitioning

Plan half a day to one day to understand the business processes.

Allow one day to read the requirements and identify the architecturally significant ones.

For each architecturally significant use case, allow half a day to draw an initial component interaction diagram. 

Structuring

Allow half a day per use case to document the responsibilities of each component and identify any new components.

Allow one day to review all non-functional requirements and associate them with components

Layering

Allow half to one day to assign components to layers using a modeling tool.

Defining component interfaces

For each component, allow half a day to draw out the interfaces and specify the operation signatures. Allow a total of another two days to associate these interfaces with core types. This estimate includes verifying that all operations are capable of supporting the data types.

Assigning business rules to components

Allow one hour per business rule to specify which component(s) should handle that rule.

Specifying components

For each component, allow half a day to specify the component and all its interfaces with enough detail to begin design.

Putting it all together

Putting the architecture documentation into a readable form involves:
- Extracting the relevant diagrams from the modeling tool
- Writing additional supporting text
- Laying out the document and setting up cross references

Allow 5-10 days for this activity, depending on the number of components and the required quality of the finished document.