Adaptive Software Development for Developing Safety Critical Software

Transcription

1 Adaptive Software Development for Developing Safety Critical Software Adil A Abdelaziz, Yaseen El-Tahir, Raheeg Osman Faculty of Computer Science and Information Technology, Faculty of Computer Science and Information Technology, Faculty of Computer Studies, Al-Neelain University Sudan, Al-Neelain University Sudan, International University of Africa Sudan I. Abstract Developers of safety critical software are becoming increasingly interested in using the agile methods. If an agile approach successfully applied in safety critical applications, it must show that the resulting software system is sufficiently safe to operate. This paper describes an approach which tries to address such needs. It identifies a need for a systematic, iterative method. The proposed approach uses the concept of safety modular decomposition to carry out the safety process in the system and safety backlog to manage the safety requirements. An analysis process, which can be used to generate better solution through the iterations, is described. The use of this approach to construct a safety argument is demonstrated. The approach has promised results and could lead to an acceptably safe system developed by using the Adaptive Software Development model (ASD). II. Introduction Safety systems are becoming increasingly needed in many aspects of life such as medicine and avionics. Appearance of any problem in these domains is not acceptable, because it s very delicate and sensitive to mistakes. Safety is an attribute of a system that means the system is free from accidents. It s concerned with preventing foreseeable accidents and minimizing the results of unforeseen ones [1]. There are many examples of critical systems wherein single failure could lead to an accident. Critical systems are most often found within the domains of aerospace, rail, automotive and medical sectors as well as in industries such as manufacturing and nuclear. Such systems have been existed in one or another form since the industrial revolution. As a result, a body of knowledge and expertise has grown up around their development to reduce the risk of accidents. A more recent development approach has used computers as part of these systems. Computers are integrated into the operation of control systems to enhance performance or increase efficiency. Such systems are often referred to as safetycritical systems, as their failure may lead to an accident. The software that executes on these computers plays a crucial role in ensuring the safe operation of the system. Errors in the software, which may appear at first sight to be minor or even trivial, could result in catastrophic consequences. This is illustrated quite clearly using the example of the Ariane /15/$ IEEE Adil.sudan@gmail.com aseny013@gmail.com yaseenraheeg@gmail.com accident, Toyota Prius. The safety requirement for safetycritical systems is more important than or at least as important as functional requirements. However, every domain has its own standards of safety; therefore the process of development is affected by these standards. There have been several studies on the use of software development life cycles, a comparative study made by Bohem & Papaccio [2] between traditional and agile methods have concluded that traditional development lifecycles are more suitable for developing safety-critical systems. The use of agile methods for developing critical systems is still a research area. A study conducted by B. Bahli and ESA Zeid [3] found that the development team using the waterfall model to be an unpleasant experience, while XP (an agile method) was found to be beneficial and a good move from management. The XP project was delivered a bit less late (50% time-overrun, versus 60% for the traditional), and at a significantly reduced cost overrun (25%, compared to 50% cost overrun for the traditional project). Agile development involves less cost of development as rework, management, documentation and other non-development work related cost is reduced. This research argues that safety-critical systems can be developed using an agile method. Besides, there is no problem in carrying out the safety-critical life-cycle systems incrementally. Consequently, the paper proposes a method to improve process of developing critical systems by applying The Adaptive Software Development (ASD) to the development of safety critical systems. After demonstrating the possibility of handling safety lifecycle incrementally, the paper will show how the researchers mapped the safety life-cycle on the ASD framework. After that the third part shows will discuss the process of building up-front design. Then fourth part shows how to manage the requirements using the concept of safety backlog [4]. Agile methods have their own complexities. This paper will focuses on mapping the safety development process to ASD and the up-front design of safety-critical and the process of iterative development of the system and its safety arguments. The researchers are not trying to prove that the traditional methods are bad; rather there are different uncovered ways 41

