The Role of CM in Agile Development of Safety-Critical Software

Size: px
Start display at page:

Download "The Role of CM in Agile Development of Safety-Critical Software"

Transcription

1 The Role of CM in Agile Development of Safety-Critical Software Tor Stålhane1, Thor Myklebust 2 1 Norwegian University of Science and Technology, N-7491, Trondheim, Norway 2 SINTEF ICT, Strindveien 2, N-7491 Trondheim, Norway Abstract. Agile development is getting more and more used, also in the development of safety-critical software. For the sake of certification, it is necessary to comply with relevant standards in this case IEC and EN In this paper we focus on two aspects of the need for configuration management and SafeScrum. First and foremost we need to adapt SafeScrum to the standards needs for configuration management. We show that this can be achieved by relative simple amendments to SafeScrum. In addition in order to keep up with a rapidly changing set of development paradigms it is necessary to move the standards requirement in a goal based direction more focus on what and not so much focus on how. Keywords: Safety critical systems, agile software development, configuration management, IEC61508, EN Introduction It is always a challenge to change software safety critical or not. In this paper we will discuss challenges related to changes and change processes when using agile development. We will do this from two perspectives IEC 61508: 2010 (a generic standard often used in industrial automation) and EN 50128: 2011 (railway signalling systems). Change is always tightly connected to configuration management (CM) which is a well-known process. The challenge is more important for agile development that in any other development paradigm since agile development promises to embrace change. The challenges related to CM will, however, increase when we use agile development since changes will be more frequent possibly several changes included in each sprint. Changes during agile development come from several sources, e.g.: New requirements added after the development process has started Changes to existing requirements due to new knowledge or new customer needs New risk and hazards due to changes in the operating environment Refactoring tidy up the code, which is important in agile development Not-accepted user story implementation from a sprint adfa, p. 1, Springer-Verlag Berlin Heidelberg 2011

2 All changes, irrespective of source, represent challenges for both the developers and for the system s integrity, e.g.: Testing. Which tests need to be re-run after the changes the need for regression testing has to be evaluated Change impact analysis. How will the change affect system Complexity both IEC and EN require that the system complexity shall be controlled Safety which safety and hazard analyses should be checked or repeated The CM process is well known and there is a plethora of tools available to support it. However, none of the proposed methods handle the problems pertaining to change impact analysis. Traditionally, the processes have been heavy on management and on documentation. None of these concepts fit well with agile development. 2 Related Works First and foremost, there exist a well-known standard for CM IEEE Std. 828 [10] which should be used as a reference document. When searching for existing work related to agile configuration management, we note that there exist few academic articles and that the few that exist mostly can be summarized in one sentence: CM is important, also for agile development. If we look for papers on how to do CM during agile development, we find that the majority of relevant articles are published on blogs e.g., [1, 2], although there are exceptions, e.g., [3, 4]. It is important to note the conclusion from [1]: CM can be adapted to an agile iterative process without any problems and the summary from [4]: Modern CM tools can handle any number of configuration items without any problems and, therefore, controlling everything should be the tendency in agile methods. In addition, there exist some books on the topic, e.g., [5-7]. The current conventional wisdom is best summed up in [1] edited by the authors: Add support for parallel multiple development branches Avoid centralized Change Control Boards (CCB) that controls all changes. Control non-strategic decisions on changes in the distributed organization of Scrums. Reserve centralized decisions for changes that impact the whole program or organization. Let the agile team assumes the CM role instead of a dedicated Configuration Manager. Use automated tools Automated continuous integration helps to reduce the integration and testing delays and allow quick feedback about the product quality. Continuously observe and adapt the CM tools and process.

3 3 Agile Development and SafeScrum SafeScrum [8] is an adaptation of Scrum to make the development process comply with IEC 61508, EN and IEC , ed. 2. The main adaptations are shown in Fig 1. Fig. 1: The SafeScrum development process. A complete description of Scrum and its development into SafeScrum can be found in [9]. The other important adaptation is the introduction of separation of concerns see Fig 2. The main message here is that SafeScrum cannot handle everything we have decided to only handle software development, which is thus separated from the rest of the process described in IEC and EN The term separation of concerns stems from software design and we found this to be a useful and descriptive term when we designed the SafeScrum process. Fig. 2: Separation of concerns

4 SafeScrum gets its requirements from the system s SSRS and incorporate methods and techniques described in annex A, part 3 of the standard as required by the designated SIL. Each increment from SafeScrum goes through a RAMS validation and the result is either that it is OK, that it needs to be modified in another sprint or that it requires a new hazard analysis. 4 CM in Two Standards 4.1 CM in IEC The following sections of IEC are related to CM: Part 1 sections and These two sections states that the project shall have a procedure for CM and the project needs configuration identification of items under test, the procedure applied for testing and the test environment Part 2 sections and D.2.1. These two sections are concerned with the CM of the complete E/E/PE system hardware and software Part 3 sections 6.2.3, , and Section is the most important one since this section defines the requirements for the CM process to be used. We will look at this process in some more details below also because part 3 is the part of the standard that is concerned with software development. The other sections are concerned with CM history and CM for tools of categories T2 and T3 Part defines the term configuration data and also defines configuration baseline as the information that allows the software release to be recreated in an auditable and systematic way Parts 5 and 6 no relevant sections on CM Part 7 appendix C.4.3 and C The first of these two appendices state that the CM tools shall be certified and the second one describes the goals of CM Part 1, part 2, part 4 or part 7 will have an impact on the chosen development method while part 3 is important. According to Software configuration management shall: a) apply administrative and technical controls throughout the software safety lifecycle, in order to manage software changes and thus ensure that the specified requirements for safety-related software continue to be satisfied b) guarantee that all necessary operations have been carried out to demonstrate that the required software systematic capability has been achieved c) maintain accurately and with unique identification all configuration items which are necessary to meet the safety integrity requirements of the E/E/PE safetyrelated system. Configuration items include at least the following: safety analysis and requirements; software specification and design documents; software source code modules; test plans and results; verification documents; pre-existing software elements and packages which are to be incorporated into the E/E/PE safetyrelated system; all tools and development environments which are used to create

