A REFERENCE METHOD FOR AIRBORNE SOFTWARE ...

A REFERENCE METHOD FOR AIRBORNE SOFTWARE REQUIREMENTS Johnny Marques, Brazilian Aeronautics Institute of Technology EMBRAER, Sao Jose dos Campos, Brazil Adilson Cunha, Brazilian Aeronautics Institute of Technology, Sao Jose dos Campos, Brazil

Abstract This paper summarizes some definition aspects from a doctoral research that has been conducted at the Brazilian Aeronautics Institute of Technology (ITA). This research has the main objective of developing a Reference Method (RM) for safetycritical software requirements definition, entitled as CARD-RM. The CARD-RM can be used in some safety-critical domains. However, this paper is focused only in aviation scenario, considering the compliance with the applicable software safety standards of DO-178C and DO-331. Additionally, the CARD-RM balances agility and discipline. Agile methods is used to apply memories and histories for adjusting to new environments, reacting, adapting, taking advantage of unexpected opportunities, and updating experience basis for the future. Discipline creates repeatability and well-organized experiences. Based upon that, there is an intersection with discipline and agility. The CARD-RM also relies in reusability, since it is a reference method that can be instantiated in any safety-critical software project.

Introduction The development of safety-critical software is usually part of a regulated environment. A software development error can directly cause losses of human lives or has other catastrophic consequences. Examples include systems that control aircrafts, nuclear reactors, and medical devices. The correctness of such software needs to be demonstrated with high assurance. Regulatory agencies in safety-critical industries use to require products, including the embedded software, to meet stringent certification requirements, as the DO-178C [1] in aviation. The typical standardization presented in any safety-critical domain does not define how the software development life cycle must be conducted. The software safety standards usually define objectives or goals that must be accomplished by the

software project. Table 1 presents the typical software standardization for some safety-critical domains. Table 1. The Safety-Critical Domains and Software Safety Standards SafetyCritical Domains Aviation

Software Safety Standards DO-178C/DO-331 supplements.

Medical

ISO/IEC 62304

Military

ISO/IEC/IEEE 12207

Nuclear

NS-G-1.1

Railway

BS EN 50126

Space

ECSS-E-ST-40C

and

other

A Reference Method (RM) is intended to provide a higher level of commonality with activities, steps, and definitions that should apply and be reused in several software projects. This research has the main objective of developing a Reference Method (RM) for safetycritical software requirements definition, named as CARD-RM. This paper summarizes only one part of a doctoral research. The appropriate tailoring for this paper is presented in Section 7. The main objectives of the doctoral research are: (i.) defining a reference method for software requirements that can be used for safety-critical software projects; (ii.) providing adherence with selected software safety standards; and (iii.) integrating appropriate and compatible agile practices related to requirements definition. Additionally, the CARD-RM also includes the attributes presented in Table 2. The CARD-RM provides activities and a sequence of steps that can be instantiated or used in

978-1-4799-1538-5/13/$31.00 ©2013 IEEE 7A2-1

many safety-critical software development, with some adaptation if applicable. Section 2 discusses the importance of good requirements. Sections 3, 4, and 5 provide a positioning related to Agile Methods, Software Safety Standards, and related work. Sections 6 to 8 explain the research and the CARD-RM. Section 9 presents the executed and planned experiments. Next steps and main conclusion are presented at Sections 10 and 11. Table 2. The CARD-RM Attributes CARD-RM Attributes Compliance

Attributes Description The CARD-RM shall provide compliance with selected software safety standards.

Reuse Discipline

According to the FAA "Requirements Engineering Management Findings Report" [4], investigators focusing on safety-critical systems have found that requirements errors are most likely to affect the safety of an embedded system than errors introduced by design or implementation.

Positioning Agile

Note: In this paper, only DO-178C and DO-331 assessment are presented.

Agile

Reason 3 - Good requirements are essential for safety; Reason 4 - Good requirements are necessary to meet customer needs; and Reason 5 - Good requirements are important for testing. Except for Reason 3, the other reasons impact any software development, not only safety-critical software.

Several agile defendants agreed with Manifesto for Agile Software Development [5] presented in Figure 1. It started as a term for a collection of lightweight methodologies, such as Scrum [6], Extreme Programming (XP) [7], Crystal [8], Feature Driven Development (FDD) [9], Test Driven Development (TDD) [10, 11], Adaptive Software Development (ASD) [12], and Dynamic Systems Development Method (DSDM) [13].

