Software Life Cycle Process



[pic]

Software Life Cycle Process

Revision History:

|Ver. No. |Date |Comments |Prepared By |Reviewed By |Approved By |

|Ver. 1.0 |15th June, 2008 |Initial Release |Abhishek Rautela |Rohitash |Mr. Sudhir Saxena |

|Ver. 2.1 |10th June 2009 |Update section 2.0 and |Abhishek Rautela |Rohitash |Mr. Sudhir Saxena |

| | |formatting | | | |

|Ver. 3.0 |23rd Feb, 2010 |Updated Sec 2 to |Neha |Abhishek Rautela |Mr. Sudhir Saxena |

| | |incorporate V-Model | | | |

|Ver. 3.1 |18th Oct, 2011 |Formatting & Update |Rahul Raj |Dhananjay Kumar |GM Dua |

| | |section 2.1 | | | |

Table Of Contents

1.0 Introduction 5

1.1 Purpose 5

1.2 Scope 5

1.3 Quality Objective 5

2.0 General Description of the Software Process 5

2.1 Software Process Models (Software Life Cycle Models) 6

2.2 The Process Decomposition 14

2.3 The Process Overview 15

2.3.1 Requirement Analysis 15

2.3.2 Software Design 15

2.3.3 Development 15

2.3.4 Testing 15

2.3.5 Replication, Delivery and Installation 16

2.3.6 Implementation 16

2.3.7 Post Production Support and Maintenance 16

3.0 Specific Description of the Sub-Processes 16

3.1 Requirement Analysis 16

3.1.1 Activity Definition 16

3.1.2 Objective 16

3.1.3 Entry Criteria 16

3.1.4 Inputs 16

3.1.5 Outputs 17

3.1.6 Exit Criteria 17

3.1.7 Standards and Procedures 17

3.1.8 Control Mechanism 17

3.1.9 Approval 17

3.1.10 Quality Records 17

3.2 Software Design 18

3.2.1 Activity Definition 18

3.2.2 Objective 18

3.2.3 Entry Criteria 18

3.2.4 Inputs 18

3.2.5 Outputs 18

3.2.6 Exit Criteria 18

3.2.7 Standards and Procedures 18

3.2.8 Control Mechanism 19

3.2.9 Approvals 19

3.2.10 Quality Records 19

3.3 Development 19

3.3.1 Activity Definition 19

3.3.2 Objective 19

3.3.3 Entry Criteria 19

3.3.4 Inputs 19

3.3.5 Outputs 19

3.3.6 Exit Criteria 20

3.3.7 Standards and Procedures 20

3.3.8 Control Mechanism 20

3.3.9 Approvals 20

3.3.10 Quality Records 20

3.4 Testing 20

3.4.1 Unit Testing 20

3.4.2 Module/Integration Testing 21

3.4.3 System Testing 23

3.4.4 Acceptance Testing 25

3.5 Replication, Final Inspection, Delivery and Installation 26

3.5.1 Activity Definition 26

3.5.2 Objective 26

3.5.3 Entry Criteria 27

3.5.4 Inputs 27

3.5.5 Outputs 27

3.5.6 Exit Criteria 27

3.5.7 Standards and Procedures 27

3.5.8 Control Mechanism 27

3.5.9 Approvals 27

3.5.10 Quality Records 27

3.6 Implementation 27

3.6.1 Activity Definition 27

3.6.2 Objective 28

3.6.3 Entry Criteria 28

3.6.4 Inputs 28

3.6.5 Outputs 28

3.6.6 Exit Criteria 28

3.6.7 Standards and Procedures 28

3.6.8 Control Mechanism 28

3.6.9 Approvals 28

3.6.10 Quality Records 28

3.7 Post Production Support and Maintenance 29

3.7.1 Activity Definition 29

3.7.2 Objective 29

3.7.3 Entry Criteria 29

3.7.4 Inputs 29

3.7.5 Outputs 29

3.7.6 Exit Criteria 29