5 or test, or carry out any action on, the software of the E/E/PE safety-related system d) apply change-control procedures: to prevent unauthorized modifications; to document modification requests to analyse the impact of a proposed modification, and to approve or reject the request to document the details of, and the authorisation for, all approved modifications; to establish configuration baseline at appropriate points in the software de- velopment, and to document the (partial) integration testing of the baseline to guarantee the composition of, and the building of, all software baselines (including the rebuilding of earlier baselines). e) ensure that appropriate methods are implemented to load valid software elements and data correctly into the run-time system f) document the following information to permit a subsequent functional safety audit: configuration status, release status, the justification (taking account of the impact analysis) for and approval of all modifications, and the details of the modification g) formally document the release of safety-related software. Master copies of the software and all associated documentation and version of data in service shall be kept to permit maintenance and modification throughout the operational lifetime of the released software. The majority of these requirements will not be influenced by a choice of using an agile approach in this case SafeScrum. Even most of the requirements in part 3, section 6.2.3will not be influenced by agile development. The mail challenges are point c and f. There is nothing there that cannot be fulfilled when using agile development but the resources needed may be large, depending on the tools used. It is thus important to agree on when we define a new configuration. This decision should be reached with the assessor and may be with the customer before development starts. According to requirement c, we need CM for the following documents: safety analysis and requirements, software specification and design documents, software source code modules, test plans and results, verification documents. We could for instance define configurations to be the result of: Each sprint. Use CM to recreate the status of the system after any chosen sprint. Separate CM-item sprints. The system s state can be recreated only to the states at these points The complete system. Only the final, delivered system can be recreated 4.2 CM in EN Even though both EN and EN also are relevant for railway applications, we have decided to only look at EN since we focus on software. The following sections in EN50128 are related to CM:

6 Section 4 requirement 4.1, which specifies that development environment shall contain a system for CM Section 5 requirement , which specifies that the project shall have a CM plan, drawn up from the start of the project Section 6 requirement and are related to tests. Requirements and handles quality assurance requirements, while requirements and handles change control. Each project needs a CM plan. All software documents and deliverables shall be placed under CM control and changes to these documents shall be authorized and recorded. The CM system shall cover the software development environment used during a full lifecycle. Each test specification shall document test environment, tools, configuration and programs, requirement and that we need to identify the configuration of all items involved in a test report. All changes shall be done according to the CM plan and deliver a new CM record. Section 7 requirements , , , and Requirement requires that each component shall have a CM history attached Requirement requires that each component shall be under CM before we start documented testing Requirements , and require that the software and hardware integrations shall identify the configurations of the elements involved and the validation report Section 8 has configuration requirements for configuration data of the system. In our opinion, this is outside the scope of this paper except for requirements and which requires that the configuration data shall be placed under configuration control Section 9 contains requirements for deployment and maintenance, which both are topics outside the scope of this paper. It is, however, important to note that requirement opens up for incremental deployment Note that EN does not mention regression testing. This should, however, be included in the next version of the standard 4.3 Prescriptive vs. Goal Based Standards The most convenient way to start this discussion is to use a definition of CM. In order not to favour any of the two standards that we discussed here, we will use the definition given by IEEE [12] which states that configuration management is the process of Identifying and defining the items in the system Controlling the change of these items throughout their lifecycle Recording and reporting the status of items and change requests Verifying the completeness and correctness of items

7 In order to make standards more robust when techniques and methods change, we work to make as many as possible of the standards goal-based. I.e., instead of saying what you shall do, we want to focus on what you shall achieve. To show what we mean, we will show a possible goal-based approach for some of the CM requirements for the two standards discussed above. The main goal for both standards is to be able to recreate a consistent set of documentation, code, test data and tools that is maintained throughout the development project. This goal alone covers IEC 61508, part 1, part 2 and part 7 plus EN 50128, section 4, section 5 and section 6. For IEC 61508, only part 3 is important, since it describes a set of concrete requirements to CM while part 4 only contains relevant definitions and parts 5 and 6 have no relevant sections pertaining to CM. A closer look at part 3, section shows that it only says that you should be able to recreate the complete project state at any defined time. For EN 50128, sections 4 and 5 just say that a project shall have a plan and a system for CM. Section 6 adds that the CM shall cover the software development over a full lifecycle. We have earlier stated that all the development requirements stated in annex A and B of IEC only contains sound software engineering practices. It would not be unreasonable to claim the same for the two standards requirements for CM. 5 The SafeScrum Approach to CM 5.1 Some general considerations First and foremost: CM is more important when using an agile development approach then when using a waterfall process. There are several reasons for this: Builds baselines more frequent Have more frequent deliveries/releases Have more and more frequent changes If we look at the table supplied by [4], we see that software CM is not a part of Scrum and thus needs to be added also to SafeScrum. Table 1: CM in agile development methods Method Adaptive Software Development Crystal family of methodologies Dynamic System Development Method Extreme Programming Feature Driven development Software configuration management approach SCM not explicitly considered Tool viewpoint on SCM - SCM explicitly considered SCM partially considered SCM explicitly considered - Practices related to SCM All changes during the development must be reversible Collective ownership, small releases and continuous integration Configuration management, regular builds