The CARD-RM shall integrate appropriate practices defined in Agile Methods. The CARD-RM shall be a generic model that can be instantiated in several software projects. The CARD-RM shall define an organized method.

Importance of Good Requirements We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

According to Thayer and Dorfman [2], the Requirements Engineering is the science concerned with establishing and documenting software requirements.

Individuals and interactions over processes and tools;

Additionally, there are some major issues of concern in the requirements area: (i.) The inability of some engineers to write correct software requirements; (ii.) The desire of managers to minimize requirements activity, because they believe that the major effort is programming; (iii.) The lack of cooperation among team members; and (iv.) The lack of requirement development methods.

Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan; and That is, while there is value in the items on the right, we value the items on the left more.

Figure 1. The Manifesto for Agile Software Development [5]

According to Rierson [3], there are five reasons for the importance of good requirements: Reason 1 - Requirements are the foundation for software development; Reason 2 - Good requirements save time and money;

According to Stober and Hansmann [14], agile thinking is "an attempt to simplify things by reducing complexity of planning, by focusing on costumer value, and by shaping a fruitful climate of participation and collaboration." Additionally, there

7A2-2

are a vast number of methods, techniques, and best practices that claim to be agile. At this section, the authors of this paper want to give an overview of some of then.

Each selected item from the Product Backlog is designed and then broken down to a set of individual tasks. The list of tasks is recorded in an artifact called a Sprint Backlog.

According to Vuori [15] there is a tendency for companies to transform their software and product development practice into more incremental form, by using special agile software development. Although the incremental software development processes have been previously used, agile principles are the main characteristics adopted within the agile methods.

After the Sprint ends, there is a Sprint Retrospective, where the Scrum Team and the Stakeholders inspect what was done during the Sprint, discuss it, and figure out what to do next. Present at this meeting are the Product Owner, the Team Members, and the Scrum Master, plus customers, stakeholders, experts, executives, and anyone else interested.

There are the following key motivations for agile methods [16]:

Extreme Programming (XP)

Early partial product; Better predictability; Final product better matching true client desires; Manageable complexity; and Early mitigation and discovery. Several software industries have applied agile methods or agile principles compatible with specific needs of organizations. Specific efforts involving balancing agility and discipline have been generated and described in related works, Section 5.

Scrum According to Jeff Sutherland [17], Scrum is an iterative and incremental framework for projects and products or applications development. The Scrum structures the development in cycles of work, also defined as Sprints. One Sprint usually takes place one after the other and it has fixed duration, typically 2-4 weeks. It ends on a specific date, whether the work has been completed or not, and is never extended. Hence, they are time boxed. At the beginning of each Sprint, a Sprint Planning Meeting takes place. The Product Owner and Scrum Team review the Product Backlog, discuss the goals and context for the items, and the Scrum Team selects the items from the Product Backlog to commit to complete by the end of the Sprint, starting at the top of the Product Backlog.

According to Beck [7], Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. The XP life cycle is composed of 4 phases: Exploration phase - at this phase, all stories will be defined; Planning phase - where stories for the next iteration are prioritized; Iteration phase - the development phase that considers analysis, design, pair programming, and tests; and Production phase- where small releases are defined. At the iteration phase, the user stories defined at the exploration phase and prioritized at the planning phase will be analyzed to translate stories to software requirements. After the software requirements for the iteration are defined, the design refines the requirements for the pair programming. At the first book written about XP, Beck [7] includes hand-drawn sketches of diagrams and models. According to Ambler [18], the design using extreme programming may be based in modeling, founded in the following principles: (i.) The creation of several simple models in parallel, (ii.) The interaction with models, (iii.) The use the simplest tools, and (iv.) The modeling of small increments.

7A2-3

Dynamic System Development Method (DSDM) According to Stapleton [13], the DSDM is founded in Pareto's Principle. Therefore, the DSDM begins the implementation of 20% of the software requirements that will be more determinants to the system as a hole. This practice states that software requirements with more complexity or higher risk should be prioritized earlier. The DSDM philosophy also requires user involvement in the entire project, developer autonomy to take decisions without need to consult superior instances, and frequent delivery with high quality to avoid surprises in the final product. One important characteristic is that DSDM considers the software testing as out of the scope of the life cycle. The DSDM is more founded in documentation than Scrum or Extreme Programming (XP). The following activities are part of DSDM:

