5 Certifiable safe airborne software process analyses

Size: px
Start display at page:

Download "5 Certifiable safe airborne software process analyses"

Transcription

1 Certifiable safe airborne software process analyses 97 5 Certifiable safe airborne software process analyses Published as E. Kesseler, Applying theory to practise, Airworthy software measured and analysed, 16 th IFIP World computer congress, Proceedings of conference on software theory and practice, August 2, Beijing, China. ISBN Abstract Software which is embedded in aircraft to which people entrust their life becomes safety-critical and consequently safety is an uncompromisable requirement. Failures of such software must be virtually non-existent. Due to the high costs of aircraft, hypothetical software failures would also incur major financial losses. To guarantee aircraft safety, an independent government agency certifies the aircraft, including its software, as fit-for-use. The world-wide-standardised avionics software certification requirements deliberately allow considerable freedom for compliant software development processes. The first two versions of the discussed application have successfully passed the certification and well over 1 units are currently being flown in numerous aircraft. In fact the software product is so successful that it will be adapted to other aircraft models. Based on product and process metrics, the software development process will be analysed, applying theory to practice. Aspects covered include requirements, code size, verification, effort, and project dynamics. 5.1 Introduction To put the software process into perspective, this chapter starts with a cursory overview of the application. A succinct description of the safety requirements follows to appreciate its influence on the software development process, which is defined in the subsequent section. The main part of the paper analyses the experience gained, using software metrics where appropriate. The switch to a spiral software development model proved beneficial, however the CASE tool could not adequately support the resulting changes. A specification method more suitable for all actors involved, pilot, aircraft experts and software experts, would reduce the requirement evolution. Applying and enforcing a strict coding standard, C can be

2 98 Certifiable safe airborne software process analyses used for safety critical applications. The test automation paid off. The conclusions summarise these and some other findings. 5.2 Application overview The embedded application discussed combines, controls, processes and forwards the data between the aircraft sensors, all pertinent aircraft subsystems and the flight deck. Configuring the embedded application to a specific aircraft is done by configuration files. This solution reduces the certification effort for each aircraft to a validation of the data files involved. The embedded application is designed to operate in both Visual Meteorological Conditions (VMC) and Instrument Meteorological Conditions (IMC). The latter conditions allow all-weather operations of the aircraft. Under these conditions the displays of the flight deck are needed by the pilot to fly, rendering the application safety-critical. During normal operations the embedded application processes about 1 different flight parameters, originating from 1 different sensors and aircraft subsystems, some of which are duplicated. Two processors are used in each of the duplicated hardware units. The delay times within the entire embedded application should be guaranteed to be less then 3 milliseconds with a cycle time of 25 milliseconds for the main processor. Aircraft have an economic life of several decades. Consequently 5% spare processor time is reserved for the many extensions of the embedded application expected during its operational life. The I/O processor has a cycle time of 36 microseconds. As an illustration of the paramount influence of safety on the embedded application's functions, for all input data the software performs quadruple data validation: Coherency test: a check on correct length and parity of the data; Reception test: a check on the timely arrival of the data; Sensor discrepancy test: a comparison the two independent redundant sensors; Module discrepancy test: a comparison between the two parameter values produced by the same sensor; one value directly read by the system from the sensor, and one obtained from the redundant system via a cross-talk bus.

3 Certifiable safe airborne software process analyses 99 (Kesseler, van de Sluis 1998) contains more information on the application. 5.3 Overview safety requirements Applicable software safety requirements For safety-critical software in airborne equipment (DO-178B 1992) provides guidance for both the software developers and the certification authorities. The latter, an independent governmental institution, performs the ultimate system acceptance by certifying the entire aircraft, including its embedded software, i.e. releasing it for commercial use. In an international industry DO-178B provides the important world-wide protection of the air traveller as well as a world-wide "level playing field" for the competing industries. DO-178B was the first widely used document to address safety-critical software. Based on amongst others the experience gained with this document, currently other more general-purpose standards are available, like (ISO/DIS ) and (IEC ) Safety classification Based on the worst-case consequences of a software failure, the software is classified into 5 levels A to E. The Federal Aviation Regulation /Joint Aviation Requirements FAR/JAR-25 uses the general principle of an inverse relationship between the probability of a failure condition and the degree of hazard to the aircraft or its occupants. As DO-178B considers qualitative demonstration of software compliance to such high reliability to be beyond the current software technology, the FAR/JAR-25 failure probability in flight hours can be provided for information only. For more information on DO-178B and its classification please refer to the section of the introduction.