8 Pragmatic Programming Tool viewpoint on SCM Source code control Scrum SCM not explicitly considered - Note that [1] advices us to avoid a centralized Change Control Boards and to reserve centralized decisions for changes that impacts the whole program or organization. The rest should be handled by the SafeScrum team. The term component is often used both in IEC and in EN From the definition given in EN well-defined interfaces and behaviour with respect to the software architecture it is reasonable to interpret component as a functional unit see IEC , Functional unit: entity of hardware or software, or both, capable of accomplishing a specified purpose. 5.2 Regression Testing One important issue not explicitly related to CM but important for each change which is the reason why we need CM is regression testing. When we do test-first, e.g. TDD, we make a set of tests based on the current set of requirements (user stories) and develop software with the goal that the piece of code currently developed shall pass the tests. However, we will also have a lot of tests developed for previous requirements. In addition, the tests developed for a user story will in most cases depend on a set of stubs, fakes or mocks. It is not obvious that these tests can be run on any later version of the system without much ado. We see two practical ways out of this: Organize the user stories in such a sequence that we avoid or at least minimize the need for stubs, fakes and mocks. See for instance [11] Have two sets of tests one for the total system and one for each increment. The first will be a system test that is increased for each sprint while the other one is a set of tests only relevant for the designated sprint see Fig 1. The system test could be maintained and run by the same persons who do the RAMS validation in the current SafeScrum model while the other tests could by the responsibility of the development team see Fig 2 Another important consideration is the need to retest only what was affected by the last sprint. To achieve this we will use two important mechanisms (1) connecting tests to user stories and (2) using the trace information. We need traces from user stories to code and from user stories to tests. This will give us information about which tests are related to which code units. We only need to retest components that are changed or receive input (directly or indirectly) from changed components. By having efficient tools for automation, it is possible to enable regression testing of relevant parts of the system, with increased frequency. When developing safety-critical systems, changes may have effects that are outside the changed modules or components. This challenge is handled by change impact analysis. Even though this is important it is not part of CM. We have, however, discussed this problem and the suggested SafeScrum solutions extensively in [9]. The interested read should consult this paper and its references.

9 5.3 SafeScrum CM in IEC and EN The most important statement related to CM is that the Software Quality Assurance Plan, Software Verification Plan, Software Validation Plan and Software Configuration Management Plan shall be drawn up at the start of the project (i.e., outside SafeScrum) and be maintained throughout the software development life cycle. For IEC 61508, this holds also for hardware and for tools of category T2 and T3 plus the documents listed in part 3, section The important thing for SafeScrum is to have a procedure at the start of each sprint where all plans are updated when necessary. This can be done either by the SafeScrum team itself as part of the sprint planning process or by the people who developed the plans, using information from the SafeScrum team. EN also requires that all information related to testing e.g., environment, tools and software shall be included in CM. Note also that the standard requires all components to be under CM before we start documented testing. Testing done during development using e.g., TDD does not need to be included. In most projects, documented testing only includes integration testing and system testing. The only part that we need to go through in some detail is IEC 61508, part 3, section This section specifies that we shall Have administrative and technical control throughout the lifecycles Apply the correct change control procedures and document all relevant information for later safety audits i.e., that the CM job is done properly Have control over all identified configuration items Formally document the releases of safety-related software An important challenge to the SafeScrum process is the first statement: administrative control throughout the lifecycles. For the other CM requirements, the challenge for SafeScrum is not to fulfil the requirements but to decide how often and under what circumstances. Most of the information needed for efficient CM is created automatically by tools. We suggest the following approach: Management decides at which milestones a new configuration should be defined. This is done before the project starts and is mentioned in the CM plan. The responsibility for managing the CM is normally assigned to the quality assurance department (QA). All code and data are tagged during check-in. The tags are administrated by the QA but used by the SafeScrum team. The QA and the SafeScrum team have regular meetings that focus on CM and other QA-related issues. EN adds some requirements all components shall have a CM history attached to it and that the validation report and configuration data shall be included in the documents under CM. In addition, the integrations shall identify the hardware and software components used. It is also worth mentioning that EN requires that each component shall be under CM before we start documented testing. Thus, the components need not be under CM during test-driven development.

