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.   

Phase 2 of Unified Process Life cycle - Elaboration

Unified process is one of the outstanding processes that follow an iterative and incremental approach for the software development. The whole process of the unified process is constituted of the 4 stages or phases namely:

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

This article is dedicated to the second phase of the unified process i.e., the elaboration phase. So let us see what all processes are involved in this phase. 

There exists a short phase between the inception phase and the elaboration commonly knwn as the “elicitation” phase. It is sometimes regarded as apart of the elaboration phase only but to keep the elaboration phase short and simple it is often treated separately.

First let us know what is this elicitation phase? 

Elicitation addresses the below mentioned three main problems of the software development process:

1. Problem of volatility
2. Problem of scope
3. Problem of understanding

What is an Elaboration Phase?

- During this whole elaboration phase, it is required that the project team captures quite a large number of the requirements of the software system or the application. 

- But this is not to be confused with the primary goal of the elaboration phase. It is quite different. 

- The primary goal involves the addressing of the involved and known risk factors. 

- Another aspect of the primary goal is to validate the architecture model being used in the system. 

- This is done with the help of various processes like those mentioned below:

1. Creation of use case diagrams
2. Creation of class diagrams
3. Creation of class with basic notation only and
4. Creation of architectural or the package diagrams.

- All these above mentioned processes fulfil only the first aspect of the primary goal that is to identify the risk factors. 

- The second aspect is fulfilled through the implementation of an EAB or an executable architectural baseline.

- It helps greatly in validation of the system architecture. 

- This is just a partial implementation rather than being a full implementation. 

- The partial implementation is of the components that are architecturally significant like the system including the core.

- The executable architecture baseline is built out of a series of small iterations that have been time boxed so that there is the stabilization of the architecture of the system by the end of the elaboration phase. 

- The executable architectural baseline provides a means to demonstrate that the key system functionality are supported by the architecture and also exhibit proper expected behaviour when it comes to the terms like the scalability, performance and cost. 

- The outcome of the elaboration phase i.e., the elaboration phase deliverable actually serves as a plan for the construction phase that also lays down the cost estimate and the schedule estimates.

- The plan at this point needs to be credible and quite accurate since the elaboration phase experience is what on which it is dependent and also because all the significant risk factors have been addressed during this phase. 

- The ultimate purpose of this phase is to provide the software with a baseline for the architecture of the software system that serves as a foundation for the further efforts. 

Goals of Elaboration Phase

- The following are the goals of the elaboration phase:

1. To have a detailed understanding of the key requirements.
2. To mitigate significant risks.
3. To produce accurate schedule and cost estimates.
4. To design, validate and implement the architecture baseline

- The number of iterations in the elaboration phase is not fixed; it varies depending up on the factors such as the maintenance cycle and the green field development. 

What are different characteristics of baseline testing?

Most of us don’t know what is a baseline actually? So let us first clear up what does it actually means?

Generally a baseline is defined as a line that forms the base for any construction or for measurement, comparisons or calculations. In the context of engineering and science it refers to the point of reference. Other tests like load tests, stress tests, resilience tests; baseline tests also form a very essential and important part of the performance testing.

It’s a very crucial part of a good software system or application.

Baseline testing is very famous for improving the overall performance of the software system. It has been found that the baseline testing identifies nearly 85 percent of the software system or application issues.

Baseline testing also helps a great deal in solving most of the problems that are discovered. A majority of the issues are solved through baseline testing.

The whole implementation and idea of how the baseline testing should be performed should be clear in the mind of the software tester. He should know that why the baseline testing is being done?

Some questions ?
- What is the baseline testing referring to in the software system or application?
- How the baseline testing is to be carried out or what is the test plan?
- How the baseline tests are to be executed?
- How this baseline testing differs from performance testing?

Advantages of Baseline Testing
- The main advantage here is that a large amount of time is saved by baseline testing.
- Actually it saves the time overhead.
- If we look at the whole scenario, the performance testing is the most time consuming process and complex also. Often the software testers or developers are not able to spare that much time for carrying out the performance testing very efficiently. So usually what some testers do is that they reduce the number of baseline tests. But the fact is that the baseline testing only saves much of the time.
- Reducing the number of baseline tests causes potential errors and bugs which in turn consume more time later in getting identified and corrected.
- Baseline testing is where most of the time can be saved.
- A performance testing plan must compulsorily include baseline testing and load testing. If more time is there endurance testing, volume testing and stress testing should also be included.

The testers or the developers should have a clear and good understanding of the testing that is to be performed.
- Baseline is usually performed for each script with 1, 2, 5, 10, 20, 30 and at the most 50 users to check the baselines.
- This is done typically for determining the response times. Generally baseline tests are carried out for each individual script that is a part of the load testing and any identified problem is immediately isolated.
- To get good and useful results the baseline tests should be executed at least for 20- 30 minutes.
- In baseline testing the test data is not lost when a test run fails and the data can be prepared for the next test quickly.
- Baseline testing reduces the time consumption of load testing also.
- Baseline testing should be properly monitored. Improper monitoring requires repetition of tests which is again wastage of time.
- Expecting meaningful results without proper monitoring is meaning less. Time over time baseline testing has proved itself to be a very important part of performance testing.
- Baseline testing shows the improvement of the software system or application when the problems and errors are fixed.
- Baseline testing should be done carefully without adhering to any shortcuts. By the time you begin the load testing, your software system will already be performing well.

Software Configuration Management - Baselines

Change is a fact of life in software development. A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. Before a software configuration item becomes a baseline, change may be made quickly and formally. However once a baseline is established, we figuratively pass through a swinging one door. Changes can be made but a specific formal procedure must be applied to evaluate and verify each change.

In terms of software engineering, a baseline is a milestone in the development of software. A baseline is marked by the delivery of one or more software configuration items that have been approved as a consequence of a formal technical review. Software engineering tasks produce one or more software configuration items (SCIs). After SCIs are reviewed and approved, they are placed in a project database. When a member of a software team wants to make a modification to a baselined SCI, it is copied from the project database into the engineer's private
workspace. However, this extracted SCI can be modified only if SCM controls are followed.

The Software Configuration Management process applied to this project identifies many types of baselines;each of them has specific identification rule and minimum verification characteristics.
All the development artifacts (source code, makefile, documentation) are identified and managed under configuration.

- Working baseline:
* Description: this is a development baseline in the private working area of a developer. This baseline is not identified since it is a private one.
* Identification: none
* Minimum characteristics: none
- Unstable baseline:
* Description: this is a development baseline in the public area of CVS.
* Identification: this baseline is not identified. It is only accessible as the 'latest' one.
* Minimum characteristics: none
- Stable baseline:
* Description: this is a development baseline in the public area of CVS. This baseline identifies a consistent set of modifications or an important step during the implementation of a modification.
* Identification: a stable baseline is identified according to the involved GHOSTS component and the current date.
* Minimum characteristics: a stable baseline shall be at least compilable / linkable.
- Official baseline:
* Description: this is a user baseline in the public area of CVS. This baseline identifies a consistent set of modifications; those modifications are well implemented, verified and tested.
* Identification: an official baseline is identified according to the part of the involved GHOSTS component and the release identification.
* Minimum characteristics: an official baseline shall be fully implemented, verified and tested.