project plan - life cycle procedure

Responsibilities

6.1 For each project, the Project Manager identifies any variations from the Life Cycle described in this
document and also which phases of the life cycle are to be used for project control in their projects.

6.2 The Quality Manager approves and the General Manager authorises any deviations from this guideline.


7. Procedure

7.1. During project planning, the Project Manager decides on the appropriate lifecycle for the project by selecting from the various lifecycles described in this section .

7.2 The selected lifecycle for the project is then tailored to the project's needs based on:

- Tailoring criteria provided along with the lifecycle model
- Any requirements for the project specified by the customer
- Tailoring of organisation baselines based on new processes that will be piloted.

7.3 The lifecycle for the project is documented in the process handbook for the project.

7.4 The following terms are used while describing the various lifecycles:

- Business Requirements Specification (BRS) - the requirements to be met by the software such as functional, performance, interface and processing requirements are specified in detail.
- Functional Specification (FS) – the implementation aspects of the BRS such as the functional, performance, interface and processing requirements through business modelling, use cases, screen specifications and business rules.
- Design Specification
- High Level design - the system is broken down into individual components. The interfaces between the components are identified.
- Detailed Design - the behaviour and composition of each of the components is defined.
- Coding - the design is translated into code in an appropriate programming language.
- Unit Testing - each of the components is tested individually to verify that the component satisfies its goals, such as functional, performance and reliability goals.
- Integration Testing - every combination of components is tested to verify that the combination functions correctly as intended.
- System Testing - the system is built as a whole and tested to verify its conformance to the defined requirements.
- Release - the components of the software (including all documentation and information necessary to build the software) are assembled together for shipment.
- Acceptance - the activity of obtaining the customer's agreement that all the required deliverables meet their defined requirements.
- Specification of conversion - the various items to be converted - such as operating system calls, blocks of code specific to the older system, utility routines, etc are identified along with how they will be converted.
- Re-engineering specification - the software items to be created or modified in order to build a system that satisfies the requirements are identified, and the modifications to be made to these are identified.







7.5 Prototyping can be performed at any of these phases and need not conform to the structure as described in this document. However, all resulting code and/or design must undergo the life cycle steps and controls before it can be used in the product. The process such as the one for Rapid Development will have to be approved by the General Manager/Quality Manager before it can be used in a project. In addition, such a development can be taken up only if the contract/LOI allows it.

Handling overlapping of phases

This Lifecycle Procedure recognises that the phases mentioned in the previous sections may overlap due
to project schedule requirements. In such cases, the following guidelines are applicable:

- The Project Manager identifies the phase overlap as a risk in the project plan and lists the steps taken to counter these risks. These may include the steps outlined below.
- The Project Manager ensures that the inputs for an activity are available before the activity commences. (For example, design specifications for a module must be reviewed and approved when coding for the module commences although design of other modules might not be complete). The Project Manager also ensures that such inputs are under version control.
- When a change in an item requires a change in other items / activities for which this has been used as an input, the Project Manager confirms if the change is really necessary.
- If yes, the Project Manager ensures that revised versions / amendments of the item, along with detailed descriptions of the changes, are made available to personnel performing subsequent activities.
- The Project Manager also performs an impact analysis and revises the project schedules, if necessary. Such schedule changes are highlighted in the project status report. The Project Manager also ensures that sufficient review / testing of the changes is performed.