4 1 Certifiable safe airborne software process analyses Software life cycle In order to provide the developer with maximum flexibility, DO-178B allows the developer to choose a complying software life cycle. It enforces traceability to its general processes listed below: Software planning process which includes the production of the software development plan and the software verification plan; Software development processes split into: a software requirement process, a software design process, a software coding process and integration processes; Integral processes comprising verification, configuration management and quality assurance. The integral processes are a result of the criticality of the software. Consequently the integral processes are performed concurrently with the software development processes throughout the entire software life cycle Verification Each process within the chosen software life cycle has to be traceable, verifiable and consistent. DO-178B defines verification as "the evaluation of the results of a process to ensure correctness and consistency with respect to the inputs and standards to that process". Verification can be accomplished by any combination of: Review, which provides a qualitative assessment of correctness; Analysis, which is a repeatable process, optionally supported by tools; Test. For software classified at DO-178B level A, the mandatory 1% code coverage consists of: Statement coverage (every statement executed, called statement testing in (BS , 1998); Decision coverage (every decision executed for pass and fail, called branch/decision testing in BS );

5 Certifiable safe airborne software process analyses 11 Modified condition/ decision coverage (MC/DC, same name in BS ). MC/DC requires that for every condition in a decision, its effect on the outcome of the decision be demonstrated. Code coverage will be shown at module level testing. In an iterative software process model each delivery requires full regression testing. 5.4 Software development process The definition of the software development process has been guided by previous experience with safety-critical software for spacecraft. (Dekker, Kesseler 1996) contains more information on the spacecraft application. (Park et al., 1996) puts great emphasis on metrics definition in order to allow others to interpret and repeat the results. The following software process definition provides this context, including all items of the basic measurement set of (Gaffney 1995). The project team was set up consisting of 2 separate groups, a development group and a verification group. In compliance with DO-178B the verification team leader was independent. Furthermore the quality assurance manager was independent from both teams and not allowed to produce deliverable code or tests. In this high-tech project the quality assurance manager needed his technical background in order to arrive at its impartial judgements. The embedded application project started using: A (DOD-STD-2167A 1992) waterfall based life cycle model; Customer supplied requirement specifications in plain English; Formal reviews after each life cycle phase; Software analysis using Structured Analysis with Hatley and Pirbhai Real Time extensions (SA/RT) (Hatley, Pirbhai, 1988) supported by the Teamwork Computer Aided Software Engineering (CASE) tool; Software design using Yourdon Structured Design (SD) supported by the same CASE tool;

6 12 Certifiable safe airborne software process analyses The customer prescribed C language; Module and integration testing on the target system with a simulated environment; The Cantata automated test tool to aid the construction and cost effective regression testing of the functional tests and code coverage tests; A proprietary configuration management tool; Integration with the aircraft avionics suite after integration of the embedded application; All key project team members had at least 5 years experience in aerospace applications. 5.5 Experience Software classification In the embedded application, software classified at DO178-B levels A, B and E has been realised. At project completion 81% of the modules were classified at level A, 8% at level B and 11 % at level E. The increasing number of data fusion requirements lead to a larger share of level A software at the expense of level B software. With the small amount of remaining level B modules it is unclear whether the advantages of less rigorous testing of level B software outweigh the more complicated software development process. When software classified at different safety levels has to run on the same processor, special partitioning software guarantees that software of one level can under no circumstance compromise the functioning of software at other levels. This partitioning software took only 1% of the total project effort. It remains necessary and cost effective for separation of level A and level E (mainly maintenance) software.

7 Certifiable safe airborne software process analyses C language The C language with its numerous unspecified constructs (Hatton 1995) is considered a project risk. This risk was contained by choosing an ISO C-9 (also known as ANSI-C) compliant compiler complemented by a proprietary coding standard enhanced to define a safe subset of C. A customised commercial static analysis tool can automatically verify compliance to this project coding standard. DO-178B requires tool verification, which revealed that the version management by the tool supplier turned out to be inadequate. The tool was already marketed worldwide since 1986 to hundreds of customers. This illustrates the rigour of the applied verification processes Metrics selection The Goal Question Metric paradigm (Basili, Weis 1984) states that business goals should drive any measurement effort. Some (Solingen, Berghout 1999) take this approach so far as to abolish any notion of a standard measurement set. Others (NASA 1995), (Gaffney 1995) define a basic measurement set consisting of size, cost, schedule, quality and project dynamics. This basic measurement set is used to analyse the safety-critical software development process and compare it with some results from literature Requirements evolution Previous experience with safety-critical software suggested a waterfall software development model. The commercially defined short time-to-market induced codevelopment of the application with a customer developed display application. This co-development required an early prototype. Note that laws prohibit the use of intermediate (i.e. non-certifiable) versions in flying aircraft. The first prototype served its purpose well. Consequently the project changed to an incremental or spiral software development model. The spiral model allowed full compliance with all high-level programme milestones. Figure 5-1 depicts the resulting requirements evolution. The time axis starts at project start. Every point indicates a formal delivery to the customer. Figure 5-1 is cumulative: the number of partially implemented requirements ( partial in Figure

8 14 Certifiable safe airborne software process analyses 5-1) is added to the number of fully implemented requirements ( Ful ). Together with the not yet implemented requirements ( Not) this yields the total number of requirements. The number of requirement changes is superimposed. New issues of the requirement document caused the increase in the number of requirements and the reduction in the number of implemented requirements after 3 and 52 calendar days. Requirements Calendar Days Full Full+Partial Full+Partial+Not Changes Changes Figure 5-1. Requirements evolution. The changes are caused by (in descending order): Changes in the Human Machine Interfaces (HMI) of the aircraft. These changes originate from pilot comment and can only be obtained from demonstrating a working prototype in a realistic environment; Adding product features. Apart from marketing input, these changes also result from experience with an actual prototype; Integration of the embedded application with the displays and the aircraft. Formal interface specifications might have helped to reduce this class of changes; Ambiguities in the plain English specifications. Especially for HMI related features an unambiguous specification method which is intelligible for pilots, HMI experts and computer software experts is needed.

9 Certifiable safe airborne software process analyses 15 Of the 15 deliveries only the ones at 655 and 779 calendar days have been certified Design evolution The CASE tool used only allows to progress once from analysis to design and once from design to code. It provides inadequate support to incorporate model updates into the next phases. By its nature the spiral model requires frequent updates of the analyses and design models. The amount of effort needed for data input even makes updating the analysis or design model cumbersome. After day 57 it was decided to retain the analysis model but limit its depth in order to allow for its updating. The design model was abandoned, as the CASE tool data input effort became unaffordable with the requirement evolution. Instead pseudo code was added to the code. As a result design metrics spanning the entire project history have to be based on the implemented modules. Figure 5-2 shows the evolution of the number of modules (files containing C code) and external functions over time Modules Functions 1 Calendar Days Modules External Functions Figure 5-2. Module evolution. Up until the first certified version the number of modules increased only slightly, indicating that all changes could be accommodated in the original design. Splitting some modules according to their safety classification, required for verification, caused the sharp rise in the number of modules just before the first certified version.

10 16 Certifiable safe airborne software process analyses This splitting was postponed until the first certified version as new data fusion requirements influenced the safety classification. Some optimisations for the second certified version resulted in a minor reduction in the number of modules. The number of external functions rose approximately continuously until the first certified version, in concert with the number of implemented requirements. The number of functions remained virtually constant for the second certified version. These two metrics reflect that the design remained relatively stable, most requirement changes could be accommodated in the existing modules Code size evolution KLoC Calendar Days Pseudo Code Code Other Comments Figure 5-3. Code size evolution. The code size evolution is shown in Figure 5-3. This figure is cumulative, the amount of pseudo code is added to the amount of code, to which the other comments are added. Its continuous increase until the first certified version corresponds with the continuous increase in the number of implemented requirements. The subsequent slight reduction mirrors some optimisations. After day 57 the detailed design was converted to pseudo code. This pseudo code contains an abstract description of the code in about 27% of its size. Also all interface definition information was added in extensive headers per function. This extra information explains the considerable increase in the amount of comment before the first certified version.

11 Certifiable safe airborne software process analyses 17 The considerable requirement evolution is reflected in the changed source code metric. On average each line of executable code has been modified 13.4 times, each comment line only 4.1 times. Figure 5-3 shows that code size on its own is inadequate to measure the growing complexity and sophistication of the product as a result of the requirement evolution Code breakdown For testing purposes a division of statements had to be made into: Decisions and loops (consisting of the "switch", "if", "for" and "while" statements); Assignments; Data e.g. tables Statements Calendar Days Decisions Assigments Data Figure 5-4. Evolution of statement type distribution. The results are shown in Figure 5-4, again in a cumulative way, i.e. the amount of assignments is added to the amount of decisions. All statement types increase approximately continuously until the first certified version, with a slight decrease up till the second certified version. Experience gained from the various prototypes lead to more sophisticated solutions which comply with both the real-time requirements as well as with the requirements evolution. Just like the code size, the code

12 18 Certifiable safe airborne software process analyses breakdown does not reflect the added complexity and sophistication of the application. Similar figures displaying the evolution of complexity metrics like McCabe, Myer and Halstead also show no significant change in complexity. In order to manage this type of application, a metric is needed which does reflect the growing complexity of the product in order to relate it to the extra effort spend on it. Note that the doubling of the requirement document size does indicate the increased complexity Verification Due to the safety criticality of the product great effort is spent to ensure that no errors remain in the product. Consequently standard quality metrics like number of errors are not applicable. As an alternative the verification process metrics are complemented by some experience. Each testable requirement is identified to allow traceability from requirements through all development processes to verification. Every DO-178B compliant development phase contained full traceability of each requirement, using the requirement identification. This has greatly helped the management of the virtually continuous requirement evolution. A lesson learned is to allocate a separate identification to each verifiable part of a requirement. (Hayhurst 1998) reached this conclusion independently. The standard applied for the software requirement process has to be verified. Some simple tools can be produced to cost-effectively reduce the verification effort. The same holds for the design standard. For module tests the use of a Commercial Off-the-Shelf (COTS) test tool greatly reduced the time needed to prepare the tests and to perform the regressions tests for each delivery. The actual test code is generated from Test Case Definition (TCD) files. To satisfy the 1% statement coverage, 1% decision coverage and the MC/DC criterion (for level A software only), on average each safety-critical function is called 3.8 times during the verification tests. Due to this thorough testing the non-comment part of the test case definition files equals 2.9 times the noncomment size of the code. The size of the test descriptions necessitated adding test comment. The test comment grew to about 7% of the executable test case size. DO-178B requires data to be verified by inspection, only decisions and assignments can be verified by testing. For each testable statement 2 checks have been performed. For global data the test tool automatically checks that no global data is

13 Certifiable safe airborne software process analyses 19 inadvertently changed by the module, causing the large amount of checks per testable statement. Integration testing was based on the white box approach. It comprised the correct functioning of combinations of functions. During integration 184 tests have been performed. The COTS test tool did not support the multiple-module integration testing. During validation testing the requirements are verified using a black box approach. Several requirements can be verified in one test. The 132 black box tests verified 9% of the requirements. Integration tests verified 19% of the requirements. These requirements could not be verified by black box testing only. Examples of the latter are spare processor time and spare memory requirements. Analysis was used to verify 12% of the requirements. Note that some requirements can only be verified by a combination of analysis, validation testing and integration testing. Consequently the 3 percentages add up to more then 1%. Figure 5-5 shows which part of the requirements was verified by which combination of techniques Number of Requirements Validation Validation + Integration Integration Integration + Analysis Analysis Analysis + Validation Figure 5-5. Requirement validation methods.

14 11 Certifiable safe airborne software process analyses Documentation Number of Pages PSAC SDP SVP SCMP SQAP sw requirements sw design sw coding sw integration STD CAD VDD sw QA SAS Figure 5-6. Document volume. Figure 5-6 depicts the document volume in number of pages for the second certified version. The five documents of the software planning process (Plan of Software Aspects of Certification PSAC, Software Development Plan SDP, Software Verification Plan SVP, Software Configuration Management Plan SCMP, Software Quality Assurance Plan SQAP) constitute to 19% of the document volume. The four software development process documents make up 63% of the document volume. A large part of the design (47% of the project volume) is retrieved from the code, see section The integral processes contribute five documents and 18% of the document volume, Software Test Description (STD), Version Description Document (VDD), software Quality Assurance (sw QA) and Software Accomplishment Summary (SAS). These figures demonstrate that the additional volume of documentation due to the certification requirements turns out to be quite modest in this case. Re-use of documents is limited to part of the software planning documents.

15 Certifiable safe airborne software process analyses 111 (Gaffney 1995) provides an estimate of the document volume based on the software size for a DOD-STD-2167A compliant life cycle. The actual requirement documentation and the test documentation size are less than 18% above these estimates. The actual design documentation size is more than twice this estimate. It is unclear whether this deviation for the design documentation is caused by the safety criticality of the product or the use of pseudo code in stead of a graphical design method Effort breakdown The unit of effort is 1 effective person month, i.e. one person working 3 calendardays full time. In a calendar year one person typically spends around two months on other activities like (public) holidays etc. First certified version (198 person month) Second certified version (37 person month) Plan PM QA CM Dev Ver Figure 5-7. Effort breakdown. For the first certified version the software planning process consumed 27% of the costs, 16% to produce all required planning documents (Plan in Figure 5-7) and 11% for project management (PM in Figure 5-7). This first implementation of a DO- 178B compliant process implies that all documents have been written from scratch. The switch from a waterfall process model to a spiral process model also added some effort. The software development process (Dev in Figure 5-7) took 41% of the total effort. The integral processes accounted for 32% of the effort, split in 23% for verification activities (Ver in Figure 5-7), 4% for configuration management (CM in Figure 5-7)

16 112 Certifiable safe airborne software process analyses and 5% for quality assurance (QA in Figure 5-7). The certification liaison effort was so small, that it is included in the quality assurance figure. The second certified version shows a dramatic shift in effort from software development to verification. In the first certified version a considerable amount of requirements were disabled using the configuration files, and hence had not been verified. Even though the test tool saved a lot of effort for the module tests, the integration and validation regression tests consumed a lot of effort. For mission-critical, embedded, real-time satellite systems (Vardanega 1999) provides effort estimates of 4%-45% for software development and 55%-6% for verification. Combining the total effort spent on both versions, 57% was spent on development and 43% on verification. This confirms that the module test automation paid of. For a wide range of aerospace applications (NASA 1996) reports 63% for software development and 37% for verification. Due to the test automation our experience comes close to the average reported for non safety-critical applications. For general software development (Gaffney 1995) reports 5% for software development, 17% for verification, 7% for quality assurance and configuration management and 26% for project management. Our 9% quality assurance and configuration management effort is only slightly higher. Surprisingly the 27% for integral processes, including the complete definition of the certifiable software development process comes close to his standard for project management. As expected the main difference is the great emphasis on verification for the safetycritical application.

17 Certifiable safe airborne software process analyses Project staffing Project Staff Calendar Monts Out In #Persons Figure 5-8. Project staffing. Figure 5-8 illustrates that on average 11 physical people were deployed. Combining this with the total effort (Figure 5-7) shows all people to be full time allocated. However in total 36 persons contributed to the project. The average personnel turnover was 1.2 person per month with a strong peak between 18 and 22 months. A key success factor was that the design team leader and verification team leader participated from the beginning to the project completion. The DO-178B requirement for well-documented software processes eased the effects of the personnel turnover. The result of the extra capacity deployed after month 18 is reflected in the large amount of comment introduced in the code (Figure 5-3). 5.6 Conclusions For a certifiable, safety-critical product with a commercially determined time-tomarket co-development is a solution. The various prototypes provided by a spiral software development process allowed full compliance with all high-level programme milestones.

18 114 Certifiable safe airborne software process analyses To reduce requirement evolution there is a need for an unambiguous specification method that is intelligible for all actors involved, pilots, HMI experts, system experts and software experts. There is a need for a complexity metric based on the realised code. Code size, statement distribution and standard complexity measures do no reflect the increasing capabilities of the software. C combined with an appropriate coding standard and an automated analysis tool can be used for certifiable, safety-critical software. The additional software needed to run software of various safety levels on one processor is cost effective. The CASE tool used did not adequately support design updates rendering it incompatible with the spiral model. Automatically retrieving the required detailed design documentation from comment in the code works better. The COTS test tool significantly reduced the module testing effort. This is confirmed by comparing the measured effort distribution with data for comparable systems from literature. For integration and validation testing such support tools were not available. The additional volume of process documentation due to the certification requirements turns out to be quite modest in this case. Re-use of the software process documentation can lead to cost reduction Of the software product documentation, only the design documentation is well above the industry average for non safety-critical applications. A well-documented software process combined with the retention of the key personnel allowed to cope with significant project personnel turnover without adverse effects on product quality.

4 Applying DO-178B for safe airborne software

4 Applying DO-178B for safe airborne software Applying DO-178B for safe airborne software 81 4 Applying DO-178B for safe airborne software Published as E. Kesseler, E. van de Sluis, Reliability, maintainability and safety applied to a real world avionics

More information

AC 20-148 REUSABLE SOFTWARE COMPONENTS

AC 20-148 REUSABLE SOFTWARE COMPONENTS AC 20-148 REUSABLE SOFTWARE COMPONENTS December 7, 2004 12/7/04 AC 20-148 CONTENTS Paragraph Title Page 1. Purpose....1 2. Motivation for this Guidance....1 3. Document Overview...1 4. General Guidelines

More information

DO-178B compliance: turn an overhead expense into a competitive advantage

DO-178B compliance: turn an overhead expense into a competitive advantage IBM Software Rational Aerospace and Defense DO-178B compliance: turn an overhead expense into a competitive advantage 2 DO-178B compliance: turn an overhead expense into a competitive advantage Contents

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS

ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS info@enea.com. www.enea.com For over 40 years, we have been one of the fastest growing avionics consulting companies in the world. Today our

More information

SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE. Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions.

SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE. Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions. SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions.com DIGITAL FLIGHT / SOLUTIONS Presentation Outline DO-178 Overview

More information

1. Software Engineering Overview

1. Software Engineering Overview 1. Overview 1. Overview...1 1.1 Total programme structure...1 1.2 Topics covered in module...2 1.3 Examples of SW eng. practice in some industrial sectors...4 1.3.1 European Space Agency (ESA), software

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Software Review Job Aid - Supplement #1

Software Review Job Aid - Supplement #1 Software Review Job Aid - Supplement #1 1010011101010011110001101001101101101101000100100010101011100010110 1010011101010011110001101001101101101101000100101110101011100010111 0110100110110110110100010010001010101110001011000100111010100111100

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original

More information

Parameters for Efficient Software Certification

Parameters for Efficient Software Certification Parameters for Efficient Software Certification Roland Wolfig, e0327070@student.tuwien.ac.at Vienna University of Technology, Real-Time Systems Group 1 Abstract Software certification is a common approach

More information

Using CMM with DO-178B/ED-12B for Airborne System Development

Using CMM with DO-178B/ED-12B for Airborne System Development Using CMM with DO-178B/ED-12B for Airborne System Development WHITE PAPER Author : Narasimha Swamy (Project Manager, Avionics Practice) Most aircraft companies develop onboard systems software for civilian

More information

Certification of a Scade 6 compiler

Certification of a Scade 6 compiler Certification of a Scade 6 compiler F-X Fornari Esterel Technologies 1 Introduction Topic : What does mean developping a certified software? In particular, using embedded sofware development rules! What

More information

F-22 Raptor. Agenda. 1. Motivation

F-22 Raptor. Agenda. 1. Motivation Model-Based Software Development and Automated Code Generation for Safety-Critical Systems F-22 Raptor for the Seminar Advanced Topics in Software Engineering for Safety-Critical Systems Cause: Bug in

More information

TITLE: Control of Software

TITLE: Control of Software Page 1 of 8 TITLE: Control of Software WARNING This document is the property of United Technologies Corporation (UTC). You may not possess, use, copy or disclose this document or any information in it,

More information

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center May, 2009 Thomas Schultz Director of Product Strategy, Coverity, Inc. Executive Summary Development organizations that create

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

8. Master Test Plan (MTP)

8. Master Test Plan (MTP) 8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across

More information

Best Practices for Verification, Validation, and Test in Model- Based Design

Best Practices for Verification, Validation, and Test in Model- Based Design 2008-01-1469 Best Practices for Verification, Validation, and in Model- Based Design Copyright 2008 The MathWorks, Inc. Brett Murphy, Amory Wakefield, and Jon Friedman The MathWorks, Inc. ABSTRACT Model-Based

More information

IBM Rational systems and software solutions for the medical device industry

IBM Rational systems and software solutions for the medical device industry IBM Software August 2011 IBM Rational systems and software solutions for the medical device industry Improve processes, manage IEC 61508 and IEC 62304 standards, develop quality products Highlights Manage

More information

Certification Authorities Software Team (CAST) Position Paper CAST-13

Certification Authorities Software Team (CAST) Position Paper CAST-13 Certification Authorities Software Team (CAST) Position Paper CAST-13 Automatic Code Generation Tools Development Assurance Completed June 2002 NOTE: This position paper has been coordinated among the

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development

Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University

More information

Information Systems Development Process (Software Development Life Cycle)

Information Systems Development Process (Software Development Life Cycle) Information Systems Development Process (Software Development Life Cycle) Phase 1 Feasibility Study Concerned with analyzing the benefits and solutions for the identified problem area Includes development

More information

WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES

WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES Wind River Professional Services RTCA DO-178 Practice provides software certification services to help our customers address their demanding software

More information

Certification Authorities Software Team (CAST) Position Paper CAST-26

Certification Authorities Software Team (CAST) Position Paper CAST-26 Certification Authorities Software Team (CAST) Position Paper CAST-26 VERIFICATION INDEPENDENCE COMPLETED January 2006 (Rev 0) NOTE: This position paper has been coordinated among the software specialists

More information

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost

More information

2/25/2012. [5] http://www.segvn.org/forum

2/25/2012. [5] http://www.segvn.org/forum MSc. NguyễnThị Thu Trang, trangntt@soict.hut.edu.vn http://soict.hut.edu.vn/~trangntt Department of Software Engineering [1] ISO/IEC FDIS 12207, Systems and software engineering Software life cycle processes.

More information

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management?

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management? 11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 11: Managing the Software Process Project management encompasses all the

More information

Chap 1. Software Quality Management

Chap 1. Software Quality Management Chap 1. Software Quality Management Part 1.1 Quality Assurance and Standards Part 1.2 Software Review and Inspection Part 1.3 Software Measurement and Metrics 1 Part 1.1 Quality Assurance and Standards

More information

Software Process for QA

Software Process for QA Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called

More information

Example Software Development Process.

Example Software Development Process. Example Software Development Process. The example software development process is shown in Figure A. The boxes represent the software development process kernels. The Software Unit Testing, Software Component

More information

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.) The Software Process Xiaojun Qi 1 The Unified Process Until recently, three of the most successful object-oriented methodologies were Booch smethod Jacobson s Objectory Rumbaugh s OMT (Object Modeling

More information

Software Test Plan (STP) Template

Software Test Plan (STP) Template (STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This

More information

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3)

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) 1st February 2006 Version 1.0 1 P3M3 Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value