3.7.7 Standards and Procedures 29

3.7.8 Control Mechanism 29

3.7.9 Approvals 30

3.7.10 Quality Records 30

4.0 Glossary 30

Introduction

1 Purpose

This Software Life Cycle Process explains the various life cycle phases of the software process along with the input, output and procedures that are relevant to those phases. The life cycle phases mentioned here refer to requirement analysis, software design, development, testing, implementation and maintenance of software.

This process is intended for use by all software developers of NST.

2 Scope

The Software Life Cycle manual is applicable to all software development, software maintenance, and related software services provided by NST.

3 Quality Objective

The quality objective for establishing and explaining the Software Life Cycle Process is to facilitate an in-depth understanding of the software process by the software development teams. This in turn would lead to proper planning and monitoring of project activities and thereby help the software development teams to produce a high quality end product. Software Developers address quality by applying relevant technical methods and measures to the software life cycle phases, conducting formal technical reviews, and testing, as mentioned in this Software Life Cycle process and Review process.

General Description of the Software Process

The life cycle to be followed in the project will be described by the Project Manager in the Project Management Plan.

It is important to note that the life cycles described here are not mandatory for a project to follow but serves only as a guide. In case a different life cycle / set of tasks not mentioned in this document are more appropriate for a project to follow, the Project Manager should feel free to describe it in the Project Plan and continue. The importance of this document is that the project be planned and managed based on an appropriate set of activities to be performed.

Software Life Cycle vs. Project Life Cycle

Software Life Cycle refers to the life cycle phases and activities of a software system. In other words, it means the various phases and activities during the software process (development, or maintenance, or both). A software project may involve working (by the respective project teams) on any one or more of such life cycle phases of a software system. The software life cycle phases and activities that may be involved in a project depend upon the scope of work in the project and the same shall be mentioned in the Project Plan.

Depending on the scope of work in the project and its complexity, the nature of the application system, and the associated technology, the software life cycle activities may differ and therefore, the concerned Project Manager may need to tailor the software life cycle phases and activities for a project .

The Software Life Cycle (SLC) phases may be broadly represented as:

SLC = Software Development Life Cycle (SDLC) + Software Maintenance Life Cycle (SMLC)

Where SDLC refers to all the software life cycle phases during development of the software viz. system analysis, system design, development, testing, and implementation, and SMLC refers to all activities during the software maintenance phase. As the nature of software maintenance may be varied and widely diverging in scope, the SMLC phase itself may have several distinct mini life cycles within itself, each one of them having its own characteristics and identity.

Project Life Cycle refers to the life cycle phases and activities during the life of a project. Typically these are referred to as a) project initiation and b) project closure phases. The software life cycle phases and activities involved are identified during the project initiation phase and accordingly, the Project Plan is prepared. The project activities are monitored as per the approved Project Plan throughout the project and accordingly, the Project Plan is revised, as and when required. Once the project commitments are met or the management decides to close the project, the project closure phase occurs and the project closure activities are carried out.

1 Software Process Models (Software Life Cycle Models)

There are several models (details available in standard published literature) which can describe the life cycle phases and activities of a software process. Some of these models have been referred below.

A. Waterfall Model or Linear Sequential Model

In the Waterfall Model, 8 phases have been identified in a software process which occurs sequentially. Each phase is executed once. The model recognises feedback loops between phases and it insists on confining the feedback loops to successive phases only, so as to minimise the expensive rework involved in feedback across many phases. The process decomposition diagram for the Waterfall Model is illustrated below.

Waterfall model

This model is best suited when a set of high quality, stable user requirements exists. Its limitations stem from the fact that it requires complete knowledge of all requirements at early stages of the life cycle, commitment of all financial and other resources up front (with a low visibility until the product is ready) and lack of flexibility to accept changes to requirements. The Waterfall Model is inappropriate for development situations where these factors may pose problems.

B. RAD Model