10 To sum up; we have considered all requirements to CM in IEC and EN There are no practises in SafeScrum that prevent or hinder the use of standard CM methods and procedures. SafeScrum needs two add-ons (1) tagging of code and data at check-in and (2) regular meetings between the SafeScrum tam and the company s QA-department. 5.4 Threats to Validity As always with this type of discussions, there are two threats to the validity of our discussions and conclusion: (1) have we understood the standards and (2) have we understood CM. We claim that we have understood The two standards, based on the practical experiences the two authors have with the standards one is a certified assessor for EN while the other author has worked with IEC in industrial settings. CM, based on the practical experience of one of the authors with software development 6 Summary and Conclusions We have had a detailed walk-through of the two standards IEC and EN with focus on CM and change management when we use an agile development process in this case SafeScrum. The challenges related to CM increase when we use agile development since changes will be more frequent. There are just a few requirements in either of the standards that prevent the use of SafeScrum as is. The following changes (additions) are needed: A new process at the start of each sprint to do necessary updates to the CM plan when needed. The SafeScrum team should cooperate with QA in this process. A separation of testing into development tests e.g., TDD which is the responsibility of the SafeScrum team and system and integration tests, which are the responsibility of the RAMS process All tools used, all documents generated and all plans should be under CM. An efficient tracing tool is needed, e.g., to keep track of the relationships between user stories, test cases and code In addition we suggest changes to the two standards under discussion in order to make the requirements goal-based in order to be able to keep up with new ideas and concepts in software engineering.

11 Acknowledgements This work was partially funded by the Norwegian Research Council under grant # (the SUSS project). References 1. Rey-Mermet, B.: Agile Configuration Management-overview, 2013, May Norin, J.: Lean Configuration Management. Evolving the CM Discipline Through the Agile Paradigm Shift. 3. Lindroth-Olson, Prentare, O.: What, When, Why and How. Introducing Software Configuration Management in Agile Projects. February 28, Koskela, J.: Software configuration management in agile methods. VTT-publications 514, Espoo Moreira, ME.: Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed, Wiley ISBN: October Jonassen Hass, AM.: Configuration Management Principles and Practice Addison-Wesley Professional 7. Black, R.: Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing, John Wiley and Sons, 2002, ISBN , Stålhane, T, Myklebust, T. and Hanssen, GK.: The application of Safe Scrum to IEC certifiable software. ESREL, Helsinki Stålhane, T., Hanssen, GK., Myklebust, T. and Haugset, B.: Agile Change Impact Analysis of Safety Critical Software, SASSUR, 2014, Florence, Italy 10. IEEE: Standard Glossary of Software Terminology. IEEE Std Bjerke-Gulstuen, K., Wiik Larsen, E., Stålhane, T., Dingsøyr, T.: High level test driven development Shift Left: How a large-scale agile development project organized testing, XP2015, Helsinki, Finland 12. IEEE: Standard for Configuration Management in Systems and Software Engineering, IEEE Std

Change Impact analysis

Change Impact analysis 1 Change Impact analysis and the safety standard IEC 61508:2010 series Author and presenter: Thor Myklebust SINTEF ICT Authors: Tor Stålhane, IDI NTNU Geir Hanssen, SINTEF ICT Børge Haugset, SINTEF ICT

More information

Agile Software Development Methodologies and Its Quality Assurance

Agile Software Development Methodologies and Its Quality Assurance Agile Software Development Methodologies and Its Quality Assurance Aslin Jenila.P.S Assistant Professor, Hindustan University, Chennai Abstract: Agility, with regard to software development, can be expressed

More information

The application of Safe Scrum to IEC 61508 certifiable software

The application of Safe Scrum to IEC 61508 certifiable software The application of Safe Scrum to IEC 61508 certifiable software Tor Stålhane a*, Thor Myklebust b, Geir Hanssen b a NTNU, Trondheim, Norway b SINTEF ICT, Trondheim, Norway Abstract: In order to develop

More information

An Agile Development Process for Petrochemical Safety Conformant Software

An Agile Development Process for Petrochemical Safety Conformant Software An Agile Development Process for Petrochemical Safety Conformant Software Thor Myklebust MSc, SINTEF Tor Stålhane, PhD, IDI NTNU Narve Lyngby MSc, SINTEF Key Words: SafeScrum, IEC 61511, Safety-Critical

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

Change Impact Analysis in Agile Development. Abstract

Change Impact Analysis in Agile Development. Abstract Change Impact Analys in Agile Development Tor Stålhane Norwegian University of Science and Technology +47 73594484, stalhane@idi.ntnu.no Vikash Katta OECD Halden Reactor Project and Norwegian University

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

Topics covered. Agile methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods

Topics covered. Agile methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods Topics covered Chapter 3 Agile Software Development Agile methods Plan-driven and agile Extreme programming Agile project management Scaling agile methods 1 2 Need for rapid software Rapid software Changing

More information

CHAPTER 7 Software Configuration Management

CHAPTER 7 Software Configuration Management CHAPTER 7 Software Configuration Management ACRONYMS CCB CM FCA MTBF PCA SCCB SCI SCM SCMP SCR SCSA SEI/CMMI SQA SRS USNRC INTRODUCTION Configuration Control Board Configuration Management Functional Configuration

More information

PM Planning Configuration Management

PM Planning Configuration Management : a Project Support Function As stated throughout the Project Planning section, there are fundamental components that are started during the pre-performance stage of the project management life cycle in

More information

Agile development of safety-critical software while meetings standards' requirements

Agile development of safety-critical software while meetings standards' requirements 1(37) Agile development of safety-critical software while meetings standards' requirements Matti Vuori, Tampere University of Technology 2011-11-04 Contents 1/2 A study in Ohjelmaturva 4 Tendency to be

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

U.S. Department of Energy