178C release, other supplementary standards were developed including special recommendations regarding tools qualification (DO -330), model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333). The 71 DO-178C objectives are presented in 10 tables, published in annex A of the standard. DO-331 is a supplement that contains modifications and additions to DO-178C. In July 19, 2013, the AC 20115C [22] has recognized DO-178C and its supplements.

ISO / IEC / IEEE 12207 The ISO / IEC / IEEE 12207 [20] standard establishes processes and activities applied during the acquisition and configuration of the services of the system. The ISO / IEC / IEEE 12207 is typically required to military projects and was officially recognized by the United States Department of Defense (DoD) on May 27, 1998. The ISO / IEC / IEEE 12207 replaces the MIL-STD-498.

Requirements analysis - the requirements are analyzed and reviewed according to the list of priorities; Identify requirements for the current iteration - select from the list of priorities the requirements that will be implemented in the current iteration; and Construct the functional model - create models of the system, using a model specification language.

ECSS-E-ST-40C

Positioning Software Safety Critical Standards As part of the complete doctoral research mentioned in this paper, the following standards are used: (i.) DO-178C [1] / DO-331 [19]; (ii.) ISO/IEC/IEEE 12207 [20]; and (iii.) ECSS-E-ST40C [21]. However, due to the tailoring applied for this paper, the CARD-RM will be evaluated only under DO-178C and DO-331.

DO-178C and DO-331 In December 2011, the RTCA Special Committee 205 (SC-205) and the EUROCAE Working Group 71 (WG-71) have prepared the DO178C, a revision of the traditional DO-178B that has been used since 1992. As part of the effort of the DO-

This ECSS-E-ST-40C [21] defines a set of requirements to be used for the development and maintenance of software for space systems. Space systems include manned and unmanned spacecraft, launchers, experiments, and their associated ground equipment and facilities. This standard also applies to the development or reuse of non-deliverable software, which affects the quality of the deliverable product or service provided by a space system, if the service is implemented by software.

Related Works The idea of reconciling agile development and regulated environments is not new [23]. A variety of software industries are applying agile methods or agile principles that are compatible with the specific needs of an organization. Specific efforts, in balancing agility and discipline, have been generated [15, 17, 18, 20]. According to Stalhane and Hanssen [24], the ISO 9001 [25] was mapped to agile development

7A2-4

principles and some differences were presented. According to McMahon [26], it is possible to integrate agile software development with CMMI [27]. The possibility of applying agile software development with ECSS standards was reported in [28]. Vuori, in [15], has defined the mapping of IEC 61508 [29] and recommended the development tasks to a simplified agile process model. The issues from the perspective of aerospace industry and the mapping from agile practices to DO178B were presented in [30]. From that work, DO178B objectives were divided into three categories: fully compatible agile practices, easily compatible agile practices, and problematic agile practices. Their results have only considered the agile methods of XP, Scrum, and Crystal. At that work, it was presented only “what” to map, but not “how” to integrate practices to the DO-178B process. Additionally, that work only has considered the DO-178B, not the DO178C.

Research Strategy The research strategy for the mentioned doctoral research is founded in two premises: Exists an Agile Methods Domain, which include all Agile Methods available: and Exists a Software Safety Standards Domain, which includes all the available Software Safety Standards.

Inside of the Agile Methods Domain, the authors of this paper have selected three Agile Methods to provide inputs to this doctoral research. The selected Agile Methods are: Scrum, Extreme Programming (XP), and Dynamic System Development Method (DSDM). An overview of the selected Agile Methods was presented at Section 3. Other Agile Methods such as: Test-Driven Development (TDD) [10]; Feature Drive-Development (FDD) [9]; and Adaptive Software Development (ASD) [12] have been preliminary evaluated. However, due to reduction of scope of this research, they were not considered. For the Software Safety Standards, the selection criteria of DO-178C / DO-331 were based in the authors expertise in such standards and the fact DO178C and DO-331 were released in 2011 and recognized by authorities under the AC-20 115C [22] in July of 2013. The other selected standards are ECSS-E-ST-40C [21], which last revision dates March 2009 and ISO / IEC / IEEE 12207 [20], which last revision dates January 2008. All the selected standards were updated in time frame lower than 5 years. Other domains such as medical (ISO 62304 [31]), nuclear (NS-G-1.1 [32]), and railway (BS EN 50126 [33]) have been preliminary evaluated. However, due to reduction of scope of this research, they were not considered. Figure 2 presents the flow of phases of this doctoral research.

