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.
|
|