Rapid Application Development (RAD) is a linear sequential software development process model that emphasises an extremely short development cycle. The RAD model is a "high-speed" adaptation of the Waterfall Model in which rapid development is achieved by using a component based construction approach using "RAD tools". If requirements are well understood and the project scope is limited, the RAD process enables a development team to create a "fully functional system" within very short time periods. Used primarily for information system applications, the RAD process model is depicted below.

RAD model

The time constraints imposed on a RAD project demand scalable scope. If a business application can be modularised in a way that enables each major function to be completed in say, less than 3 months, it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole application.

Not all types of applications are suitable for RAD. If a system cannot be properly modularised, building the components necessary for RAD will be problematic. If high performance is an issue, or if the technical risks are high (may be arising out of use of new technology), or if the extent of interoperability of the proposed application with existing programs is significant, RAD is not suitable as a life cycle model.

C. Incremental Model

The Incremental Model combines the elements of Waterfall Model with the philosophy of an iterative approach. As illustrated below, it applies the linear sequences in the Waterfall Model in a staggered manner as the calendar time progresses. Each linear sequence produces an incremental deliverable of the software. The first increment is often a core product where the basic requirements are addressed, but many supplementary features remain undelivered. The core product is reviewed in detail by the customer and may be even used.

As a result of the detailed review and/or use of the core product, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and delivery of the additional features and functionality. This process is repeated following the delivery of each increment until the complete product is produced.

This has a number of distinct advantages over the traditional sequential development model. This is the best choice for projects that has high technical risks, and objectives are achieved by breaking down the project organisation and systems construction into manageable sub-projects. The advantage of this model is that the development team learns of the customer's expectations in gradual steps and gets the opportunity to implement changes in the same incremental steps. It is particularly useful when staffing is unavailable for a complete implementation of the full system by the project deadline. The core product can be implemented with fewer staff that can be put to use by the user. If the core product is well received by the user, additional staff is added to work on the next increment(s).

Incremental model

D. Prototyping Model

In the Prototyping Model, the software requirements are developed in a series of iterations. The life cycle starts with requirement analysis. The analysts discuss with the customer the overall system objectives, identify whatever requirements are known, and outline areas where further definition is needed. Based on this knowledge a quick "Conceptual or Gross Design” is made which focuses on a representation of those aspects of the software that will be visible to the customer/user.

On the basis of the Gross Design, a prototype is built which serves to obtain user feedback and refines the requirements of the software to be produced. Iteration occurs as the prototype is tuned to satisfy the needs of the customer and thus facilitate a better understanding of the customer requirements and thereby, modification and refinement of the system requirements.

The life cycle showing the sequence of phases in the Prototyping Model is shown below.

Prototype model

E. Spiral Model

One of the better alternatives to the above models is a non-linear life cycle model known as the Spiral Model. This couples the iterative nature of the Prototyping Model with the controlled and systematic approach of the Waterfall Model. This model does not necessitate either a full knowledge of user requirements, or a full commitment of funds for the entire development work at the beginning of the project. Feedback between phases is a natural activity in this life cycle model.

Like the Waterfall Model, the Spiral Model starts out with a set of objectives that specify quality and costs associated with the reaching of goals. In this technique, the developer creates a model of the software that must be built. The model may be i) a paper prototype or PC-based model that depicts man-machine interaction in a form that enables the user to understand how such interaction will occur or ii) a working prototype that implements some subsets of the functions required of the desired software.

The following diagram is a representation of the Spiral Model of the software process.

Spiral model

There are also software process models such as Component Assembly Model, Concurrent Development Model, Formal Methods Model, etc. Choosing a process model for a software project depends on a number of factors. However, the concerned Project Manager may choose and/or may even tailor any of the life cycle models as he/she thinks fit for a particular situation.

In all the above models the elements of life cycle phases are essentially the same. These are:

• Requirements Specifications Phase

• Design Phase

• Development (i.e. software construction) Phase

• Testing Phase

• Replication, Delivery and Installation Phase

• Implementation

• Post Production Support & Maintenance Phase