Figure 2. The Complete Research Strategy Workflow

7A2-5

As this doctoral research is planned to take place until December, 2015, this paper provides only preliminary details. Additionally, as Digital Avionics System Conference (DASC) is a traditional conference for avionics systems, the authors of this

paper have focused in present the CARD-RM, oriented to airborne software. For comprising such goal, this paper provides a tailoring of the research strategy, presented in Figure 3.

Figure 3. Tailoring of the Research Strategy Workflow

The CARD-RM Definition The CARD-RM is a reference method that considers the development in an incremental model,

as presented in Figure 4. Additionally, the CARDRM uses the term "sprint" in the same definition as presented in SCRUM [17].

Figure 4. The CARD-RM Iterative Development

7A2-6

The sprint structure considered for the CARDRM is presented in Figure 5. Although Coding and Testing are benefited from the use of models, these

activities are not part of the CARD-RM, as it is a new reference method for the requirements process.

Figure 5. The CARD-RM Domain According to Shumate and Keller [34], a method is a "set of steps that must be accomplished to complete an activity". The CARD-RM is structured in activities and steps.

Table 3. The System Requirements Analysis and Selection Activity ASSR: Analyze and Select System Requirements

Analyze and Select System Requirements (ASSR)

Step

Description

1

Review the System Requirements.

Typically, system requirements define the functionality of the system that has been developed. A system is not simply composed of software. Several systems are comprised of software, electronic hardware, and other parts (mechanical, pneumatics, and hydraulics). Not all system requirements are directly applied to the software.

2

Identify the System Requirements applied to Software (SRATS).

3

Prioritize the specific SRATS for the next Sprint. Inputs

System Requirements

At this activity the software team, in addition to the system team, must analyze the system requirements, select the System Requirements Applied to Software (SRATS), and prioritize the SRATS for the Sprint.

Outputs Prioritized SRATS

Define Sprint Stories (DSS) During the DSS, the focus of the software team is to understand the SRATS and create the Stories. Typically, some agile methods define the term "User Stories".

Table 3 identifies the steps for the activity ASSR.

According to Schwaber and Beedle [6], a User Story is one or more sentences in the everyday or business language of the end user or user of a

7A2-7

system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what', and 'why' of a requirement in a simple and concise way.

Define Design (DD) During the DD, the focus of the software team is to use the S-Stories and DS-Stories to create design data. At the CARD-RM, Models and Textual Low-level requirements compose the design data. Models are generated to specify the functionality according to S-Stories and DS-Stories. The use of models can portray system, hardware, and software detailed requirements. In general, models have the capability to generate source code directly using autocode generation tools. The generation of test cases and procedures, directly from graphical models, can be used to verify the software implementation.

For safety critical software, it is very difficult to define "User Stories". An operator of a nuclear reactor or an airline pilot probably can contribute with requirements associated to the systems' operation. However, a system cannot be constructed using only the operational perspective. Based on such definition, the authors of this paper have expanded the scope of the User Stories to Specification Stories (S-Stories) for the software to be constructed. Such S-Stories may include functional, performance, security, and safety-related requirements and are refined from SRATS.

Models may express part of the design using a modeling tool, as defined by European Aviation Safety Agency (EASA) [35]. These models should contain sufficient details of such aspects as code structures and data/control flow for source code to be produced directly from it, either manually or by the use of a tool, without any further information.

Additional S-Stories, not refined from SRATS, may be necessary to construct the derived software requirements. S-Stories, specifying behavior beyond that defined by the system requirements, are named, in this paper, as Derived S-Stories (DSStories). Table 4 identifies the steps for the activity DSS.

The authors of this paper decide to include models on the CARD-RM for the following reasons: Reason 1 - The model of a software application is specified on higher abstraction level than traditional textual requirements; Reason 2 - The model is automatically transformed into a working software application, by using autocode generation; Reason 3 - The model is expressed in a higher abstraction level and it is smaller compared to the same model expressed in textual requirements. In other words, each element within the model represents multiple Textual Low-level Requirements; and Reason 4 - Some Software Safety Standards allow the use of Model-Based Development (MBD). Textual Low-Level Requirements (TLLR) are additional requirements that cannot be expressed using modeling tools. Some of the TLLRs may be

Table 4. The Sprint Stories Definition Activity DSS: Define Sprint Stories (DSS) Step

Description

1