More information

Moving from Paper to Electronic Records: Hardwiring Compliance into Product Development Using technology to incorporate quality system regulation

Moving from Paper to Electronic Records: Hardwiring Compliance into Product Development Using technology to incorporate quality system regulation P T C. c o m White Paper Medical Devices Page 1 of 8 Moving from Paper to Electronic Records: Hardwiring Compliance into Product Development Using technology to incorporate quality system regulation Abstract

More information

CERTIFICATION MEMORANDUM

CERTIFICATION MEMORANDUM EASA CM No.: EASA CM SWCEH 002 Issue: 01 EASA CERTIFICATION MEMORANDUM EASA CM No.: EASA CM - SWCEH 002 Issue: 01 Issue Date: 11 th of August 2011 Issued by: Software & Complex Electronic Hardware section

More information

Development of AUTOSAR Software Components within Model-Based Design

Development of AUTOSAR Software Components within Model-Based Design 2008-01-0383 Development of AUTOSAR Software Components within Model-Based Design Copyright 2008 The MathWorks, Inc. Guido Sandmann Automotive Marketing Manager, EMEA The MathWorks Richard Thompson Senior

More information

CDC UNIFIED PROCESS JOB AID

CDC UNIFIED PROCESS JOB AID CDC UNIFIED PROCESS JOB AID Independent Verification & Validation Activities Document Purpose This Job Aid is a brief document listing the items to be noted, checked, remembered, and delivered when completing