Therefore in section 3.0 viz. Specific Description of the Sub-Processes, the procedures involved in these elemental life cycle phases are described in detail. Sections 2.5 and 2.6 provide the process decomposition diagram and the process overview respectively.

F. V Model

V-Model has evolved from the Waterfall Model. In V-Model, each phase must be completed before the next phase begins. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase; to form the typical V shape. Testing is emphasized in this model more than in the waterfall model. It has a structured approach for testing. It results high quality into the development of our end products.

The following diagram is a representation of the Spiral Model of the software process.

[pic]

V model

Few Benefits identified for V- Model are:

• Faults are prevented and it stops fault multiplication.

• Avoids the downward flow of defect.

• Lower defect Resolution cost due to earlier detection.

• Improved quality and reliability.

• Reduction in the amount of Re-work.

• Improved Risk Management

• Validation and Verification at each level of stage containment

• Allows testers to be active in the project early in the project’s lifecycle. They develop critical knowledge about the system.

Joint Application Development Model

Joint Application Development (JAD) is a technique that allows the development team, customer management and user groups to work together to build a product. This is more of a project management strategy and approach than software process model, though the life cycle activities may differ in some cases while the JAD technique is adopted. Thus a project using JAD technique may use any of the life cycle models described above with the necessary tailoring of the life cycle model.

G. Agile Software Development Model

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

[pic]

Agile model

Software Maintenance Life Cycle

The life cycle for any support project will normally involve understanding the system that is to be supported - system study, and then providing support as when any issues are reported by the user (issues could include bugs, exceptions or minor changes) - issue handling. These two phases are described below.

System Study

A base lined Project Plan, code and related documents should exist before the start of system study. The inputs to this phase apart from the Project Plan (which gives milestones related to the phase), the code and related documents may include a statement giving the user requirements in terms of expected performance levels.

The main task to be carried out during this phase is:

• Understanding the system - what it does functionally, and also the system design.

Issue Handling

The main inputs to this phase, which is iterative in nature, are issue reports / enhancement requests (problems, changes) from the user.

The main tasks to be carried out for each issue report / enhancement request are:

• Log the issue report / enhancement request

• Conduct an impact analysis to determine the configuration items (CIs) affected (code and documents), and the effort and time required.

• Get an approval from the project's Software Change Control Board (SCCB), if required

• Check out the affected CIs from the baseline directory

• Carry out the required changes

• Review/Test the changed CIs

• Make corrections, if required

• Re-baseline the CIs with new version numbers

• Release the new version of the software

• Conduct regression testing at defined frequencies, or as appropriate.

2 The Process Decomposition

The Software Development Life Cycle process comprises systems analysis, design, development, testing, delivery, implementation and maintenance of a software system. The Process Decomposition diagram of Software Development Life Cycle Process is shown below.

3 The Process Overview

1 Requirement Analysis

This process is conducted with the following objectives in mind:

• Identify the customer's need

• Evaluate the system concept for feasibility

• Perform economic and technical analysis

• Create a system definition that forms the foundation for all subsequent engineering work. Both hardware and software expertise are required to successfully attain the objectives listed above.

2 Software Design

This is a multi step process that focuses on four distinct attributes of software: data structure, system architecture, interface representations and procedural (algorithmic) detail. The design process translates requirements into a representation of the software that can be assessed for quality before coding begins.

3 Development

The design must be translated into a machine-readable form. The development/coding takes care of these activities. This step encompasses coding, as well as, application being developed using appropriate tools.

4 Testing

Once coding is completed, program testing begins. The testing process focuses on the logical internals of the software, assuring that all statements have been tested, and on the functional externals - that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results.

5 Replication, Delivery and Installation

A procedure that identifies needs for control of performing replications of software deliverables, maintaining proper backup of the deliverables, accurate identification, shipment of deliverables to customer, and installation of software at customer's site.

6 Implementation

To install, run and audit the output of the developed software and subsequently impart training to the end user.

7 Post Production Support and Maintenance

