Phase 4 of Unified Process Life cycle - Transition

Unified process is one of the best development processes we have of the iterative and incremental form. The whole unified process is completed in four phases which have been mentioned below:

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

This whole article is all about the last phase i.e., the transition phase. In this whole article we are going to discuss about the last phase. 

What is a Transition Phase?

- The final phase of the unified process i.e., the transition phase involves the deployment of the system for targeting the customers.

- The feedback that is collected on the account of the previous releases helps in further refining or improving the software system or application. 

- It can also be decided over the further functionality that have to be added to the software system or application under development to make it much better. 

- Transition phase like all of the preceding three phases is composed of several timed iterations that are time boxed. 

- Apart from just targeting the users, the transition phase also involves user training and the system conversions. 

- The transition phase has been named so because it is in this phase that the transition of the whole system from development to production takes place and software is made available to the users. 

- Along with the end users in some cases the maintainers might also be treated. 

- This phase also witnesses the beta testing of the software system or application so that it is validated against the expectations of the end users. 

- A certain quality level is set in the phase i.e., in the inception phase which is tested in against by the quality of the software system or application in the transition phase. 

- The point at which all the objectives are met is called the “product release milestone”. 

- At this point the product is declared finished and the development is also declared to be complete. 

- The unified process is quite a robust software process that is meant for addressing the development as well as the production needs of the users and the customers. 

- We need a software development process that serves the scope of our real world quite well and provides us with a balanced perspective of the alternative programming methodologies available from all around the field. 

- In this transition phase, if there are any legacy systems that you are going to replace, then your whole software system or application is operated in parallel with those legacy systems. 

- This leads to the conversion of the legacy data bases and the systems in to an improved one that supports your new software system or application. 

Goals of transition Phase

The transition phase has got three main goals as mentioned below:

1.Evolving the final product baseline or the production base line of the software system or the application.

2.Training the materials for the software system or application.

3.Creation of the documentation which is inclusive of all the user manuals, operations documentation and the support documentation.

Issues faced during Transition Phase

- This phase is concluded with the product release milestone. 

- Achieving this milestone is not so easy since you have to satisfy all the expectations of the end users and also justify the actual expenditures against the planned expenditure. 

- Issues such as finishing the features that were postponed usually arise after the product has been transited to the end users or customers. 

- The production baseline ought to be mature enough to be deployed in the end user domain. 

- The operational data bases are also converted and the final product is released for marketing, distribution and sales team. 

Validation phase - Unit Testing - UTC Document, UTC Checklist, Defect Recording

UTC Document
The Unit Test Case document consists of test case number, test case purpose, the procedure, the expected result and the actual result. Columns like Pass/Fail and Remarks are also present in UTC.

UTC Checklist
UTC checklist may be used while reviewing the UTC prepared by the programmer. As any other checklist, it contains a list of questions which can be answered in yes or no. The 'aspects' list can be referred to while preparing UTC checklist.
- Are test cases present for all form field validations?
- Are boundary conditions considered?
- Are error messages properly phrased?

Defect Recording
It can be done on the same document of UTC, in the column of 'Expected results'. this column can be duplicated for the next iterations of unit testing. Defect recording can also be done using some tools like Bugzilla in which defects are stored in the database. Defect recording needs to be done with care. It should be able to indicate the problem in clear, unambiguous manner and reproducing of the defects should be easily possible from the defect formation.

To conclude, exhaustive unit testing filters out the defects at an early stage in the development life cycle. It proves to be cost effective and improves quality of the software before the smaller pieces are put together to form an application as a whole. Unit testing should be done sincerely and meticulously.

Validation phase - Unit Testing - how to write Unit test cases

Preparing a Unit test case document commonly referred as UTC is an important task in unit testing activity. Having a complete UTC with every possible test case leads to complete unit testing and thus gives an assurance of defect free unit at the end of unit testing stage.

While preparing unit test cases the following aspects should be kept in mind-