More information

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com Reduce Medical Device Compliance Costs with Best Practices mark.pitchford@ldra.com 1 Agenda Medical Software Certification How new is Critical Software Certification? What do we need to do? What Best Practises

More information

Certification Authorities Software Team (CAST) Position Paper CAST-3

Certification Authorities Software Team (CAST) Position Paper CAST-3 Certification Authorities Software Team (CAST) Position Paper CAST-3 Guidelines for Assuring the Software Aspects of Certification When Replacing Obsolete Electronic Parts Used in Airborne Systems and

More information

TESSY Automated dynamic module/unit and. CTE Classification Tree Editor. integration testing of embedded applications. for test case specifications

TESSY Automated dynamic module/unit and. CTE Classification Tree Editor. integration testing of embedded applications. for test case specifications TESSY Automated dynamic module/unit and integration testing of embedded applications CTE Classification Tree Editor for test case specifications Automated module/unit testing and debugging at its best

More information

Component Based Development in Software Engineering

Component Based Development in Software Engineering Component Based Development in Software Engineering Amandeep Bakshi, Rupinder Singh Abstract--In today s world, Component Based development is an active research area for more than a decade in software

More information

STANDARD REVIEW PLAN

STANDARD REVIEW PLAN NUREG-0800 U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN BRANCH TECHNICAL POSITION 7-14 GUIDANCE ON SOFTWARE REVIEWS FOR DIGITAL COMPUTER-BASED INSTRUMENTATION AND CONTROL SYSTEMS REVIEW RESPONSIBILITIES

