The Software Development Life Cycle

The auditor has to ensure that the hardware manufacturer or software integrator is working to a life cycle and has documented this work. Most hardware manufacturers already have a stage-wise, documented approach to engineering operations and are therefore usually receptive to the need for 

The life cycle description should be as simple as it can be while still being adequate as a working description. It should describe the contents of the document delivered at each stage. Details of the suggested contents of the User Requirements Specification (URS rarely used by hardware manufacturers), the Functional Specification and the Software Design Specification (SDS) are 

We have implied that the design specification is based on the functional requirements. However, both the importance of ensuring this and the way to achieve it simply are seldom understood. All of the functional requirements must somehow be catered for in the design. This applies no less to what the system must do as to what the system should not do. Failure to achieve this is one of the most common causes of the most fundamental defects of delivered systems, those errors that are, in general, the most expensive to rectify. Ensuring such comprehensive scope in designs is one of the responsibilities of QA, of which more will be discussed later. In the meanwhile, a simple but reliable system of document traceability must be in place to enable QA to sign off the document for comprehensiveness. 

Any life cycle worth its salt should deliver at least the following foundational documents  

Functional Specification Design specification Source code 

---

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... 

Standards for work conducted, including the software development life cycle to be used, and the documents to be delivered by it... 

As part of the software development life cycle of the custom/bespoke or modified software, it should be subject to SCR. This is another means of building quality into LIMS. When conducting an SCR, the source code should be reviewed against the agreed design and Good Programming Practice (GPP). Particular emphasis should be applied to the software deemed as GxP critical. 

The underlying code of the generic shell that comprises the tool should be developed according to the software development life cycle. Depending on the degree of sophistication of the system, testing should cover the following areas of functionality ... 

A configuration management plan shonld be established to outline the process to be followed to ensure that configuration and version control is established for the software, development tools, and supporting docnmentation that are nsed. This will enable accurate configuration baselines to be taken at specified points in the software development life cycle. 

Establish and document the standards to be used for all Web site development following the same approach used for other coding standards within the software development life cycle. 

Computer Aided Software Environments (CASE) Tools designed to support the analysis and design phases of the software development life cycle. The tools are usually oriented toward the support of graphical notations. [Defined for this book.]... 

It is useful to understand the steps of the software development life cycle (SDLC) during a project. In fact, this approach is commonly used for implementation and validation even when commercial off-the-shelf software is involved [104]. It is also important to consider the economic aspects of the automation project [105]. A 10-step guide to success that emphasizes clearly defined project control in outsourced automation/information technology projects has been published [106]. 

The aforementioned procedure covers an entire lifetime of software, which is usually referred to as the software development life cycle (SDLC). In particular, commercial software development underlies certain regulations that are compiled as a set of standards. Several models can be applied to form a formal point of view. One of these is the V-model its name is derived from the shape of the graphical representation used to describe the required processes (Figure 8.1). 

For each phase, design documents of safety systems, based on SRP BTP-14, of the software development life cycle, include software plans, software requirement specification, software design output, source code listing, and test reports. These documents are subject to the IV V review. 

In addition to the need for calibration to deal with local circumstances, a problem with the COCOMO-type approach is that the number of lines of code that an application will require will be difficult to assess at the beginning of the software development life cycle and will only be known with certainty when the software has actually been coded. Lines of code are also difficult for the user community to grasp and thus validate. 

The principal activity of software engineering is the production of software. There are a number of different approaches to developing software, and the best way to understand these approaches is to study the software development life cycle for each approach. 

Waterfall ModeL The waterfall model of software development is characterized hy a sequential software development life cycle. The key characteristic of the waterfall model is that each step of the software development life cycle is completed before going to the next step. The first step is to perform an initial study of the problem to be sure it is feasible. In the second step, a detailed analysis of what the project entails is completed. This is one of the most important components of the waterfall model and often uses a specialist called a systems analyst. In the third step, the information contained in the systems analyst s report... 

Knowledge of the software development life cycle is needed to understand software reliability concepts and techniques. Several life cycle models have been developed over the years from the code-and-fix model to the spiral model. We will describe two such models, which have found a wide variety of applications the waterfall life cycle model and the spiral model. 

SPIRAL MODEL OF THE SOFTWARE DEVELOPMENT LIFE CYCLE... 

Table 1 only shows some important dependencies used in Section 5. A comprehensive version can be found in our technical report [6]. The next step in the software development life-cycle is to derive a specification, which describes the machine and is the starting point for its development. 

CASE is the use of software tools to assist in the development and maintenance of software. All aspects of the software development life cycle can be supported by software tools therefore, the use of tools from across the spectrum can be described as CASE, from project management software through tools for business and functional analysis, system design, code storage, compilers, translation tools, test software, and so on. 

Allocated to the framework specified in ISO/IEC 15504 Part 5 the core and support processes depicted in Figure 3 result for the software development life cycle in accordance with the V-Model. 

Figure 3 shows the software development life cycle which is divided into the three phases of concept confirmation, implementation and testing. The concept confirmation phase includes the processes of requirements development and software design. The software requirements will be derived from the system requirements and the system design. They include functional, performance and interface requirements. Inputs for the software requirements are ... 

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... 

---