2 that might be better to develop critical systems. III. Background For a system to be considered safe all the hazards associated with it should either be eliminated or reduced to an acceptable level. Software it part of that system and can be considered safe only whit in the context of a particular system, if the same software was taken and reused in another system and behaved in the same way it might contribute to a hazard and cause an accident. A. Safety-critical software development processes The typical process of developing a safety-critical software system is generally time-consuming. Most such processes are based on the V-model, which is illustrated diagrammatically in Figure 1. This model identifies the major elements of the development process and indicates the structured, and typically sequential, nature of the development process. The sequential nature of development is generally considered essential for reasons of managing communication and scale, for scheduling different phases and disciplines, for managing traceability (which is mandated by relevant safety standards) and for the last phase in the life-cycle is certification, which is often the most important concern of the critical system development process [6]. The core differences between Agile and plan-driven processes are as follows. 1) Plan-driven processes have an up-front design (including the analysis activity). Instead of planned design, the design in Agile processes is evolutionary. Compared with plan driven processes, the shape of the system rather than its detail are designed at the beginning of an Agile process, which makes up-front design in an Agile process lighter. 2) In plan-driven processes, implementation is normally a monolithic activity, which also entails a monolithic testing phase. In an Agile process, implementation (and hence testing) is iterative and incremental [6]. IV. Previous studies The use of modular safety arguments was proposed [5] to allow safety arguments to be developed in terms of modules with argument dependencies. This approach divides the safety arguments into separate modules that can be developed individually with argument dependencies meaning that each module can be developed individually. An example of a modular argument structure is shown in figure 2. Instead of the monolithic approach that is used in Figure 1: V-model B. Agile Models Agile models are a family of development processes which are lightweight methods that minimize the requirement analysis and software design phase. Typical Agile development methods include extreme Programming (XP) Feature Driven Development (FDD), Scrum, and Adaptive Software Development (ASD). These methods are faster in development than the traditional methods like the V-Model. 42 Figure 2: modular argument decomposition the usual safety development process. the use of modular decomposition and up front design was proposed in [6], the systems safety module were derived from a minimal up front design, and based the number of safety modules the number of iterations was determine by adding one to the number of safety modules to create the final interaction module. There was another study [4] that proposed the adaptation of the agile method scrum to develop safety critical systems, what was very notable from that study is the safety backlog, in scrum the requirements are managed maintained and tracked in backlogs, they made use of the same backlogs and created a safety backlog to maintain and manage the safety requirements, with traceability between the functional and safety requirements. These previous studies

3 contributed to changing the process of developing safety process from a liner monolithic approach to a more non liner process. The safe scrum [4] customized the scrum model to fit the safety development process, in this paper the researchers will do the same, but will apply the ASD method which is in the researchers perspective is better for developing safety systems. V. Proposed Solution Developing safety-critical systems is not just a process of producing software, but also providing evidence that the produced software will not cause or contribute to any hazardous situations, and the process of producing such evidence should be carried out concurrently with the software development process; so in order to produce a safe software incrementally the process of creating evidence must also be carried out incrementally. There are two aspects to the solution proposed, the first is to create an upfront design that is sufficient enough to serve as an input to the safety argument building process and secondly mapping the safety argument development process to the ASD. 1- In agile development methods, there is usually a form of up-front design. This design is normally is incomplete and is a high level abstract description of the software architecture, and it does not dwell into the details of the design of the system because the systems detailed requirements not known yet. However, when it comes to safety-critical systems, the design needs to be detailed enough to serve as input to the safety argument building process. The hazards associated with each domain are well known and documented and the people who carry out the hazard identification process are domain experts. Therefore, most of the hazard identification process is done by brainstorming or checklists. In the early stages of safety critical development, the preliminary system safety assessment is based on an architectural model of the system. Thus, an up-front plan for safety critical software development must include not only up-front architectural design but also up-front hazard analysis, as the design gets more detailed the hazard analysis evolves with it. The challenge here is to lighten the up-front requirement and design process, while still gathering enough information to serve as input to be able to at least identify and asses the risks associated with the certain system. To be able to know such a thing requires a criteria to measure against, but to define a general criteria is very difficult because in different domains different safety analysis techniques are used, and each requires different information The information always comes from the experience of safety engineers or historical data, not directly from the functional design of the system. To do FMEA or HAZOP analysis, engineers not only need to know the system structure, but also the information of the effect of a failure on other components, which sometimes comes from a detailed design of components. We thus claim that, for an agile safety-critical software project, the up-front design should produce at least a system architecture model as well as functional requirements for each component, along with a priority. 2- There are generally six phases/processes in the safety life cycle: 1- Hazard Identification 2- Risk Assessment 3- Preliminary system safety assessment 4- Common cause analysis 5- System safety assessment 6- Certification The safety development process first starts with the hazard identification process and in this process all the hazards related to the specific system should be identified and no hazard should be left out for its consequences can be very catastrophic. And the second process is the risk assessment process where each and every hazard is given a degree of risk the higher the risk the more dangerous it is. The third phase is the preliminary system safety assessment, in this phase after the hazards have been identified and assessed the causes of the failures are identified and safety requirements are elicited to prevent or control possible causes of failure. The fourth phase will be skipped for now and we will discuss the fifth phase which is the system safety assessment, once the design is implemented it is necessary to confirm that the safety requirements elicited from the preliminary system safety assessment have been met, and this is where such a process happens. The fourth process is which is the common cause analysis is used throughout the whole development lifecycle it is used to support both the preliminary system safety assessment and the system safety assessment. A lot of safety analysis techniques assume that failures are independent of each other, if that assumption is not true and there is fact a common cause then the safety integrity of the system will be broke. The ASD framework shown in figure 3 was identified as a very good vessel to carry out the safety critical software development process, as that it is perfectly suited for carrying out the safety process with the software development process. The figure shows the three conceptual phases of the framework, firstly the speculation phase, then the collaboration phase, and finally the learning phase. 43