More information

Process Models and Metrics

Process Models and Metrics Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers

More information

Peter Mileff PhD SOFTWARE ENGINEERING. The Basics of Software Engineering. University of Miskolc Department of Information Technology

Peter Mileff PhD SOFTWARE ENGINEERING. The Basics of Software Engineering. University of Miskolc Department of Information Technology Peter Mileff PhD SOFTWARE ENGINEERING The Basics of Software Engineering University of Miskolc Department of Information Technology Introduction Péter Mileff - Department of Information Engineering Room

More information

Testing of safety-critical software some principles

Testing of safety-critical software some principles 1(60) Testing of safety-critical software some principles Emerging Trends in Software Testing: autumn 2012 Matti Vuori, Tampere University of Technology 27.11.2012 Contents 1/4 Topics of this lecture 6

More information

Rev 1 January 16, 2004

Rev 1 January 16, 2004 1010011101010011110001101001101101101101000100110010101011100010110 0110100110110110110100010010001010101110001011000100111010100111100 1110100110110110110100010010001010101110001011000100111010100111100

More information

The Advantages of Commercial UAV Autopilots over Open Source Alternatives

The Advantages of Commercial UAV Autopilots over Open Source Alternatives The Advantages of Commercial UAV Autopilots over Open Source Alternatives White Paper by Sarah Vallely Small and large scale businesses are switching to open source software solutions (OSS) to create anything