Implement Open Problem Reports (OPRs) scheduled for the current Sprint.

2

Define and Trace S-Stories from SRATS.

3

Define DS-Stories.

4

Communicate DS-Stories to System Team.

5

Review S-stories and DS-Stories.

Inputs: 1. Selected SRATS

Outputs: 1. S-Stories 2. DS-Stories

7A2-8

completion and changeability is neglected. The accumulation of debt does not impact software delivery immediately. At first, focusing on immediate completion creates a sense of rapid future delivery. However, this is only an illusion of speed in delivery.

defined to specify interface among models, hardware interface, among others. Table 5 identifies the steps for the DD activity. In the CARD-RM, the management of the software debt is focused in:

The Specification Retrospective is an activity that is focused in confirming that solutions to previous Open Problem Reports (OPRs) are implemented. This means that OPRs rose to correct S-Stories or DS-Stories will be implemented and reviewed. Additionally, this activity will analyze and confirm the OPRs rose during step DD-9 in the current sprint, by identifying the S-Stories and DSStories to be corrected in future sprints. Table 6 identifies the steps for the activity ESR.

Models and Low-Level Requirements that are corrected, during the review; and S-Stories and DS-Stories can be scheduled for future correction. However, the correction should be analyzed, confirmed, and scheduled in the Sprint where deficiency was found. No error is postponed to an uncertain future. Table 5. The Design Definition

Table 6. Execute Specification Retrospective (ESR)

Activity DD: Define Design Step

Description

Activity ESR: Retrospective

Execute

Specification

1

Define and trace Models to S-Stories and DS-Stories.

2

Define and trace Textual Low-Level Requirements to S-Stories and DS-Stories.

1

Select Open Problem Reports (OPRs) from activity DD-10.

3

Communicate Derived Models and Derived Textual Low-Level Requirements to System Team.

2

Analyze and confirm OPRs.

3

Schedule OPRs to future Specification Sprints.

4

Close Problem Reports (PRs) addressed in the current Specification Sprint.

Step

Description

4

Create Simulation Cases and Procedures.

5

Simulate Models.

6

Review Models Low-Level Requirements.

Involved Roles/Team:

7

Review Textual Low-Level Requirements.

Software Team

8

Correct Errors.

Inputs:

9

Open Problem Reports to update any SStories and DS-Stories that need correction. Inputs

1. OPR at initial stage 2. S-Sprints and DSSprints to be corrected

Outputs

1. S-Stories

1. MLLRs

2. DS-Stories

2. TLLRs 3. Architecture

Outputs: 1. Closed PRs for the current Specification Sprint 2. OPRs to future Specification Sprints Analyzed and Scheduled

Execute Specification Retrospective (ESR)

DO-178C/DO-331 Compliance

According to Sterling [36], the software debt accumulates when the focus is on immediate

Although other scenarios of models usage are available in the DO-331, the use of models in the 7A2-9

Table 8 present the acceptance of reconciling agile with DO-178C.

CARD-RM is restricted to represent Low-Level Requirements (LLR) and Architecture. As mentioned at Section 4.1, DO-178C has 71 objectives and other supplements that can add, modify, or eliminate objectives due to the use of new technologies as Model-Based Development. Table 7 presents the CARD-RM Compliance Evaluation Matrix with the objectives of the DO178C and DO-331 applied.

Table 8. The Survey Results Responses Yes. I am confident all agile practices are compatible with DO-178C. Yes. I think some agile practices may be compatible with DO-178C. No. They are not compatible. I am not familiar with agile practices.

Table 7. The CARD-RM Compliance Evaluation Matrix Standard Table DO-178C Table A-2 obj. 1 DO-178C Table A-2 obj. 2 DO-178C Table A-2 obj. 3 DO-178C Table A-2 obj. 4 DO-178C Table A-2 obj. 5 DO-178C Table A-3 obj. 1-2 and obj. 4-6 DO-178C Table A-4 obj. 1-12 DO-178C Table A-8 obj, 3 DO-331 Table MB-A-4 obj. MB 14 DO-331 Table MB-A-4 obj. MB 15 DO-331 Table MB-A-4 obj. MB 16

CARDRM Activity DSS DSS

DSS 2

DD DD

DD 1-2

DD

DD 3

DSS

DSS 3 DSS 5

DD

DD 6-7

ESR

ESR 1-4

DD

DD 4

DD

DD 4

DD

DD 5

86,21% 0,00% 10,34%

