Phase 3 of Unified Process Lifecycle - Construction

Unified process has never been so late in making its mark in the field of the iterative and incremental software development approaches. The unified process has got many refinements and one of them is the rational unified process. The whole process has been divided in to 4 phases the names of which are:

1. Inception
2. Elaboration
3. Construction and
4. Transition

The third phase i.e., the construction phase is what we have discussed throughout this article. So let us see what does this phase actually consists of. This is perhaps the largest phase of the whole unified software development process.

The progress that is to be made in this phase is completely dependent on the foundation that was laid in the previous phase. We mean to say that the remaining structure of the software system is built on the baseline that was developed in the elaboration phase. 

What is the Construction Phase

- Since the construction will be based up on the architecture baseline it is required that the baseline must have been properly developed along with the addressing of the risk factors. 

- In this phase, the implementation of the features and functionality of the software system takes place in an iterative manner and involves the time boxed iterations which are generally of very short duration. 

- These iterations are developed as a time boxed series and with every iteration an executable release of the software system or application is produced. 

- It is quite customary that the full length use cases must be written during the construction phase which then serves as a beginning for a new iteration and the process continues. 

- This phase makes use of the common UML (unified modelling language) diagrams. 

- Some of the common UML diagrams that are generally used are mentioned below:

1. Activity diagrams
2. Sequence diagrams
3. Collaboration diagrams
4. State diagrams
5. Transition diagrams
6. Interaction overview diagrams and so on.

- This is the phase that witnesses a lot of coding takes place since the primary objective is to build the software system or application. 

- However, the primary focus is on the development of the features and components of the system throughout the construction of the software system or application. 

- The number of the iterations involved in the construction depends largely up on the size of the project.

- This is generally done with the purpose of dividing the use cases in to small segments that are manageable enough and lead to the production of the demonstrable prototypes. 

- This is the phase in which the first external release of the software product is produced and this stage is marked by the IOCM or initial operational capability milestone. 

Goals defined for Construction Phase

Few goals have also been defined for this phase of the unified process as mentioned below:

1. Describing the remaining requirements that were not addressed in the preceding phases.
2. Drawing up a design for the system.
3. Ensuring that the system meets the needs of the customers and fit in to the port folio of the organization.
4. Completing component development.
5. Testing of the system and its documentation.
6. Optimizing the resources so that the development cost is reduced.
7. Achieving as much quality as possible.
8. Developing useful versions of the software product.

There is always a rush among the software development organizations to improve the software development processes they are using. Around 80- 90 % of the software failure arises due to faults that are made during the construction phase of the unified process. It is obvious that a more sensible approach will be followed out of all the options available.   

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

Different testing activities in Programming/Construction and Operations and Maintenance Phase

The main testing points in this phase are:
- Check the code for consistency with design
The areas to check include modular structure, module interfaces, data structures, functions, algorithms and I/O handling.

- Perform the testing process in an organized and systematic manner with test runs dated, annotated and saved.
A plan or schedule can be used as a checklist to help the programmer organize testing efforts. If errors are found and changes are made to the program, all tests involving the erroneous segment must be re-run and recorded.

- Asks some challenges for assistance
Some independent party, other than the programmer of the specific part of the code should analyze the development product at each phase. The programmer should explain the product to the party who will then question the logic and search for errors with a checklist to guide the search. This is needed to locate errors the programmer has overlooked.

- Use available tools
The programmer should be familiar with various compilers and interpreters available on the system for the implementation language being used because they differ in their error analysis and code generation capabilities.

- Apply stress to the program
Testing should exercise and stress the program structure, the data structures, the internal functions and the externally visible functions or functionality. Both valid and invalid data should be included in the test set.

- Test one at a time
Pieces of code, individual modules and small collections of modules should be exercised separately before they are integrated into the total program, one by one. Errors are easier to isolate when the number of potential interactions should be kept small. Instrumentation-insertion of the some code into the program solely to measure various program characteristics can be useful here.

- Measure testing coverage/ When should testing stop?
If errors are still found every time the program is executed, testing should continue. Because errors tend to cluster, modules appearing particularly error-prone require special scrutiny. The metrics used to measure testing thoroughness include statement testing, branch testing and path testing. Statement testing is the coverage metric most frequently used as it is relatively simple to implement.

Testing Activities in Operations and Maintenance Phase

Correctness, modifications and extensions are bound to occur even for small programs and testing is required every time there is a change. Testing during maintenance is termed regression testing. The test set, test plan, and the test results for the original program should exist. Modifications must be made to accommodate the program changes, and then all portions of the program affected by the modifications must be re-tested. After regression testing is complete, the program and test documentation must be updated to reflect the changes.