More information

Software Quality Assurance: II Software Life Cycle

Software Quality Assurance: II Software Life Cycle Software Quality Assurance: II Software Life Cycle Room E 3.165 Tel. 60-3321 Email: hg@upb.de Outline I Introduction II Software Life Cycle III Quality Control IV Infrastructure V Management VI Standards

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

Software Development Principles Applied to Graphical Model Development

Software Development Principles Applied to Graphical Model Development Software Development Principles Applied to Graphical Model Development Paul A. Barnard * The MathWorks, Natick, MA 01760, USA The four fundamental principles of good software design communicate clearly,

More information

Criteria for Flight Project Critical Milestone Reviews

Criteria for Flight Project Critical Milestone Reviews Criteria for Flight Project Critical Milestone Reviews GSFC-STD-1001 Baseline Release February 2005 Approved By: Original signed by Date: 2/19/05 Richard M. Day Director, Independent Technical Authority

More information

The Impact of RTCA DO-178C on Software Development

The Impact of RTCA DO-178C on Software Development Cognizant 20-20 Insights The Impact of RTCA DO-178C on Software Development By following DO-178C, organizations can implement aeronautical software with clear and consistent ties to existing systems and

More information

Rapid Modular Software Integration (RMSI)

Rapid Modular Software Integration (RMSI) Rapid Modular Software Integration (RMSI) Adam Grimm adam.grimm@kihomac.com Overview RMSI Overview Future Airborne Compatibility Environment (FACE ) Analog Computer Rehost Integration of Modular Components

More information

NODIS Library Program Formulation(7000s) Search

NODIS Library Program Formulation(7000s) Search NODIS Library Program Formulation(7000s) Search NASA Procedural Requirements This Document Is Uncontrolled When Printed. Check the NASA Online Directives Information System (NODIS) Library to verify that

More information

3 August 2014. Software Safety and Security Best Practices A Case Study From Aerospace

3 August 2014. Software Safety and Security Best Practices A Case Study From Aerospace 3 August 2014 Software Safety and Security Best Practices A Case Study From Aerospace Agenda Introduction Why Aviation? ARINC 653 Real-time Linux on Xen (ARLX) Safety Artifacts for ARLX Security Artifacts

More information

Certification Authorities Software Team (CAST) Position Paper CAST-9

Certification Authorities Software Team (CAST) Position Paper CAST-9 Certification Authorities Software Team (CAST) Position Paper CAST-9 Considerations for Evaluating Safety Engineering Approaches to Software Assurance Completed January, 2002 NOTE: This position paper