The results shown in Figure 6 and Table 8 present that more than 86% of users think that some agile practices are compatible with the DO-178C. This is an important result, as it confirms the acceptance of the research in this area.

CARDRM Step

DSS 3 DSS 5 DD 1

Results 3,45%

Figure 6. The Survey Question Other experiments will be performed until the end of this doctoral research.

Experiments

Table 9 presents the other three Experiments B, C, and D and also the main planned activities.

There are four experiments planned for this doctoral research. The Experiment A was conducted to verify the acceptance of the Brazilian DO-178C community on the use of Agile Methods and Practices. The Experiment A is a survey that has conducted with 45 software engineers. Figure 6 and

7A2-10

methods and their best practices to enhance efficiency while maintaining the DO-178C compliance.

Table 9. Upcoming Experiments Experiment B

C

D

Main Activities 1. To instantiate the CARD-RM in a Software Development Plan (SDP), as required by DO-178C, Section 11.2. 2. To request to 3 independent senior software engineers (Designated Engineering Representative - DER) to evaluate the SDP using Job Aid Checklist [37]. 3. To collect suggestions, observations, and improvements proposed by the independent evaluations and confirm DO-178C and DO331 compliances. 1. To use the CARD-RM at the Brazilian Aeronautics Institute of Technology (ITA). A Problem Based Learning (PBL) for the Real Time Embedded Avionics System proposed for three graduate disciplines on the second semester of 2013. 1. To use the CARD-RM in a real existing system which requirements were generated from other methods and comparing results.

According to Figure 2, during the Analysis of Results, a validation of the CARD-RM, in terms of agility and discipline, will occur using the Experiments B, C, and D presented in Section 9. The reusability will be investigated, by using the principles defined in [38]. Additionally, the next steps will include the implementation of all phases presented in Figure 2 and Experiments B, C, and D also presented in Table 9.

Conclusion The Manifesto for Agile Software Development is compatible with Software Safety Standards. However, all the Software Safety Standards mentioned in this paper are plan-driven, requirements-driven, and document-driven. Basically, the development can occur using agile practices of any method. However, the compliance with such standards has the same values of responding to change or providing working software. The CARD-RM must be instantiated in the Software Development Plan (SDP). This is a premise assumed and expected by the authors of this paper to be confirmed from Experiment B. Agility can be introduced, planned, and followed and this is other premise also expected by the authors of this paper to be confirmed from Experiments C and D.

Next Steps

Besides, the authors also believe that the five reasons for the importance of good requirements, identified by Rierson [3], are also included in the CARD-RM Definition.

This paper has summarized the partial results of a doctoral research that has been conducted at the Brazilian Aeronautics Institute of Technology (ITA).

The following principles of SCRUM, XP, and DSDM were included in the CARD-RM definition:

The key motivations for agile methods identified in [16] were included in the Reference Method. During this process, early partial product should be delivered at the end of each Sprint.

Stories, as software requirements; Prioritization of stories; and The use of functional models to represent software architecture. The CARD-RM also presents the compliance with DO-178C and DO-331 associated to software

As the next steps, due to the increasing of complexity of airborne systems, the authors of this paper believe that approaches like the CARD-RM be used and/or adapted, aiming to integrate agile

7A2-11

high-level requirements, software requirements, and software architecture.

[14] Thomas Stober, Uwe Hansmann, 2010, Agile Software Development - Best Practices for Large Software Projects, Springer, Heindelberg, Germany

low-level

References

[15] Matti Vuori, 2011, Agile Development of Safety-Critical Software, Tampere University of Technology Report

[1] RTCA, 2011, DO-178C Software Considerations in Airborne Systems and Equipment Certification, Radio Technical Commission for Aeronautics.

[16] Craig Larman, 2003, Agile and Iterative Development: a Manager's Guide, Addison-Wesley.

[2] Richard H. Thayer, Merlin Dorfman, 2000, Software Requirements Engineering, 2nd Edition, IEEE Computer Society.

[17] Jeff Sutherland, 2010, SCRUM Handbook, Scrum Training Institute Press. [18] Scott Ambler, 2002, Agile Modeling, Wiley.

[3] Leanna Rierson, 2013, Developing Safety Critical Software, CRC Press.

[19] RTCA, 2011, DO-331 Model-Based Development and Verification Supplement to DO178C and DO-278A, Radio Technical Commission for Aeronautics

