Software life cycle activities

The software life cycle activities extend until retirement of the software. However, in a manner of speaking, life cycle activities extend even beyond retirement since the data must be able to be reconstructed at any time during the life of the product, i.e., the archived record must always be accessible and readable even if the software is no longer commercially available or typically employed in the laboratory. Additional software validation includes implementation of the code and integration and performance testing. There also must be system security, change control procedures, audit trails, calibration, preventative maintenance, and quality assurance. 

Specific Development Activities. Software life cycle activities related to system safety engineering include the following ... 

We should now look more closely at the basics of the software life cycle activities. We begin by sorting out the main features of SIS software activities. For this we need to understand the architecture terms and relationships used in the lEC standards. 

Guidances recommend an integration of software life-cycle management and risk management activities. Software validation and verification activities must be conducted throughout the software life cycle [12,14]. Software verification and validation are terms frequently confused. Software verification is defined as the process that provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase... 

For GMP applications the software development must be based on a fully documented and structured design and formally reviewed to ensure that it is reliable, safe, testable, and maintainable. A modular approach to software design with annotated documentation will provide a better understanding of the system software throughout the relevant life-cycle activities and also during regulatory inspection. Use of standard software should be considered whenever possible. 

Verification in software development refers to a process for providing objective evidence as to whether the software and its associated products and processes conform to requirements, satisfy standards, and successfully completed each life-cycle activity. 

A process model is an ideal definition of the software life cycle or of how actual software projects work. As such, they are prescriptions for how to organize the software engineering activity. In reality, actual software projects deviate from these models but the models nevertheless give both managers and engineers a framework in which to plan and schedule their work. 

This view is more conq)lex than previous process-based attempts to capture software reliability using BBNs. It takes the view that a phase is associated with a set of processes (e.g. a requirements specification), and these processes are subject to active updating for the duration of the project due to work in later phases. This approach allows us to capture intricate influences between phases . The generic BBN structure shown in Figure 4 presents a sub-net for each phase of the safety software life-cycle and a net for interaction among phases. The interaction net aggregates integrity estimates from multiple phases. 

In Fig. Vlll/2.0.3-2 the V model approach for system software as per lEC 61508 is shown to focus on the software development process in safety applications. The international standard makes the generic approach for all safety life cycle activities for... 

We have noted that certification must cover the hardware and diagnostic performance capabilities as specified by lEC 61508. Certification must also cover the software engineering life cycle activities leading to the embedded software as well as the programming tools supplied for the end user. 

The full scope of software safety life cycle activities is beyond the scope of this book. However, we need to understand what is required of the project engineer and the designers involved in practical applications. So here are some key points seen fi om the position of the end user. 

The above sequence will of course be supported by documentation of the software and the testing procedures. Test procedures derive from the planning and validation activities specified for the safety life cycle activities. Documentation of the software will be supported by the PC based workbench as far as possible. 

This last type is widely used for the final testing in conjunction with the development system serially linked into the SIS logic solver. We should bear in mind that the software development life cycle activities will have utilized emulation of the plant signals during the software integration tests. (Refer to Chapter 10 of the workshop.) These tests will have extensively tested the application logic before it was brought to the FAT. Hence it... 

More companies are incorporating life-cycle costs and life-cycle assessment into their operations. The U.S. Air Force has developed a computer-aided software-engineering tool, for defining the complex sets of interacting activities in the life cycle of an aircraft. 

The effect that verification and testing activities have on financial resources is noticeable. A potential saving of 50% on software maintenance can make a sizeable impact on overall life cycle cost. 

System vahdation is employed as a mechanism to estabhsh objective evidence that a system consistently performs according to its predetermined requirements, specifications, and quality attributes. The GAMP software categories provide some guidance as to activities that should be followed as a minimum to provide the objective evidence of the system meeting performance objectives. The complexity of the computerized system should determine the extent of this effort. There are many life-cycle models published that fadhtate the creation of this objective evidence. Acceptable life-cycle models will include phases for Define, Design, Develop, and Operate. 

Evidence of sufficient control of these issues should be demonstrated in the validation documentation. Compliance must be integrated using a formal methodology and an appropriate system life-cycle approach that is clearly identified in the user requirements phase for any new computerized systems. The priority for validation activities can be established by analyzing the control scheme system and subsystem inventory for the criticality, validation stams, software category, and system type. This analysis aids validation planning and prioritization. 

Computer system validation activities will occur both during as well as at the end of the database development life cycle. Successful validation is highly dependent upon a comprehensive approach to specifications, reviews, installation, inspections, analyses, and testing of both the system hardware and software. 

Life cycle forms are generic frameworks used in systems engineering to manage the development and maintenance of complex systems. These forms have been developed for the needs of software engineering, but can be applied to other complex activities, as for example car production or architectural works. The life cycle forms are also suitable to capture the formalism of organising a team work devoted to achieve an objective in short time with high degree of reliability. 

The U.S. Food and Drug Administration (FDA) published a technical report on software development activities in 1987. While under revision, its content is still very relevant and covers basic expectations for software development practices. A simple life cycle is described the requirements phase, the design phase, the implementation phase, the test phase, the installation and checkout phase and the operation and maintenance phase. The technical report also has some appendices covering firmware and software test methods. 

Although we have asserted that the design phase is the center of gravity of the life cycle, programming activity lies at the very heart of software development. For this reason, it is important that the auditor pays attention to the individuals involved and the standards by which they work, since both have an important bearing on the quality of the code produced. 

---