More information

Reuse and Capitalization of Software Components in the GSN Project

Reuse and Capitalization of Software Components in the GSN Project Experiences with certification of reusable components in the GSN project in Ericsson, Norway Parastoo Mohagheghi (Ph.D. Student, NTNU) Reidar Conradi Ericsson AS, Grimstad, Dept. Computer and Information

More information

ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL

ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL 61508-3 ª IEC: 1997 1 Version 12.0 05/12/97 COMMISSION CEI ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL COMMISSION Functional safety of electrical/electronic/ programmable

More information

<name of project> Software Project Management Plan

<name of project> Software Project Management Plan The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

SOFTWARE ASSURANCE STANDARD

SOFTWARE ASSURANCE STANDARD NOT MEASUREMENT SENSITIVE National Aeronautics and NASA-STD-8739.8 w/change 1 Space Administration July 28, 2004 SOFTWARE ASSURANCE STANDARD NASA TECHNICAL STANDARD REPLACES NASA-STD-2201-93 DATED NOVEMBER

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

An integrated life cycle quality model for general public market software products

An integrated life cycle quality model for general public market software products An integrated life cycle quality model for general public market software products Witold Suryn 1, Alain Abran 2, Claude Laporte 3 1 Département de génie électrique, École de technologie supérieure 1100,

More information

WORKSHOP RC 2011. EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior

WORKSHOP RC 2011. EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior WORKSHOP RC 2011 EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior Comparison between ARP4754 A Guidelines for Development of Civil Aircraft and Systems (2010) and ARP4754 Certification

More information

Request for Proposal for Application Development and Maintenance Services for XML Store platforms

Request for Proposal for Application Development and Maintenance Services for XML Store platforms Request for Proposal for Application Development and Maintenance s for ML Store platforms Annex 4: Application Development & Maintenance Requirements Description TABLE OF CONTENTS Page 1 1.0 s Overview...

More information

Procedure for Assessment of System and Software

Procedure for Assessment of System and Software Doc. No: STQC IT/ Assessment/ 01, Version 1.0 Procedure for Assessment of System and Software May, 2014 STQC - IT Services STQC Directorate, Department of Electronics and Information Technology, Ministry

More information

Software Engineering. Software Development Process Models. Lecturer: Giuseppe Santucci

Software Engineering. Software Development Process Models. Lecturer: Giuseppe Santucci Software Engineering Software Development Process Models Lecturer: Giuseppe Santucci Summary Modeling the Software Process Generic Software Process Models Waterfall model Process Iteration Incremental

More information

Abstract. 1 Introduction

Abstract. 1 Introduction Amir Tomer Amir Tomer is the Director of Systems and Software Engineering Processes at RAFAEL Ltd., Israel,with whom he has been since 1982,holding a variety of systems and software engineering positions,both

More information

A COMPARISON OF FIVE APPROACHES TO SOFTWARE DEVELOPMENT. David J. Schultz. January 21, 2000

A COMPARISON OF FIVE APPROACHES TO SOFTWARE DEVELOPMENT. David J. Schultz. January 21, 2000 A COMPARISON OF FIVE APPROACHES TO SOFTWARE DEVELOPMENT David J. Schultz January 21, 2000 1. Introduction This white paper addresses five approaches, or methodologies, for software engineering (SWE): The

More information

How to Upgrade SPICE-Compliant Processes for Functional Safety

How to Upgrade SPICE-Compliant Processes for Functional Safety How to Upgrade SPICE-Compliant Processes for Functional Safety Dr. Erwin Petry KUGLER MAAG CIE GmbH Leibnizstraße 11 70806 Kornwestheim Germany Mobile: +49 173 67 87 337 Tel: +49 7154-1796-222 Fax: +49

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

Virtual Platforms Addressing challenges in telecom product development

Virtual Platforms Addressing challenges in telecom product development white paper Virtual Platforms Addressing challenges in telecom product development This page is intentionally left blank. EXECUTIVE SUMMARY Telecom Equipment Manufacturers (TEMs) are currently facing numerous

More information

Software Production and Lifecycle Models

Software Production and Lifecycle Models Software Production and Lifecycle Models 1 Problem Definition Change Architectural Design Verification Personnel Basic Phases Potential Difficulties, Verification, and Testing Implementation and Integration

More information

Personal Software Process (PSP)

Personal Software Process (PSP) Personal Software Process (PSP) Application of CMM principles to individuals Developed by Watts Humphrey of the Software Engineering Institute (SEI) in the early 1990s Extensive supporting materials: books,

More information

International Journal of Advance Research in Computer Science and Management Studies

International Journal of Advance Research in Computer Science and Management Studies Volume 2, Issue 12, December 2014 ISSN: 2321 7782 (Online) International Journal of Advance Research in Computer Science and Management Studies Research Article / Survey Paper / Case Study Available online

More information

Software Life Cycle Process - DO-178B

Software Life Cycle Process - DO-178B 1(19) Cross reference tables for H ProgSäk (E) and DO-178B A comparison has been made between requirement areas covered by H ProgSäk (E) and DO-178B respectively. Tables for correspondences and differences

More information

Business Operations. Module Db. Capita s Combined Offer for Business & Enforcement Operations delivers many overarching benefits for TfL:

Business Operations. Module Db. Capita s Combined Offer for Business & Enforcement Operations delivers many overarching benefits for TfL: Module Db Technical Solution Capita s Combined Offer for Business & Enforcement Operations delivers many overarching benefits for TfL: Cost is reduced through greater economies of scale, removal of duplication

More information

the state of the practice Variations in Software Development Practices

the state of the practice Variations in Software Development Practices focus the state of the practice invited article Variations in Software Development Practices Capers Jones, Software Productivity Research My colleagues and I at Software Productivity Research gathered

More information

Chapter 2 Software Processes