4 Figure 3 ASD framework As mentioned earlier that the paper will discuss the mapping of the safety development process to the ASD framework and the mapping is suggested as followed: The speculation phase: this phase is made of two stages the initiation and the adaptive cycle planning stage as shown in figure 4. The first stage is the initiation, it is the first step in whole development life cycle, and this stage is only carried out once at the beginning of the project, here the projects requirements (functional and safety) should be gathered in enough detail to serve as input to the project plan and software architecture, to serve as input to the The second stage is the adaptive cycle planning stage, after finishing the initiation phase, the produced outputs from it act as input to the planning, based on the initiation output a time box can be established for the whole project based upon the scope and the available resource, the speculation phase does not mean to abandon planning and estimating, but just gives us space to work under the fact that we don t have complete control over everything or know everything, and to change plans without fear. This stage is revisited after completing an iteration cycle, at the beginning of each the plan can be modified based on the projects status. The collaboration phase: In this phase the actual development of the software begins, here the requirements are gathered in more detail by the developers and the use of requirement backlogs from scrum [7], and safety backlogs is recommended. The numbers of development cycles are determined by the number of modules that are formed by the modular decomposition. Each module will be a development cycle. By the end of each cycle a software module with the evidence of its safety should be generated. The safety process activities that will take place in the phase are the PAAS and common cause analysis processes, depending on the type of project at hand the most suitable safety analysis techniques are going to be used, the resulting outputs of the process is going to feed the next phase in this model. The learning phase: the last phase in the cycle is the learning phase, this phase main point is to assure the quality of the produced software and its associated evidence, and to review the plans progress and if any problems need to be handled, as the output will be fed to the adaptive cycle planning stage again if the current cycle wasn't the last cycle. This stage has two stages as seen in figure 2 but the second stage is not visited only on the last cycle or iteration as shown in figure 5 there are two stages in this phase, the quality review stage and the final quality assurance and review stage. Figure 4 speculation phase Preliminary System Safety Assessment PAAS activities, also the hazard identification process should be carried out and the hazards risks should be assessed at this stage. Requirements should be gathered in a workshop or series of workshops with the project manager, the software analyst, the software architect, and the safety engineer, and the other stakeholders as participants, to get the functional requirements and build an architecture for the software based on that a safety modular argument will be produced and based on it the number of iterations will be determined. 44 Figure 5 learning phase In quality review stage managerial reviews and technical

