Starting UML
As mentioned in the introduction, UML has four pro
ject phases:
* Inception Phase - Approximately 20% of requi rements determined.
* Elaboration Phase - Approximately 80% of requirements determined.
* Construction Phase
* Transition Phase
These phases and what I perceive should be done in each of them are described here.
Inception Phase
This is the part of the project where the original idea is developed. The amount of work done here is dependent on how formal project planning is done in your organization and the size of the project. During this part of the project some technical risk may be partially evaluated and/or eliminated. This may be done by using a few throw away prototypes to test for technical feasability of specific system functions. Normally this phase would take between two to six weeks for large projects and may be only a few days for smaller projects. The following should be done during this phase:
1. Project idea is developed.
2. Assess the capablilities of any current system that provides similar functionality to the new project even if the current system is a manual system. This will help determine cost savings that the new system can provide.
3. Utilize as many users and potential users as possible along with technical staff, customers, and management to determine desired system features, functional capabilities, and performance requirements. Analyze the scope of the proposed system.
4. Identify feature and functional priorities along with preliminary risk assessment of each system feature or function.
5. Identify systems and people the system will interact with.
6. For large systems, break the system down into subsystems if possible.
7. Identify all major use cases and describe significant use cases. No need to make expanded use cases at this time. This is just to help identify and present system functionality.
8. Develop a throw away prototype of the system with breadth and not depth. This prototype will address some of the greatest technical risks. The time to develop this prototype should be specifically limited. For a project that will take about one year, the prototype should take one month.
9. Present a business case for the project (white paper) identifying rough cost and value of the project. The white paper is optional for smaller projects. Define goals, estimate risks, and resources required to complete the project.
10. Set up some major project milestones (mainly for the elaboration phase). A rough estimate of the overall project size is made.
11. Preliminary determination of iterations and requirements for each iteration. This outlines system functions and features to be included in each iteration. Keep in mind that this plan will likely be changes as risks are further assessed and more requirements are determined.
12. Management Approval for a more serious evaluation of the project.
This phase is done once the business case is presented with major milestones determined (not cast in stone yet) and management approves the plan. At this point the following should be complete:
* Business case (if required) with risk assessment.
* Preliminary project plan with preliminary iterations planned.
* Core project requirements are defined on paper.
* Major use cases are defined.
The inception phase has only one iteration. All other phases may have multiple iterations.
Elaboration Phase
The primary purpose of this phase is to complete the most essential parts of the project that are high risk and plan the construction phase. This is the part of the project where technical risk is fully evaluated and/or eliminated by building the highest risk parts of the project. During this phase personnel requirements should be more accurately determined along with estimated man hours to complete the project. The complete cost and time frame of the project is more firmly determined. During this phase how the system will work must be considered. Use cases will help identify risks. Steps to take during this phase:
1. Complete project plan with construction iterations planned with requirements for each iteration.
2. 80% of use cases are completed. Significant use cases are described in detail.
3. The project domain model is defined. (Don't get bogged down)
4. Rank use cases by priority and risk. Do the highest priority and highest risk use cases first. Items that may be high risk:
* Overall system architecture especially when dealing with communication between subsystems.
* Team structure.
* Anything not done before or used before such as a new programming language, or using the unified/iterative process for the first time.
5. Begin design and development of the riskiest and highest priority use cases. There will be an iteration for each high risk and priority use case.
6. Plan the iterations for the construction phase. This involves choosing the length of the iterations and deciding which use cases or parts of use cases will be implemented during each iteration. Develop the higher priority and risk use cases during the first iterations in the construction phase.
As was done on a preliminary level in the previous phase, the value (priority) of use cases and their respective risks must be more fully assessed in this phase. This may be done be either assigning an number to each use case for both value and risk. or categorize them by high, medium, or low value and risk. Time required for each use case should be estimated to the man week. Do the highest priority and highest risk use cases first.
Requirements to be completed for this phase include:
* Description of the software architecture. Therefore most use cases should be done, activity diagrams, state charts, system sequence diagrams, and the domain model should be mostly complete.
* A prototype that overcomes the greatest project technical risk and has minimal high priority functionality.
* Complete project plan.
* Development plan.
There may be an elaboration phase for each high risk use case.
This is the point at which I believe many of the steps in the Unified Process become vague. Considering the various diagrams and charts to be created, when they are created, and the best order to create them in, there seems to be a variety of opinions. I believe this is because in the real world there may be more than one correct solution and there are no hard and fast rules that work everytime. In a way, this flexibility is a strength of UML. Some documentation indicates that most use cases should be done before creating a domain model and others indicate that the domain model can be built on a use case by use case basis. A good compromise is to spend a short time on a brief domain model during the elaboration phase, then enhance the domain model as each use case is developed during the elaboration and construction phase iterations. Some documentation indicates that activity diagrams and class diagrams should be complete before the domain model is done. It is possible to create some of the diagrams and charts (artifacts) in parallel with each other. I'm not sure there is really any correct best way to do this, but I favor the following order.
1. Completion of 80% of use case diagrams.
2. Completion of 80% of high level use case diagrams.
3. Completion of expanded use case diagrams for major use cases only.
4. System sequence diagrams for major use cases.
5. Domain model (Don't get bogged down here with details). Just get a good idea of concepts involved. Use use cases to create the domain model. Any use case that strongly impacts the domain model should be considered and concepts from that use case should be incorporated in the domain model. The initial domain model may be drawn without lines and attributes to avoid too much detail and determine important use cases. The domain model may be refined later as the project analysis continues. If the system is large, domain models should be done on a per use case basis.
6. Optionally create a glossary of terms for concepts to improve team communication.
After this point the design part of the project begins (although more analysis is done for each use case) and the following will be done in each iteration of the elaboration and construction phases.
1. Operation contracts based on domain model and use cases.
2. Collaboration diagrams.
3. Class diagrams.
4. Map class and collaboration diagrams to code.
5. Update the domain model but do not force it to the class diagrams.
Considerations during this project should be the following:
* Consider possible significant changes (down the road) to the system during analysis.
* Regarding system functional ability what do you expect to be able to change?
Construction Phase
Construction iterations are based on use cases. Small use cases may be done in one iteration or a larger use case may be worked on in sections. For each iteration, analysis, design, and creation of software is performed for each use case in that iteration. As I understand the process, the following would be done for each construction iteration per use case. Again, much documentation indicates that the domain model (conceptual model) should be done for each construction iteration and be based on use cases being implemented during that specific iteration. The following should be done during the construction iterations:
1. Completion of expanded use case diagrams for use cases.
2. System sequence diagrams for major use cases.
3. Operation contracts based on domain model and use cases.
4. Collaboration diagrams.
5. Class diagrams.
6. Map class and collaboration diagrams to code.
7. Update the domain model but do not force it to the class diagrams.
It is worth performing tests to be sure each use case works properly at the end of the iteration. At the end of the construction phase there is a product that users can use. The following will be complete:
* Users manuals.
* Release version and description.
Transition Phase
During this phase, the finished product is brought to the user. Items to be addressed in this phase include:
* Final program debugging
* Code Optimization
* Beta testing
* Completion of manuals.
* User training
* Possible operation in parallel with an existing system.
Iterations
Iterations mostly occur in the elaboration and construction phases, but may occur in any phase.
As iterations progress, integration of the various iterations into each other should constantly be done so integration is not left at the end of the project. Each iteration should be complete at the scheduled time. If time becomes a problem, some use cases may need to be moved to other iterations. The plan may need to be changed every two to three iterations especially if you are finding out that many use cases are being moved to later iterations.
Testing
During the construction phase unit and integration testing will be done. At the end of the construction phase, system testing is done. Unit testing is based on use cases and tests to be sure the system can perform the use case functions. Integration testing ensures that the various construction iterations (based on use cases) can interface with each other.
Common Pitfalls to the Process
* Domain models are static (not behavior oriented).
* Domain models are an analysis artifact (not design) - Once the first domain model is constructed, when the second iteration is done, modify the original domain model rather than imposing design class diagrams on the domain model.
* Design is responsibility driven (not speculative) - Conciously use GRASP patterns.
* Not following the basics with GRASP patterns.
* Not recognizing the 20% of exceptions to GRASP patterns where design patterns should be used.
As mentioned in the introduction, UML has four pro
ject phases:
* Inception Phase - Approximately 20% of requi rements determined.
* Elaboration Phase - Approximately 80% of requirements determined.
* Construction Phase
* Transition Phase
These phases and what I perceive should be done in each of them are described here.
Inception Phase
This is the part of the project where the original idea is developed. The amount of work done here is dependent on how formal project planning is done in your organization and the size of the project. During this part of the project some technical risk may be partially evaluated and/or eliminated. This may be done by using a few throw away prototypes to test for technical feasability of specific system functions. Normally this phase would take between two to six weeks for large projects and may be only a few days for smaller projects. The following should be done during this phase:
1. Project idea is developed.
2. Assess the capablilities of any current system that provides similar functionality to the new project even if the current system is a manual system. This will help determine cost savings that the new system can provide.
3. Utilize as many users and potential users as possible along with technical staff, customers, and management to determine desired system features, functional capabilities, and performance requirements. Analyze the scope of the proposed system.
4. Identify feature and functional priorities along with preliminary risk assessment of each system feature or function.
5. Identify systems and people the system will interact with.
6. For large systems, break the system down into subsystems if possible.
7. Identify all major use cases and describe significant use cases. No need to make expanded use cases at this time. This is just to help identify and present system functionality.
8. Develop a throw away prototype of the system with breadth and not depth. This prototype will address some of the greatest technical risks. The time to develop this prototype should be specifically limited. For a project that will take about one year, the prototype should take one month.
9. Present a business case for the project (white paper) identifying rough cost and value of the project. The white paper is optional for smaller projects. Define goals, estimate risks, and resources required to complete the project.
10. Set up some major project milestones (mainly for the elaboration phase). A rough estimate of the overall project size is made.
11. Preliminary determination of iterations and requirements for each iteration. This outlines system functions and features to be included in each iteration. Keep in mind that this plan will likely be changes as risks are further assessed and more requirements are determined.
12. Management Approval for a more serious evaluation of the project.
This phase is done once the business case is presented with major milestones determined (not cast in stone yet) and management approves the plan. At this point the following should be complete:
* Business case (if required) with risk assessment.
* Preliminary project plan with preliminary iterations planned.
* Core project requirements are defined on paper.
* Major use cases are defined.
The inception phase has only one iteration. All other phases may have multiple iterations.
Elaboration Phase
The primary purpose of this phase is to complete the most essential parts of the project that are high risk and plan the construction phase. This is the part of the project where technical risk is fully evaluated and/or eliminated by building the highest risk parts of the project. During this phase personnel requirements should be more accurately determined along with estimated man hours to complete the project. The complete cost and time frame of the project is more firmly determined. During this phase how the system will work must be considered. Use cases will help identify risks. Steps to take during this phase:
1. Complete project plan with construction iterations planned with requirements for each iteration.
2. 80% of use cases are completed. Significant use cases are described in detail.
3. The project domain model is defined. (Don't get bogged down)
4. Rank use cases by priority and risk. Do the highest priority and highest risk use cases first. Items that may be high risk:
* Overall system architecture especially when dealing with communication between subsystems.
* Team structure.
* Anything not done before or used before such as a new programming language, or using the unified/iterative process for the first time.
5. Begin design and development of the riskiest and highest priority use cases. There will be an iteration for each high risk and priority use case.
6. Plan the iterations for the construction phase. This involves choosing the length of the iterations and deciding which use cases or parts of use cases will be implemented during each iteration. Develop the higher priority and risk use cases during the first iterations in the construction phase.
As was done on a preliminary level in the previous phase, the value (priority) of use cases and their respective risks must be more fully assessed in this phase. This may be done be either assigning an number to each use case for both value and risk. or categorize them by high, medium, or low value and risk. Time required for each use case should be estimated to the man week. Do the highest priority and highest risk use cases first.
Requirements to be completed for this phase include:
* Description of the software architecture. Therefore most use cases should be done, activity diagrams, state charts, system sequence diagrams, and the domain model should be mostly complete.
* A prototype that overcomes the greatest project technical risk and has minimal high priority functionality.
* Complete project plan.
* Development plan.
There may be an elaboration phase for each high risk use case.
This is the point at which I believe many of the steps in the Unified Process become vague. Considering the various diagrams and charts to be created, when they are created, and the best order to create them in, there seems to be a variety of opinions. I believe this is because in the real world there may be more than one correct solution and there are no hard and fast rules that work everytime. In a way, this flexibility is a strength of UML. Some documentation indicates that most use cases should be done before creating a domain model and others indicate that the domain model can be built on a use case by use case basis. A good compromise is to spend a short time on a brief domain model during the elaboration phase, then enhance the domain model as each use case is developed during the elaboration and construction phase iterations. Some documentation indicates that activity diagrams and class diagrams should be complete before the domain model is done. It is possible to create some of the diagrams and charts (artifacts) in parallel with each other. I'm not sure there is really any correct best way to do this, but I favor the following order.
1. Completion of 80% of use case diagrams.
2. Completion of 80% of high level use case diagrams.
3. Completion of expanded use case diagrams for major use cases only.
4. System sequence diagrams for major use cases.
5. Domain model (Don't get bogged down here with details). Just get a good idea of concepts involved. Use use cases to create the domain model. Any use case that strongly impacts the domain model should be considered and concepts from that use case should be incorporated in the domain model. The initial domain model may be drawn without lines and attributes to avoid too much detail and determine important use cases. The domain model may be refined later as the project analysis continues. If the system is large, domain models should be done on a per use case basis.
6. Optionally create a glossary of terms for concepts to improve team communication.
After this point the design part of the project begins (although more analysis is done for each use case) and the following will be done in each iteration of the elaboration and construction phases.
1. Operation contracts based on domain model and use cases.
2. Collaboration diagrams.
3. Class diagrams.
4. Map class and collaboration diagrams to code.
5. Update the domain model but do not force it to the class diagrams.
Considerations during this project should be the following:
* Consider possible significant changes (down the road) to the system during analysis.
* Regarding system functional ability what do you expect to be able to change?
Construction Phase
Construction iterations are based on use cases. Small use cases may be done in one iteration or a larger use case may be worked on in sections. For each iteration, analysis, design, and creation of software is performed for each use case in that iteration. As I understand the process, the following would be done for each construction iteration per use case. Again, much documentation indicates that the domain model (conceptual model) should be done for each construction iteration and be based on use cases being implemented during that specific iteration. The following should be done during the construction iterations:
1. Completion of expanded use case diagrams for use cases.
2. System sequence diagrams for major use cases.
3. Operation contracts based on domain model and use cases.
4. Collaboration diagrams.
5. Class diagrams.
6. Map class and collaboration diagrams to code.
7. Update the domain model but do not force it to the class diagrams.
It is worth performing tests to be sure each use case works properly at the end of the iteration. At the end of the construction phase there is a product that users can use. The following will be complete:
* Users manuals.
* Release version and description.
Transition Phase
During this phase, the finished product is brought to the user. Items to be addressed in this phase include:
* Final program debugging
* Code Optimization
* Beta testing
* Completion of manuals.
* User training
* Possible operation in parallel with an existing system.
Iterations
Iterations mostly occur in the elaboration and construction phases, but may occur in any phase.
As iterations progress, integration of the various iterations into each other should constantly be done so integration is not left at the end of the project. Each iteration should be complete at the scheduled time. If time becomes a problem, some use cases may need to be moved to other iterations. The plan may need to be changed every two to three iterations especially if you are finding out that many use cases are being moved to later iterations.
Testing
During the construction phase unit and integration testing will be done. At the end of the construction phase, system testing is done. Unit testing is based on use cases and tests to be sure the system can perform the use case functions. Integration testing ensures that the various construction iterations (based on use cases) can interface with each other.
Common Pitfalls to the Process
* Domain models are static (not behavior oriented).
* Domain models are an analysis artifact (not design) - Once the first domain model is constructed, when the second iteration is done, modify the original domain model rather than imposing design class diagrams on the domain model.
* Design is responsibility driven (not speculative) - Conciously use GRASP patterns.
* Not following the basics with GRASP patterns.
* Not recognizing the 20% of exceptions to GRASP patterns where design patterns should be used.