Expected functionality
Write test cases against each functionality that is expected to be provided from the unit being developed. It is important that user requirements should be traceable to functional specifications which should be traceable to program specifications which should be traceable to unit test cases. Maintaining such traceability ensures that the application fulfills user requirements.

Input Values
- Write test cases for each of the inputs accepted by the unit. Every input has certain validation rule associated with it. Write test cases to validate this rule.
- There can be cross-field validations in which one field is enabled depending upon input of another field. Test cases for these should not be missed.
- Write test cases for the minimum and maximum values of input.
- Variables that hold data have their value limits. In case of computed fields, it is very important to write test cases to arrive at an upper limit value of the variables.
- Write test cases to check the arithmetic expressions with all possible combinations of values.

Output Values
- Write test cases to generate scenarios which will produce all types of output values that are expected from unit.

Screen Layout
Screen/report layout must be tested against the requirements. It should ensure that pages and screens are consistent.

Path Coverage
A unit may have conditional processing which results in various paths, the control can traverse through. Test cases must be written for each of these paths.

Assumptions and Transactions
A unit may assume certain things for it to function. Test cases must be written to check that the unit reports error if such assumptions are not met.
In case of database applications, test cases should be written to ensure that transactions are properly designed and in no way inconsistent data gets saved in the database.

Abnormal terminations and Error messages
Test cases should be written to test the behavior of unit in case of abnormal termination.
Error messages should be short, precise and self explanatory. They should be properly phrased and free of grammatical mistakes.

Validation phase - Unit Testing - Stubs and Drivers

The validation phase falls into picture after the software is ready or when the code is being written. There are various techniques and testing types that can be appropriately used while performing the testing activities.

Unit Testing

A unit is allocated to a programmer for programming. Functional Specifications document is used as an input for programmer's work. The programmer prepares program specifications for his unit from the functional specifications. Program specifications describe the programming approach, coding tips for the unit's coding.
Using these program specifications as input, the programmer prepares unit test cases document for that particular unit. A unit test cases checklist may be used to check the completeness of unit test cases document. Program Specifications and unit test cases are reviewed and approved by quality assurance analyst or by peer programmer. The programmer implements some functionality for the system to be developed. The same is tested by referring the unit test cases. While testing that functionality if any defects have been found, they are recorded using the defect logging tool whichever is applicable. The programmer fixes the bugs found and tests the same for any errors.

Stubs and Drivers
A software application is made up of a number of units where output of one unit goes as an input of another unit. Due to such interfaces, independent testing of a unit becomes impossible. So here, we use stub and driver.
A driver is a piece of software that drives the unit being tested. A driver creates necessary inputs required for the unit and then invokes the unit.
A unit may reference another unit in its logic. A stub takes place of such subordinate unit during the unit testing. A stub is a piece of software that works similar to a unit which is referenced by the unit being tested but it is much simpler than the actual unit. A stub works as a stand-in for the subordinate unit and provides the minimum required behavior for that unit.
Programmers needs to create such drivers and stubs for carrying out unit testing. Both the driver and stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the unit in question.

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.

Spiral Model - A type of software development life cycle model

Boehm proposed the spiral model in 1988. A useful model for projects involving high risks. each loop in spiral represents a development phase. Each loop is split into four sections which carry out a specific task.
- Determine the objectives, alternatives, and constraints.
- Analysis of risk and to evaluate alternatives.
- Execution of that phase of development.
- Planning the next phase.
For each round of spiral, one form is top be filled with information like :
- Objectives
- Alternatives
- Constraints
- Risk factors
- Risk resolution
- Results
- Plans
- Commitment
At the end of each spiral the management can review the status based on this form and decide the future course of action.

Advantages of Spiral Model

- Estimates become more realistic as work progresses.
- The model is designed to cope with the inevitable changes to the learning experience that will happen over the course of design and delivery.
- Multimedia producers can get their hands in and start working on a project earlier, and therefore shape the design process as well.

Disadvantages of Spiral Model

- Highly customized limiting re-usability.
- Applied differently for each application.
- Risk of not meeting budget or schedule.
- Risk of not meeting budget or schedule.