U.S. Department of Energy U.S. Department of Energy Washington, D.C. NOTICE DOE N 203.1 Approved: Expires: 06-02-01 SUBJECT: SOFTWARE QUALITY ASSURANCE 1. OBJECTIVES. To define requirements and responsibilities for software quality

More information

Comparing Agile Software Processes Based on the Software Development Project Requirements

Comparing Agile Software Processes Based on the Software Development Project Requirements CIMCA 2008, IAWTIC 2008, and ISE 2008 Comparing Agile Software Processes Based on the Software Development Project Requirements Malik Qasaimeh, Hossein Mehrfard, Abdelwahab Hamou-Lhadj Department of Electrical

More information

Nova Software Quality Assurance Process

Nova Software Quality Assurance Process Nova Software Quality Assurance Process White Paper Atlantic International Building 15F No.2 Ke Yuan Yi Road, Shiqiaopu, Chongqing, P.R.C. 400039 Tel: 86-23- 68795169 Fax: 86-23- 68795169 Quality Assurance

More information

Basic Trends of Modern Software Development

Basic Trends of Modern Software Development DITF LDI Lietišķo datorsistēmu programmatūras profesora grupa e-business Solutions Basic Trends of Modern Software Development 2 3 Software Engineering FAQ What is software engineering? An engineering

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

Agile Software Development compliant to Safety Standards?

Agile Software Development compliant to Safety Standards? DB AG/Christian Bedeschinski www.thalesgroup.com/germany Agile Software Development compliant to Safety Standards? Christian Scholz Thales Transportation Systems 2 / Content Motivation Agile Software Development

More information

Software Engineering

Software Engineering 1 Software Engineering Lecture 2: Software Life Cycles Stefan Hallerstede Århus School of Engineering 25 August 2011 2 Contents Naive Software Development Code & Fix Towards A Software Process Software

More information

Rapid Software Development

Rapid Software Development Software Engineering Rapid Software Development Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain how an iterative, incremental development process leads to faster delivery

More information

www.testing-solutions.com TSG Quick Reference Guide to Agile Development & Testing Enabling Successful Business Outcomes

www.testing-solutions.com TSG Quick Reference Guide to Agile Development & Testing Enabling Successful Business Outcomes www. TSG Quick Reference Guide to Agile Development & Testing Enabling Successful Business Outcomes What is Agile Development? There are various opinions on what defines agile development, but most would

More information

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 18-19 The Unified Process Static dimension Glossary UP (Unified

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

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of

More information

Agile So)ware Development

Agile So)ware Development Software Engineering Agile So)ware Development 1 Rapid software development Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast

More information

Agile Software Engineering Practice to Improve Project Success

Agile Software Engineering Practice to Improve Project Success Agile Software Engineering Practice to Improve Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems dietmar.winkler@qse.ifs.tuwien.ac.at

More information

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Year 2014, Vol. 1, issue 1, pp. 49-56 Available online at: http://journal.iecuniversity.com TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Singh RANDEEP a*, Rathee AMIT b a* Department of

More information

Axe in the Agile World

Axe in the Agile World Axe in the Agile World WHITE PAPER Executive Summary This paper explains the way in which Axe (Odin s Enterprise Test Automation Platform) allows the automated testing to take place in a range of project

More information

Controlling Change on Agile Software Development Projects

Controlling Change on Agile Software Development Projects Universal Journal of Management 4(1): 42-49, 2016 DOI: 10.13189/ujm.2016.040106 http://www.hrpub.org Controlling Change on Agile Software Development Projects Andrew L Ecuyer 1, Syed Adeel Ahmed 2,* 1

More information

Engineering. Software. Eric J. Braude. Michael E. Bernstein. Modern Approaches UNIVERSITATSBIBLIOTHEK HANNOVER ' TECHNISCHE INFORM ATIONSBIBLIOTHEK

Engineering. Software. Eric J. Braude. Michael E. Bernstein. Modern Approaches UNIVERSITATSBIBLIOTHEK HANNOVER ' TECHNISCHE INFORM ATIONSBIBLIOTHEK Software Engineering Modern Approaches SECOND EDITION Eric J. Braude Boston University, Metropolitan College Michael E. Bernstein Boston University, Metropolitan College TECHNISCHE INFORM ATIONSBIBLIOTHEK

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

CSE 435 Software Engineering. Sept 16, 2015

CSE 435 Software Engineering. Sept 16, 2015 CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process

More information

Configuration & Build Management

Configuration & Build Management Object-Oriented Software Engineering Using UML, Patterns, and Java Configuration & Build Management Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration

More information

Software Life Cycles and Configuration Management

Software Life Cycles and Configuration Management Theory Lecture Plan 2 Software Configuration Lecture 11 Software Engineering TDDC88/TDDC93 autumn 2008 Department of Computer and Information Science Linköping University, Sweden L1 - Course Introduction

More information

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

Table of contents. Performance testing in Agile environments. Deliver quality software in less time. Business white paper

Table of contents. Performance testing in Agile environments. Deliver quality software in less time. Business white paper Performance testing in Agile environments Deliver quality software in less time Business white paper Table of contents Executive summary... 2 Why Agile? And, why now?... 2 Incorporating performance testing

More information

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...

More information

Introduction to Agile Software Development

Introduction to Agile Software Development Introduction to Agile Software Development Word Association Write down the first word or phrase that pops in your head when you hear: Extreme Programming (XP) Team (or Personal) Software Process (TSP/PSP)