5 reviews are carried out, and during the final quality review and assurance the more testing on the product is carried out on the software, and the safety case should be delivered. The learning phase forces on the technical and managerial aspects, from the management perspective issues of time, cost and other managerial issues are consider and also if there are any complications faced by the team during the previous phase. And regarding the technical reviews the produced product should be tested and the safety arguments reviewed to ensure that the safety requirements for this increment are met, the System Safety Analysis (SSA) process is carried out to ensure this, and the appropriate techniques should be used depending on the project type, and during the SSA process the safety argument for the system is developed so by the time the last iteration is reached the safety argument should be complete. What this proposed approach makes possible is the ability to develop safety systems in a concurrent manner which will in turn decrease the time required to develop these systems dramatically. There were other studies performed on adapting agile methods to safety critical software development, but as far as the researchers knowledge there was never an attempt to adapt the ASD framework to develop these systems, the researchers believe that this method is the most suitable method for the development of such systems because of its structure that fits the nature of the safety-critical systems in a very good way. Although this process is not entirely agile it is a step in the direction of improving the development process of the safety systems, to apply an agile method completely to the development of safety systems is very difficult because of the certification process, but by applying some of the agile practices can improve the process of the safety development one way or the other. VI. Results In an attempt to evaluate our approach, the researchers selected an avionics software application which is a safetycritical system. It makes an excellent test ground for the proposed model; for avionics require a high system integrity level for an mistake can lead to a severe incident. the application selected is an integrated altitude data display system. It is responsible for providing pilots with accurate and understandable altitude data during flight. It also must provide audio and visual warnings whenever specified altitudes are reached. The steps of the proposed model were applied to this application. And the researchers were able to apply the proposed model to the application in focus. This was carried out in a non-production environment, with a small application. VII. Discussion The researchers were able to apply the model to the selected application, it was found possible to apply the proposed model to the development of such systems. However the results are inconclusive, because this was not tested in a real production environment where lots of things can go wrong. Besides, there are areas in this model that have not yet been considered, science there are a lot of stakeholders from different engineering disciplines, managing all of them in such a process will need to be considered. Basically the model is applicable in a small scale application, but still isn't tested on real production environments to determine its applicability and its effectiveness on such environments. What the researchers believe is that if the process was carried out successfully on a small application it could be carried out on a bigger scale, though there might be some issues, but surely they will not be impossible to tackle. VIII. Conclusion Agile methods have many advantages, and these advantages are attracting software engineers from all disciplines including engineers from the safety domain, if there were to be successfully applied to the safety domain lots will be benefited from them. In this paper proposed the use of ASD and some other development techniques were put together to enable the development of these systems in an agile way. The proposed proposition was applicable to in a non-production environment, but still the extent of applicability and effectiveness of the proposition is to be tested in real production environments. It was clear that the proposed method can be applied to the development of safety systems and reduce the time required substantially, although this proposed is not fully agile the researchers believe that it is a better approach to developing safety systems. This is just a step forward in the improvement of the development process of the safety systems. The researchers are planning to carry out the proposed model in a real production environment to come up with more concrete results, and also are planning to discuss this proposition with practitioners in the field and with other researcher. 45

6 References: [1] Ian Sommerville, Software engineering ninth edition 9th ed., [2] Boehm, B. W., & Papaccio, P. N. Understanding and controlling software costs. Software Engineering, IEEE Transactions on, 14(10), (1988). [3] Bahli, B., & Zeid, E. A. (2005, December). The role of knowledge creation in adopting extreme programming model: an empirical study. In Information and Communications Technology, Enabling Technologies for the New Knowledge Society: ITI 3rd International Conference on (pp ). IEEE. [4] Tor Stålhane,Thor Myklebust, Geir Hanssen The application of Safe Scrum to IEC certifiable software, [5] Richard D. Hawkins. Using Safety Contracts in the Development of Safety Critical Object-Oriented Systems. PhD research, Department of Computer Science, The University of York, March [6] X. Ge, et al. An Iterative Approach for development of Safety-Critical Software and Safety Arguments. Agile Conference, [7] The Scrum Guide, July