[4] David L. Lempia and Steven P. Miller, 2009, Requirements Engineering Management Findings Report DOT/FAA/AR-08/34. [5] Kent Beck et. al, 2001, Manifesto for Agile Software Development, available at http://agilemanifesto.org/ (12.8.2013)

[20] International Standardization Organization, 2008, ISO/IEC/IEEE 12207:2008 Systems and software engineering - Software life cycle processes.

[6] Ken Schwaber, Mike Beedle, 2001, Agile Software Development with SCRUM, PrenticeHall.

[21] European Cooperation for Safety Standardization, 2009, ECSS-E-ST-40C Space Engineering Software

[7] Kent Beck, 2000, Extreme Programming Explained: Embrace Change, Addison–Wesley

[22] Federal Aviation Administration, 2013, Airborne Software Assurance, Washington, United States.

[8] Alistar Cockburn, 2004, Crystal Clear: a Human-Powered Methodology for Small Teams, Addison-Wesley.

[23] Barry Boehm, Richard Turner, 2003, Balancing Agility and Discipline: a Guide for the Perplexed, Addison-Wesley.

[9] Stephen. R. Palmer, John M. Felsing, 2002, A Practical Guide to Feature Driven Development, Pearson Educational.

[24] Tor Stalhane, Geir Kjetil. Hanssen, 2008, The Application of ISO 9001 to Agile Software Development, Proceedings of the 9th International Conference on Product-Focused Software Process Improvement, 371-385.

[10] Kent Beck, 2003, Test-driven Development by Example, Addison-Wesley. [11] David Astels, 2003, Test-driven Development: A Practical Guide: A Practical Guide, Pearson Education, Upper Saddle River, NJ, pp. 6-7.

[25] International Standardization Organization, 2008, ISO 9001 Quality Management Systems Requirements. [26] Paul. E. McMahon, 2010, Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement, Addison-Wesley.

[12] James A. Highsmith III, 2000, Adaptive Software Development: a Collaborative Approach to Managing Complex Systems, Dorset House Publishing.

[27] Mary Bath Chrissis, Mike Konrad, Sandy Shrum, 2011, CMMI for Development: Guidelines for Process Integration and Product Improvement, 3rd Edition: SEI - Software Engineering Institute.

[13] Jennifer Stapleton, 1997, DSDM - Dynamic Systems Development Method, Addison-Wesley

7A2-12

[35] European Aviation Safety Agency, 2011, "Certification Memo SW-CEH 002", Cologne, Germany.

[28] Ehsan Ahmad, Bilal Raza, Robert Feldt, Tanja. Nordeback, 2010, ECSS Standard Compliant Agile Software Development, Proceedings of the 2010 National Software Engineering Conference.

[36] Chris Sterling, 2010, Managing Software Debt - Building for Inevitable Change, AddisonWesley.

[29] International Eletrotechnical Commission, 2010, IEC 61508-3 Functional Safety of Electrical/Electronic/Programmable Electronic, Safety Related Systems - Part 1: Software Requirements, 2nd Edition, IEC, 2010.

[37] Federal Aviation Administration, 2004, Job Aid-Conducting Software Reviews Prior to Certification. [38] Carma McClure, 2001, Software Reuse: A Standards-Based Guide.

[30] Steven H. Vanderleest, Andrew Buter, 2009, Escape the Waterfall: Agile for Aerospace, 28th Digital Avionics Systems Conference, IEEE/AIAA.

Acknowledgements

[31] International Standardization Organization, 2006, ISO/IEC 62304 Medical Device Software Software Life Cycle Processes.

The main author of this paper is Johnny Marques. He is a doctoral student at the Brazilian Aeronautics Institute of Technology (ITA). Adilson Marques da Cunha is an Associate Professor, the thesis advisor, and the co-author of this paper. This paper summarizes only the preliminary aspects of a doctoral research work developed.

[32] International Atomic Energy Agency, 2000, NS-G-1.1 - Software for Computer Based Systems Important to Safety in Nuclear Power Plants. [33] British Standard, 1999, BS EN 50126-1:1999 Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability, and Safety (RAMS) - Part 1: Basic Requirements and Generic Process.

The authors would like also to thank their colleagues at Embraer that provides responses to Experiment A.

[34] Ken Shumate, Marilyn Keller, 1992, Software Specification and Design: a Disciplined Approach for Real-time Systems, Willey.

32nd Digital Avionics Systems Conference October 6-10, 2013

7A2-13