More information

In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is:

In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: The period of time that starts when a software product is conceived and ends when the product is no longer

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

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

Test-Driven Approach for Safety-Critical Software Development

Test-Driven Approach for Safety-Critical Software Development Test-Driven Approach for Safety-Critical Software Development Onur Özçelik 1,2*, D. Turgay Altilar2 1 Scientific 2 and Technological Research Council of Turkey, 41470 Kocaeli, Turkey. Department of Computer

More information

Software Configuration Management Plan

Software Configuration Management Plan For Database Applications Document ID: Version: 2.0c Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 22 Copyright 2000-2005 Digital Publications LLC.

More information

Functional Safety Management: As Easy As (SIL) 1, 2, 3

Functional Safety Management: As Easy As (SIL) 1, 2, 3 Functional Safety Management: As Easy As (SIL) 1, 2, 3 Abstract This paper outlines the need for planning in functional safety management. Recent events such as the Montara blowout and the Deepwater Horizon

More information

Achieving ISO 9001 Certification for an XP Company

Achieving ISO 9001 Certification for an XP Company Achieving ISO 9001 Certification for an XP Company Graham Wright Development Team Coach Workshare 20 Fashion Street London, E1 6PX (44) 020 7539 1361 graham.wright@workshare.com Abstract It is generally

More information

Agile Projects 7. Agile Project Management 21

Agile Projects 7. Agile Project Management 21 Contents Contents 1 2 3 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management

More information

Software Engineering. An Introduction. Fakhar Lodhi

Software Engineering. An Introduction. Fakhar Lodhi Software Engineering An Introduction Fakhar Lodhi 1 Engineering The science concerned with putting scientific knowledge to practical use. Webster s Dictionary Physics versus Electrical Engineering 2 Software

More information

Agile and Secure Can We Be Both? Chicago OWASP. June 20 th, 2007

Agile and Secure Can We Be Both? Chicago OWASP. June 20 th, 2007 Agile and Secure Can We Be Both? Chicago OWASP June 20 th, 2007 The Agile Practitioner s Dilemma Agile Forces: Be more responsive to business concerns Increase the frequency of stable releases Decrease

More information

SOFTWARE DEVELOPMENT METHODOLOGIES, TRENDS, AND IMPLICATIONS

SOFTWARE DEVELOPMENT METHODOLOGIES, TRENDS, AND IMPLICATIONS SOFTWARE DEVELOPMENT METHODOLOGIES, TRENDS, AND IMPLICATIONS Xihui Zhang University of North Alabama xzhang6@una.edu Hua Dai University of Wisconsin-La Crosse dai.hua@uwlax.edu Tao Hu King College thu@king.edu

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

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Requirements-driven Verification Methodology for Standards Compliance

Requirements-driven Verification Methodology for Standards Compliance Requirements-driven Verification Methodology for Standards Compliance Serrie-justine Chapman (TVS) serrie@testandverification.com Mike Bartley (TVS) mike@testandverification.com Darren Galpin (Infineon)

More information

Configuration management. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1

Configuration management. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1 Configuration management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1 Objectives To explain the importance of software configuration management (CM) To describe key CM activities

More information

Clinical Risk Management: Agile Development Implementation Guidance

Clinical Risk Management: Agile Development Implementation Guidance Document filename: Directorate / Programme Document Reference NPFIT-FNT-TO-TOCLNSA-1306.02 CRM Agile Development Implementation Guidance v1.0 Solution Design Standards and Assurance Project Clinical Risk

More information

5 FAH-5 H-520 LIFE CYCLE MANAGEMENT