To ensure high availability /uptime and accurate running of software.

Specific Description of the Sub-Processes

1 Requirement Analysis

1 Activity Definition

This is an activity to define the procedure to study the complete system as given in the contract by the Customer in depth, such that each process linked to the final preparation of the software is clearly understood.

2 Objective

The objective is to decompose the whole assignment into well-understood processes on the basis of business logic, end user's and functional requirements to be reviewed and approved by the concerned authority.

3 Entry Criteria

Project Plan has been base lined.

4 Inputs

• Any system requirements that were found during the pre-proposed stage and after

• All customer correspondence related to system requirements

• Any other relevant reference material

5 Outputs

• Software Requirements Specification (SRS) / Requirements Traceability Matrix.

• Customer signs off on SRS or equivalent.

6 Exit Criteria

The SRS is reviewed and approved by the User/Customer and the PM. Unless approval from at least the PM is obtained, the next phase will not be started. However, some base activities, which are not dependent on the customer’s approval, may be continued under the sole discretion of the PM.

7 Standards and Procedures

1. Functional decomposition of the existing system either computerised or manual is done.

2. Input and output requirements for the process have to be identified.

3. Data conversion strategy should be noted, if required. The format of existing data should be taken from the user.

4. Acceptance criteria with reference to scope, functionality, performance, and security level must be identified, as appropriate.

5. Implementation plan must be drafted. In case of module wise implementation, prioritisation should be as agreed with the Customer/User.

6. Hardware, software and infrastructure requirements must be identified.

7. SRS or equivalent document is prepared.

8. SRS shall be reviewed and approved by the PM, User/Customer, as applicable.

9. If some cases are not applicable as per the template, the PM shall clearly mention and shall incorporate the changed SRS template .The Quality department shall be notified regarding the same.

10. Based on the SRS, the system test cases shall be prepared. The system test cases shall be base lined before the start of the testing phase.

11. After base lining the SRS, the requirements traceability matrix (RTM) shall be updated.

8 Control Mechanism

Reviewed and approved by the PM and User/Customer, and all documents shall be under control of CM according to the configuration Management Process.

9 Approval

The SRS shall be reviewed and approved by the PM and/or User/Customer. If the PM makes the SRS by himself/herself, the same will be approved by his/her reporting authority.

10 Quality Records

• SRS Review Report

• Sign off from Customer or User, if any

2 Software Design

1 Activity Definition

This is an activity to convert the requirements as expressed in the analysis phase to the level of programmable processes.

2 Objective

The objective is to get all the processes to programmable level, screen design and the database and table relationships, object model, use cases, sequence diagram, state transition diagram and object dictionary.

3 Entry Criteria

• Base lined SRS

4 Inputs

• Base lined SRS

5 Outputs

• Base lined System Design Description (SDD)

6 Exit Criteria

• Base lined SDD

7 Standards and Procedures

1. Decide on application standards, such as, naming conventions for files, tables, programs and objects. Use of function keys by referring to the coding standards if available.

2. Preparation of all SDD shall be made with reference to the guideline for high level and low level design. If some cases are not applicable as per template, the PM shall clearly mention and shall incorporate the changed SDD template in consultation with QA.

3. Develop interface specifications.

4. Design system and integration test, test cases and test procedure for integration and system testing design test data.

5. Review the resource requirements for data conversion and program coding activities, and in case of a deviation from the original project estimates, the PM should update the PP and plan appropriate actions.

6. After the SDD has been prepared, it is reviewed and base lined.

7. The RTM is updated after base lining of SDD

8. The unit test cases / module / integration test cases are prepared based on SDD. The unit / module / integration test cases are base lined before commencement of testing.

8 Control Mechanism

Reviewed and approved by the PM, and all documents shall be under control of CM according to the Configuration Management Process.

9 Approvals

The SDD shall be reviewed and base lined.

10 Quality Records

• SDD Review Report

3 Development

1 Activity Definition

This is an activity to convert the process identified from Design Phase to usable codes and to test individual program level process using test data.