Chapter 2 Software Processes Chapter 2 Software Processes Chapter 2 Software Processes Slide 1 Topics covered Software processes and process models Generic models: Waterfall Incremental development Reuse-oriented software engineering

More information

Project Type Guide. Project Planning and Management (PPM) V2.0. Custom Development Version 1.1 January 2014. PPM Project Type Custom Development

Project Type Guide. Project Planning and Management (PPM) V2.0. Custom Development Version 1.1 January 2014. PPM Project Type Custom Development Project Planning and Management (PPM) V2.0 Project Type Guide Custom Development Version 1.1 January 2014 Last Revision: 1/22/2014 Page 1 Project Type Guide Summary: Custom Development Custom software

More information

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM The American Association for Laboratory Accreditation Document Revised: R214: Specific Requirements: Information Technology Testing Laboratory Accreditation July 13, 2010 Program Page 1 of 26 R214 SPECIFIC

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN. Organization responsible for the review of instrumentation and controls

U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN. Organization responsible for the review of instrumentation and controls U.S. NUCLEAR REGULATORY COMMISSION STANDARD REVIEW PLAN NUREG-0800 BRANCH TECHNICAL POSITION 7-14 GUIDANCE ON SOFTWARE REVIEWS FOR DIGITAL COMPUTER-BASED INSTRUMENTATION AND CONTROL SYSTEMS REVIEW RESPONSIBILITIES

More information

SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND. Queensland 4072 Australia TECHNICAL REPORT

SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND. Queensland 4072 Australia TECHNICAL REPORT SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND Queensland 4072 Australia TECHNICAL REPORT No. 99-30 A Survey of International Safety Standards Axel

More information

Methodology: Agile development of safety critical systems Annex D1.1.d to deliverable D1.1

Methodology: Agile development of safety critical systems Annex D1.1.d to deliverable D1.1 Collaborative Large scale Integrating Project Open Platform for EvolutioNary Certification Of Safety critical Systems Methodology: Agile development of safety critical systems to deliverable D1.1 Work

More information

Best practices for developing DO-178 compliant software using Model-Based Design

Best practices for developing DO-178 compliant software using Model-Based Design Best practices for developing DO-178 compliant software using Model-Based Design Raymond G. Estrada, Jr. 1 The MathWorks, Torrance, CA Eric Dillaber. 2 The MathWorks, Natick, MA Gen Sasaki 3 The MathWorks,

More information

Standard for Software Component Testing

Standard for Software Component Testing Standard for Software Component Testing Working Draft 3.4 Date: 27 April 2001 produced by the British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST) Copyright Notice This document

More information

Independent Validation of Software Safety Requirements for System of Systems by S. Driskell, J. Murphy, J.B. Michael, M. Shing

Independent Validation of Software Safety Requirements for System of Systems by S. Driskell, J. Murphy, J.B. Michael, M. Shing Independent Validation of Software Safety Requirements for System of Systems by S. Driskell, J. Murphy, J.B. Michael, M. Shing Presented by Stephen Driskell Stephen.Driskell@TASC.com Judy Murphy jmurphy@mpl.com

More information

Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes.

Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes. Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes.. www.pharmout.net Page 1 of 15 Version-02 1. Scope 1.1. Purpose This paper reviews the implementation of the ANSI/AAMI/IEC

More information

The Software Development Process

The Software Development Process Systeme hoher Qualität und Sicherheit Universität Bremen WS 2015/2016 Lecture 03 (26.10.2015) The Software Development Process Christoph Lüth Jan Peleska Dieter Hutter Your Daily Menu Models of software

More information

Software Development Under Stringent Hardware Constraints: Do Agile Methods Have a Chance?

Software Development Under Stringent Hardware Constraints: Do Agile Methods Have a Chance? Software Development Under Stringent Hardware Constraints: Do Agile Methods Have a Chance? Jussi Ronkainen, Pekka Abrahamsson VTT Technical Research Centre of Finland P.O. Box 1100 FIN-90570 Oulu, Finland

More information

Notes and terms of conditions. Vendor shall note the following terms and conditions/ information before they submit their quote.

Notes and terms of conditions. Vendor shall note the following terms and conditions/ information before they submit their quote. Specifications for ARINC 653 compliant RTOS & Development Environment Notes and terms of conditions Vendor shall note the following terms and conditions/ information before they submit their quote. 1.

More information

Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 6 : Product Development Software Level

Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 6 : Product Development Software Level ISO 26262 the Emerging Automotive Safety Standard Agenda Introduction of ISO/DIS 26262 (ISO 26262) Parts of ISO 26262 ASIL Levels Part 4 : Product Development System Level Part 6 : Product Development

More information

IEC 61508 Overview Report

IEC 61508 Overview Report IEC 61508 Overview Report A Summary of the IEC 61508 Standard for Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems exida Sellersville, PA 18960, USA +1-215-453-1720

More information

Engineering Services

Engineering Services Contact Us About Dorset Software Our work has assisted many engineering and scientific organisations to meet and exceed their goals. A member of our account management team is waiting to take your call,

More information

Certified Software Quality Engineer (CSQE) Body of Knowledge

Certified Software Quality Engineer (CSQE) Body of Knowledge Certified Software Quality Engineer (CSQE) Body of Knowledge The topics in this Body of Knowledge include additional detail in the form of subtext explanations and the cognitive level at which the questions

More information

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY How to Write a Software Process for YOUR COMPANY 1. Introduction MicroTools is proposing to assist YOUR COMPANY in improving the existing software process. The purpose of this project is to both improve

More information

Systems Development Life Cycle (SDLC)

Systems Development Life Cycle (SDLC) DEPARTMENT OF BUDGET & MANAGEMENT (SDLC) Volume 1 Introduction to the SDLC August 2006 Table of Contents Introduction... 3 Overview... 4 Page 2 of 17 INTRODUCTION 1.0 STRUCTURE The SDLC Manual consists

More information