Software development lifecycle

The procedure for executing a modification follows the development process i.e. all phases of the software development lifecycle have to be repeated for any part of the system im-pacted by the change. This means that the modification is carried out according to the (many) rules for good (error-poor) development of software (as e.g. laid down in chapter 5 of / /). 

An example of an application software development lifecycle using an lEC 61508 series SIL 3 compliant PLC is given in Annex D. 

In the proposed BBN, as a general principle, we model the rigour of application of any method (its effectiveness), in terms of two subsidiary concepts the inherent power to do the job ( power of build/verification method i nodes) and the intensity of its application ( intensity at which build/verification method i was applied nodes). The multiple node notation presented in Figure 3 indicates that every phase of the IEC61508 safety software development lifecycle has one or more build and verification methods, the precise number of nodes depends on -... 

Figure 3 - Generic BBN Flat structure for one phase of the safety software development lifecycle.

The Quality of the verification process... nodes take values from a discrete set of values such as very poor, poor, medium, good, very good. Estimations of their values are made, based on the rigour at which verification methods were applied and their relevance. The relevance of the verification method j for phase i node effectively selects the verification processes that are relevant to previous phases of the software development lifecycle. 

Yeo, A. Global Software Development Lifecycle an Exploratory Study. In Jacko, J., Sears, A., Beaudouin-Lafon, M., Jacob, R. (eds.) CHI 2001 Conference on Human Factors in Computing Systems, pp. 104-111. ACM Press, New York (2001)... 

User-centered design is not just about building nice-looking and usable user interfaces, and software development is not just about implementing functionality that supports user tasks. Belonging to different traditions and times, the disciplines of software engineering (SE) and human computer interaction (HCI) have evolved separately and developed their own methods to meet the needs of software application customers and users. Over the last twenty years, especially, several practices have been developed in both communities. This illustrates the human-centered perspective s influence on the software development lifecycle. Stakeholder involvement in the requirements elicitation process and evolutionary process models [39], which enable iterative construction of the application software to best meet the user requirements, and the widespread use of prototyping by the HCI community are examples of the approximation of both disciplines [31]. 

Ferre, X., Juristo, N., Moreno, A. Which, When and How Usability Techniques and Activities Should be Integrated. In Seffah, A., GnUiksen, J., Desmarais, M.C. (eds.) Human-Centered Software Engineering - Integrating Usability in the Software Development Lifecycle. Human-Computer Interaction Series, vol. 8, Kluwer, Dordrecht (2005)... 

Software development processes can depend on the organisation, context of the project, scope of the project, and so ow This guidance identifies four major phases (Initial, Development, Containment and Acceptance) which can usefully be mapped to all software development projects. These identified phases are not intended as a software development lifecycle, but rather to identify the key decision points relevant to DS 00-56 which occur during contractual interactions. They are orthogonal to the swim-lane strands introduced in Section 2. Figure 1 shows this interaction. 

In order to reveal and remove faults that already exist in the software, verification is recommended throughout the development lifecycle. Typical approaches are described in 12.7.2.3. 

A key concept of the lEC 61508 as mentioned before is the implementation of a safety lifecycle that includes hardware and software development life cycles for the safety functions. The AOP 52 recommends the usage of a lifecycle during development of hardware and software. One can say that there is a basic correspondence between the key concept of using process models for the development of safety critical systems. 

IEC61508 system development is structured into three safety lifecycles the overall, the E/E/PES, and the software. Only the software safety lifecycle is addressed in this paper. Figure 1 illustrates the software safety lifecycle as it is presented in IEC61508-3. 

The activities of the software safety lifecycle are organised into a number of phases including safety requirements specification architecture design selection of support tools and translators detailed software design and coding module and integration testing In each phase there is a verification exercise that aims to find errors introduced in the development process. 

The software safety lifecycle phases are ordered according to the well known V diagram for software development, see Figure 2 for more detail. 

In order to model the software safety development lifecycle a larger BBN is needed to combine estimations from individual phases. We propose that this larger network should feed forward the quality of the development process of each single phase, since the subsequent development work will depend on that quality. The network also should have a feedback connection so that errors found in later phases have an impact on the contribution to the estimated SIL from a previous phase. 

Fenton N E, Neil M, Marsh W, Krause P and Mishra R (2005b). Predicting Software Defects in Varying Development Lifecycles using Bayesian Nets, submitted to ESEC 2005. 

ANSI/ISA-84.01-1996 requires that the application software be developed in accordance with the Safety Requirements Specification (SRS). ANSI/ISA-84.00.01-2004-1 also requires this, but discusses the development of the application software with relation to the safety lifecycle. Where hardware is prone to random failures, the software is more prone to systematic failures. The safety lifecycle is important, because it is the primary mechanism for reducing systematic failure. The inclusion of the lifecycle discussion in the software section does result in repetition of the design process described in ANSI/ISA-84.00.01-2004-1 Clause 11. This repetition is intended to highlight the importance of the lifecycle in the development, verification and validation of application software. ISA-TR84.00.04-1 Annex O provides a discussion of the evolution of application software development. 

We must therefore seek to understand why more formal approaches to software development have not generated the unstoppable momentum of UML or visual programming and, from this, find ways of injecting formality into the earlier stages of the software lifecycle where it will do most good. 

It is very important to recognize that the Overall E/E/PE System Safety and Software Safety Lifecycle figures are simplified views of reality and as such do not show all the iterations relating to specific phases or between phases. Iteration, however, is an essential and vital part of development through the Overall E/E/PE System Safety and Software Safety Lifecycles. 

The project execution layer is typically controlled by some product development lifecycle model (PDLM). Some PDLMs widely used for software development are the Waterfall model, Spiral model, Agile model and the Unified Process. Due to the large variety of businesses and products within the ABB Group one cannot find one single development life cycle model which is actually being used company-wide. Through the years, each business unit adopted its own approach based not only on the type of product but also on several other factors like market type, country, early company know-how, past experiences, development team culture, etc. 

There are no clearly defined design elements for hardware and software development to manage complexity of a safety development project. Although system, subsystem, component and module are used in the SLCM, there is too much interpretation freedom, which leads to uncontrollable uncertainty and difficult in specifying the required outputs of each safety lifecycle phase. 

To address the design constraints we have selected several safety development projects with different hardware and software complexity in order to collect inputs, and to understand the related domains, the corresponding problems, needs and development environments. They are also used to verify our SLCM. In addition, we have used the functional safety initiative of the automation product division (one of five ABB divisions) as a platform to collect the related experience and knowledge in the safety development to ensure reusability of our SLCM. To guarantee the conformance we had our SLCM assessed by TUV in the context of the certification of our FSM Add-on [6], which includes our SLCM. Fig. 2 illustrates our development strategy. As input for the development of our SLCM we also referred to different development lifecycle models such as V-model [12], RUP [11], Harmony [13] and the best practice, knowledge and experience [4,5,13,14]. 

Additional vulnerability classifications are the Microsoft Security Development Lifecycle (SDL) [16] and the CWE (Common Weakness Enumeration). The CWE is a detailed and community-developed list of common software weaknesses. 

---