2 Objective

The objective is to generate usable codes.

3 Entry Criteria

• Base lined SDD

4 Inputs

• Base lined SDD

5 Outputs

• Codes and database (if any)

6 Exit Criteria

Implementation of all the functional points as per the conscious knowledge of the developers. End of development will be declared by the PM or any other person assigned by the PM.

7 Standards and Procedures

1. Create user interface.

2. Create database (if required) and integrate it with user interface.

3. Testing by the programmer to ensure error free programming.

4. Coding shall be carried out as per the coding standards, if available for the technology.

5. Code review may be conducted as per the requirements of the project.

6. After coding, the RTM is updated. Refer to the guideline for traceability matrix.

8 Control Mechanism

Developers to ensure error free running of programs.

9 Approvals

N/A

10 Quality Records

• Code Review Report

4 Testing

1 Unit Testing

1 Activity Definition

This activity comprises testing each individual software unit against the unit test cases.

2 Objective

The objective is to produce error-free program units, and meeting all the specifications described in the SDD.

3 Entry Criteria

• Unit test cases are base lined

4 Inputs

• Base lined unit test cases

• Developed program unit

5 Outputs

• Test results (optional)

• Tested software program unit

6 Exit Criteria

Unit test results are approved by the PM/Leader or any other person authorised by them for approving the Unit Test results.

7 Standards and Procedures

1. If scheduled in the Project Plan, Unit Testing shall be carried out by the testers, according to the unit test cases and test data.

2. Areas impacted by any modifications in code shall be identified, tested again and properly documented.

3. The unit testing procedure shall be carried out until approval is obtained on the test results from the designated approval authority.

4. Once a unit of software code passes all tests successfully, the test result shall be approved by the PM/Leader or any other person authorised by the PM/Leader in line with the Review Process. The approving authority is identified in the Quality Plan by the PM/Leader.

5. After the testing is complete, the test results shall be reviewed in accordance with the Review Process.

8 Control Mechanisms

All testing are done in accordance with section 3.4.1.7 above. The testing procedure is controlled by means of the Quality Plan. On approval, the software unit is base lined.

9 Approvals

N/A

10 Quality Records

• Test Results (optional)

2 Module/Integration Testing

1 Activity Definition

This activity consists of conducting tests to uncover errors associated with interfacing among sub-systems/software modules. This test is done at sub-system/module level.

2 Objective

The objective is to ensure that no new error crops up as the various objects/program units of a module are integrated, as well as, confirm functional requirements when the modules are subsequently integrated.

3 Entry Criteria

• Program units to be integrated are tested and approved

• Module/Integration test cases are base lined

• Modules are ready for integration

4 Inputs

• Base lined Module/Integration test cases

• Program units / module / software

5 Outputs

• Test results

• Defect Tracking Report

• Tested module or integrated software

6 Exit Criteria

• Module/Integration Test Results are approved

7 Standards and Procedures

1. As scheduled in the Project Plan, Module/Integration Testing shall be carried out by the testers, according to the Module/Integration test cases and test data. The Module/Integration Testing may be merged with System Testing as per the requirement of the project.

2. All the test results shall be noted and properly recorded by the tester.

3. Any result deemed to be a defect, will be recorded by the tester in the Defect Tracking Report. The analysis of the results will be carried out by the PM/Leader or anyone assigned by the PM, and that analysis and/or Defect Tracking Report, if any, will be made available to the QA Group.

4. Areas impacted by any modifications in code shall be identified, tested again and properly documented.

5. The Integration testing procedure shall be carried out until approval is obtained on the test results from the designated approval authority as identified in section 3.4.2.9.

6. Once a module of software code passes all tests successfully, the test result shall be approved by the PM/Leader or any other person authorised by the PM/Leader. The approving authority is identified in the Quality Plan by the PM/Leader and it may include any other subject expert if needed.

7. After testing is complete, the test results shall be reviewed in accordance with the Review Process.