5 FAH-5 H-520 LIFE CYCLE MANAGEMENT 5 FAH-5 H-520 LIFE CYCLE MANAGEMENT (CT:ITS-5; 02-05-2013) (Office of Origin: (IRM/BMP/SPO/PM) 5 FAH-5 H-521 CONFIGURATION MANAGEMENT REQUIREMENTS Configuration management (CM) is a function deployed throughout

More information

Agile Software Development

Agile Software Development Agile Software Development Application in the Medical Device Industry Kelly Weyrauch Medtronic, Inc. (29 April 2008) Introduction Purpose Provide an introduction to Agile Software Development as it applies

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

CONFIGURATION MANAGEMENT PLAN GUIDELINES

CONFIGURATION MANAGEMENT PLAN GUIDELINES I-680 SMART CARPOOL LANE PROJECT SYSTEM ENGINEERING MANAGEMENT PLAN CONFIGURATION MANAGEMENT PLAN GUIDELINE SECTIONS: PLAN GUIDELINES 1. GENERAL 2. ROLES AND RESPONSIBILITIES 3. CONFIGURATION MANAGEMENT

More information

Configuration Management. Software Configuration Management. Example of System Families. Configuration Management

Configuration Management. Software Configuration Management. Example of System Families. Configuration Management Configuration Management Software Configuration Management New versions of software systems are created as they change: For different machines/os; Offering different functionality; Tailored for particular

More information

SOE. managing change in system development projects: configuration management

SOE. managing change in system development projects: configuration management SOE managing change in system development projects: configuration management 2 3 understanding the problem of change change is one of the most fundamental characteristics in any software development process

More information

Transition to Agile Development

Transition to Agile Development 2010 18th IEEE International Requirements Engineering Conference Transition to Agile Development Rediscovery of Important Requirements Engineering Practices Juha Savolainen Nokia Research Center Nokia

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

Chapter 25 Configuration Management. Chapter 25 Configuration management

Chapter 25 Configuration Management. Chapter 25 Configuration management Chapter 25 Configuration Management 1 Topics covered Change management Version management System building Release management 2 Configuration management Because software changes frequently, systems, can

More information

Scrum and Testing The end of the test role Bryan Bakker 20 maart 2012

Scrum and Testing The end of the test role Bryan Bakker 20 maart 2012 Scrum and Testing The end of the test role Bryan Bakker 20 maart 2012 voordracht georganiseerd door Discussiegroep Software Testing met de steun van Ingenieurshuis, Antwerpen Scrum and Testing... The end

More information

Practical Experiences of Agility in the Telecom Industry

Practical Experiences of Agility in the Telecom Industry Practical Experiences of Agility in the Telecom Industry Jari Vanhanen 1, Jouni Jartti 2, and Tuomo Kähkönen 2 1 Helsinki University of Technology, Software Business and Engineering Institute, P.O. Box

More information

Software Configuration Management. Addendum zu Kapitel 13

Software Configuration Management. Addendum zu Kapitel 13 Software Configuration Management Addendum zu Kapitel 13 Outline Purpose of Software Configuration Management (SCM) Motivation: Why software configuration management? Definition: What is software configuration

More information

INTERNATIONAL JOURNAL OF ADVANCES IN COMPUTING AND INFORMATION TECHNOLOGY An International online open access peer reviewed journal

INTERNATIONAL JOURNAL OF ADVANCES IN COMPUTING AND INFORMATION TECHNOLOGY An International online open access peer reviewed journal INTERNATIONAL JOURNAL OF ADVANCES IN COMPUTING AND INFORMATION TECHNOLOGY An International online open access peer reviewed journal Research Article ISSN 2277 9140 ABSTRACT Analysis and tabular comparison

More information

PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL

PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL Sanja Vukićević 1, Dražen Drašković 2 1 Faculty of Organizational Sciences, University of Belgrade, vukicevicsanja@yahoo.com 2 Faculty

More information

Lean Configuration Management

Lean Configuration Management A Softhouse White Paper Jens Norin Daniel Karlström September 2006 Softhouse Consulting, Stormgatan 14, SE-211 20 Malmö info@softhouse.se www.softhouse.se Contents Abstract...3 Introduction...4 Software

More information

Design of automatic testing tool for railway signalling systems software safety assessment

Design of automatic testing tool for railway signalling systems software safety assessment Risk Analysis VI 513 Design of automatic testing tool for railway signalling systems software safety assessment J.-G. Hwang 1, H.-J. Jo 1 & H.-S. Kim 2 1 Train Control Research Team, Korea Railroad Research

More information

Revision History Revision Date 3.0 14.02.10. Changes Initial version published to http://www.isasecure.org

Revision History Revision Date 3.0 14.02.10. Changes Initial version published to http://www.isasecure.org SDLA-312 ISA Security Compliance Institute Security Development Lifecycle Assurance - Security Development Lifecycle Assessment v3.0 Lifecycle Phases Number Phase Name Description PH1 Security Management

More information

Agile and Secure: Can We Be Both?

Agile and Secure: Can We Be Both? Agile and Secure: Can We Be Both? OWASP AppSec Seattle Oct 2006 Keith Landrus Director of Technology Denim Group Ltd. keith.landrus@denimgroup.com (210) 572-4400 Copyright 2006 - The OWASP Foundation Permission

More information

A Capability Maturity Model (CMM)

A Capability Maturity Model (CMM) Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability

More information

Automated Acceptance Testing of High Capacity Network Gateway

Automated Acceptance Testing of High Capacity Network Gateway Automated Acceptance Testing of High Capacity Network Gateway Ran Nyman 1, Ismo Aro 2, Roland Wagner 3, 1,2,3 Nokia Siemens Network, PO Box 1 FI-02022 Nokia Siemens Networks 1 ran@rannicon.com, 2 ismo.aro@nsn.com,

More information

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca Using Simulation to teach project management skills Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca Agenda of the workshop 1 The software project management theory overview (40 minutes) 2 Why use SDLC

More information

Lean Software Configuration Management Using 'Process Increments' Software Engineering Competence Center

Lean Software Configuration Management Using 'Process Increments' Software Engineering Competence Center Lean Software Configuration Management Using 'Process Increments' Software Engineering Competence Center Copyright Software Engineering Competence Center 2011 Agenda Process Increments Method Overview

More information

SOFTWARE PROCESS MODELS

SOFTWARE PROCESS MODELS SOFTWARE PROCESS MODELS Slide 1 Software Process Models Process model (Life-cycle model) - steps through which the product progresses Requirements phase Specification phase Design phase Implementation

More information

September 25, 2014 EFFECTIVE METHODS FOR SOFTWARE AND SYSTEMS INTEGRATION P R E S E N T E D B Y: D R. B O Y D L. S U M M E R S

September 25, 2014 EFFECTIVE METHODS FOR SOFTWARE AND SYSTEMS INTEGRATION P R E S E N T E D B Y: D R. B O Y D L. S U M M E R S September 25, 2014 EFFECTIVE METHODS FOR SOFTWARE AND SYSTEMS INTEGRATION P R E S E N T E D B Y: D R. B O Y D L. S U M M E R S 1 Software Engineer (Quality) Defense and Space The Boeing Company - Seattle,

More information

Page 1. Outline of the Lecture. What is Software Configuration Management? Why Software Configuration Management?

Page 1. Outline of the Lecture. What is Software Configuration Management? Why Software Configuration Management? Books: Software Configuration Management 1. B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering: Using UML, Patterns, and Java (Chapter 13) Outline of the Lecture Purpose of Software Configuration

More information

Web Application Development Processes: Requirements, Demands and Challenges

Web Application Development Processes: Requirements, Demands and Challenges Web Application Development Processes: Requirements, Demands and Challenges THAMER AL-ROUSAN 1, BASEM HADIDI 2, SHADI ALJAWARNEH 3 1, 3 Faculty of Science and Information Technology, Isra University, Amman,

More information

Certified Professional in Configuration Management Glossary of Terms

Certified Professional in Configuration Management Glossary of Terms Certified Professional in Configuration Management Glossary of terms used in Configuration Management Issue 2007.07 Association of the International Certified Configuration Manager e.v. Copyright 2007,

More information

Atomate Development Process. Quick Guide

Atomate Development Process. Quick Guide Development Process Quick Guide METHODOLOGY Every project is unique You know your business inside out. You have thought and planned your ideas carefully and are keen to see it live as soon as possible.

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

Agile in a Safety Critical world

Agile in a Safety Critical world Agile in a Safety Critical world Julian Goddard 24/11/2014 26/11/14 (c) 2014 Plaxion Limited. All rights reserved. 1 Contents Introductions The pervasiveness of software Agile review Safety Critical software

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

www.pwc.com Scale agile throughout the enterprise A PwC point of view

www.pwc.com Scale agile throughout the enterprise A PwC point of view www.pwc.com Scale agile throughout the enterprise A PwC point of view December 2013 Overview Today it s rare to speak with a company that is not adopting some form of agile development practice. However,

More information

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 Development Process

Software Development Process Software Development Process A software development process, also known as software development lifecycle, is a structure imposed on the development of a software product. Similar terms include software

More information

Agile Scrum Workshop

Agile Scrum Workshop Agile Scrum Workshop What is agile and scrum? Agile meaning: Able to move quickly and easily. Scrum meaning: a Rugby play Agile Scrum: It is an iterative and incremental agile software development framework

More information

An Agile Methodology Based Model for Change- Oriented Software Engineering

An Agile Methodology Based Model for Change- Oriented Software Engineering An Agile Methodology Based Model for Change- Oriented Software Engineering Naresh Kumar Nagwani, Pradeep Singh Department of Computer Sc. & Engg. National Institute of Technology, Raipur nknagwani.cs@nitrr.ac.in,

More information

Information Technology Policy

Information Technology Policy Information Technology Policy Systems Development Life Cycle Policy ITP Number ITP-APP012 Category Recommended Policy Contact RA-itcentral@pa.gov Effective Date May 1, 2013 Supersedes Scheduled Review

More information

Life-Cycle Model. Software Life-Cycle Models. Software Development in Theory. Software Development in Practice

Life-Cycle Model. Software Life-Cycle Models. Software Development in Theory. Software Development in Practice Life-Cycle Model Software Life-Cycle Models Xiaojun Qi It specifies the various phases/workflows of the software process, such as the requirements, analysis (specification), design, implementation, and

More information

The traditional project management uses conventional methods in software project management process.

The traditional project management uses conventional methods in software project management process. Volume 5, Issue 1, January 2015 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com Analysis of

More information

Software Development Life Cycle at SSPL. An Summary of Methodologies We Offer

Software Development Life Cycle at SSPL. An Summary of Methodologies We Offer Software Development Life Cycle at SSPL An Summary of Methodologies We Offer 10/29/2009 Table of Contents The SSPL Advantage... 2 Commonly Used SDLC Models at SSPL... 2 Waterfall Model... 2 Agile Model...

More information

Appendix H Software Development Plan Template

Appendix H Software Development Plan Template Appendix H Software Development Plan Template Version 2 March 7, 2005 This page is intentionally left blank. Version 2 March 7, 2005 Title Page Document Control Panel Table of Contents List of Acronyms

More information

Development models. 1 Introduction. 2 Analyzing development models. R. Kuiper and E.J. Luit

Development models. 1 Introduction. 2 Analyzing development models. R. Kuiper and E.J. Luit Development models R. Kuiper and E.J. Luit 1 Introduction We reconsider the classical development models: the Waterfall Model [Bo76], the V-Model [Ro86], the Spiral Model [Bo88], together with the further

More information

Configuration Management. CxOne Standard

Configuration Management. CxOne Standard Configuration Management CxOne Standard CxStand_ConfigurationManagement.doc November 4, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW...

More information

Agile Techniques for Object Databases

Agile Techniques for Object Databases db4o The Open Source Object Database Java and.net Agile Techniques for Object Databases By Scott Ambler 1 Modern software processes such as Rational Unified Process (RUP), Extreme Programming (XP), and

More information

Medical Device Software - Software Life Cycle Processes

Medical Device Software - Software Life Cycle Processes 1 Medical Device Software - Software Life Cycle Processes IEC 62304 2 Credits John F. Murray Software Compliance Expert U.S. Food and Drug Administration Marcie R. Williams Medical Device Fellow Ph.D.

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