8 Control Mechanisms

All testing are done in accordance with section 3.4.2.7 above and recorded. The testing procedure is controlled by means of the Quality Plan. On approval, the modules are base lined.

9 Quality Records

• Test results

• Defect Tracking Report, if any

• Review Note, if any

3 System Testing

1 Activity Definition

This activity consists of validating the software developed with respect to its functional and environmental requirements.

2 Objective

The objective is to ensure that all the system elements have been properly integrated and allocated functions performed according to the specifications.

3 Entry Criteria

• The software is ready for System Testing

• The software modules / sub-systems have passed the Integration Testing phase

• System test cases are base lined

4 Inputs

• System Test Plan

• Complete software product

5 Outputs

• Test results

• Tested software

• Defect Tracking Report

6 Exit Criteria

• System test results are reviewed

7 Standards and Procedures

1. As scheduled in the Project Plan, System Testing shall be carried out by the testers identified in the Quality Plan, according to the System Test Plan with the prepared test cases and test data.

2. All the test results shall be noted and properly recorded by the tester.

3. Any result deemed to be a defect, will be recorded by the tester in a Defect Tracking Report.

4. The analysis of the results will be carried out by the PM/Leader or anyone as assigned by the PM, and that analysis and/or Defect Tracking Report, if any, will be made available to the QA Group.

5. Areas impacted by any modifications in code shall be identified, tested again and properly documented.

6. The System testing procedure shall be carried out till the approval is obtained on the test results from the designated approval authority as identified in section 3.4.3.9.

7. Once a module of software code passes all tests successfully, the test result shall be approved by the PM/Leader or any other person authorised by the PM/Leader. The approving authority is identified in the Quality Plan by the PM/Leader and it may include any other subject expert.

8. After testing is complete, the test results shall be reviewed in accordance with the Review Process.

8 Control Mechanisms

All testing are done in accordance with section 3.4.3.7 above and recorded. After review and approval of test results, the software is base lined.

9 Approvals

Review and approval of system test results.

10 Quality Records

• Test results

• Defect Tracking Report

4 Acceptance Testing

1 Activity Definition

This activity comprises testing the software for customer acceptance, (generally at the installation site), by the Project Team (and also by the Customer, in general) at the Customer's actual operation environment. Acceptance tests may also be carried out at the software developer's development site, depending on the specific project scope. There may be situations where Acceptance Testing is not carried out at all, again depending upon the scope of work in the project and the acceptance criteria of the project.

2 Objective

The objective is to ensure that the software developed fulfils the customer's stated and implied needs.

3 Entry Criteria

• Software is ready for acceptance testing and all previous tests are successfully completed

• Acceptance test plan is approved

4 Inputs

• Base lined acceptance test cases

• The software system has passed through the System Testing phase and is ready for delivery/handover to the users for operation

5 Outputs

• Test results

• Defect Tracking Report

• Acceptance from customer, if any

6 Exit Criteria

• Test results are approved

• Acceptance is obtained from customer, if feasible

7 Standards and Procedures

1. As scheduled in the Project Plan, Acceptance Testing shall be carried out by the testers, according to the acceptance test cases and test data. Acceptance test cases may be prepared by the Customer and testing may be carried out by the Customer.

2. All test results shall be noted and properly recorded by the tester.

3. Any result deemed to be a defect, will be recorded by the tester in a Defect Tracking Report. The analysis of the results will be carried out by the PM/Leader or by anybody as assigned by the PM, and that analysis and/or Defect Tracking Report, if any, will be made available to PQA.

4. Areas impacted by any modifications in code shall be identified, tested again and properly documented.

5. The acceptance testing procedure shall be carried out until approval is obtained on the test results from the designated approval authority as identified in section 3.4.5.8.

6. Once a software system passes acceptance test successfully, the test result shall be approved by the PM/Leader or any other person authorised by the PM/Leader or Customer representative(s).

7. After testing is complete, the test results shall be reviewed in accordance with the Review Process.

8 Control Mechanisms

All testing are done in accordance with section 3.4.5.7 above and recorded.

9 Approvals

Review and approval of acceptance test results.

10 Quality Records

• Test Results

• Defect Tracking Report

• Acceptance from customer, if feasible

5 Replication, Final Inspection, Delivery and Installation

1 Activity Definition

A procedure that identifies the needs for control of performing replications of software deliverables, maintaining proper backup of the deliverables, accurate identification, final inspection of the deliverables before the release and installation of software at the Customer's site.

2 Objective

To put the developed software into use.

3 Entry Criteria

• Developed software

4 Inputs

• Developed software

5 Outputs

• Software with all the documentation as agreed with the User/Customer

6 Exit Criteria

• User acceptance

7 Standards and Procedures

1. Prepare a checklist of deliverables to be released.

2. Validate the final release according to the requirements of the project.

3. Verify that all required documentation is available.

4. Verify that the documented test results provide clear evidence of product conformance to the specified requirements.

5. The user manual or equivalent shall be prepared, which details out the features/requirements related to the product and provides necessary operation instructions. The user manual or equivalent shall be reviewed and base lined. The user manual may be prepared in parallel with the prior phases.

6. Verify that all the deliverables are base lined.

8 Control Mechanism

All the deliverables are base lined and released from the baseline folder.

9 Approvals

N/A

10 Quality Records

• Checklist (optional)

6 Implementation

1 Activity Definition

To install and configure the developed software and subsequently impart training to the end user.

2 Objective

To put the developed software into production.

3 Entry Criteria

• Software is released to the customer

4 Inputs

• Application software / product

• Users manual

5 Outputs

• Users acceptance

6 Exit Criteria

• User acceptance / Sign off

7 Standards and Procedures

1. Installation of the software on proper hardware.

2. Configuration, as required.

3. Check for successful execution of software.

4. User training as agreed with the User/Customer.

8 Control Mechanism

N/A

9 Approvals

Customer sign off as applicable.

10 Quality Records

• User acceptance / customer sign off

7 Post Production Support and Maintenance

1 Activity Definition

To assist user in phasing out the old system, fixing bugs if any, data posting and user training.

2 Objective

To provide support for the smooth running of software as agreed with the User/Customer.

3 Entry Criteria

Support request from customer (any media, even a phone call/email)

4 Inputs

• Support request from the customer

5 Outputs

• Closure of the customer request

• Updated Issue / Defect / CR Log

6 Exit Criteria

• Closure of customer request

• End of the support period as per agreement with the User/Customer

7 Standards and Procedures

1. Upon receiving the support request from the Customer, the Issue Log is filled.

2. Impact Analysis is done.

3. If required, a change request is raised and handled according to the Configuration Management Process.

4. It the Customer reports a defect, then the Defect Tracking Log is updated and the defect is handled according to the Configuration Management Process.

5. If the Customer reports an issue which is neither a defect nor a CR, then the PM resolves the same by meeting / discussing the issue with the Customer as per the agreement, or else escalates the issue to Senior Management according to the Project Management Process.

8 Control Mechanism

N/A

9 Approvals

As applicable

10 Quality Records

• Impact Analysis Report

• Test results or Review Reports as applicable

Glossary

|SCCB |Software Change Control Board |

|CI |Configuration Item |

|CM |Configuration Management |

|JAD |Joint Application Development |

|PM |Project Manager |

|PP\PMP |Project Plan\Project Management Plan. |

|QA |Quality Assurance |

|SEPG |Software Engineering Process Group |

|RAD |Rapid Application Development |

|RTM |Requirements Traceability Matrix |

|SDD |System Design Description |

|SDLC |Software Development Life Cycle |

|SLC |Software Life Cycle |

|SMLC |Software Maintenance Life Cycle |

|Software Process |The process of development and / or maintenance of a Software system. |

|Software Process Model |The abstract representation of the software process. Synonymous with Software Life Cycle Model. |

|SRS |Software Requirements Specification |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download