1 1(37) Agile development of safety-critical software while meetings standards' requirements Matti Vuori, Tampere University of Technology
2 Contents 1/2 A study in Ohjelmaturva 4 Tendency to be agile 5 Benefits of Agile according to Larman (2004) 6 Benefits in different product development settings 7 Positive conclusions for agile safety-critical development 8 Different goals => different approaches to Agile 10 Risks of new processes 11 Risk analysis of the transformation 12 Problems in Agile culture according to Kruchten (2011) 13 No generic "safety-critical system" under development 15 What we need to do in agile way? 16 What is forgotten in agile?... Hybrid approaches are needed 17 Anatomy of agile development 18 Lean 19 Guidance for going agile 20
3 Contents 2/2 Prerequisites 21 Ten generic guidelines for process development 23 Develop basic elements that provide value for any process model 26 Make rules clear 27 Communication and collaboration 28 Make time-consuming phases efficient 29 Provide control 30 Split the process 31 Increase number of releases 32 Add any other practices that bring value 33 Continuous improvement 34 Read the report for more info 35 References 36
4 4(37) A study in Ohjelmaturva Identification of agile principles, process and activity elements and practices that are key issues from the viewpoint of developing safety-critical software systems. Analysis of the identified elements: risks of applying of them, how they should be supplemented, modified or avoided. Mapping of essential development tasks, quality and safety assurance into a generic agile development framework. Synthesis of key issues for guidance in process tailoring and development in companies. IEC 61508(-3) as context. The safety-criticality of the context of the study was moderate. We assessed mostly the safety integrity levels SIL levels 1, 2 and 3.
5 5(37) Tendency to be agile There is a tendency for companies to transform their software and product development practice into more incremental form. Agile project management models. Agile software lifecycle models. Practices from Agile culture. The main value of agile processes comes from controlled increments and releases, which they produce more often than previous models. Controlled releases should especially help in getting feedback from the customer and to manage project risks. Familiar in other domain, now also in safety-critical development. However, the question still is, how it can be done so that any project features safety, of course, being critical are not compromised.
6 Benefits of Agile according to Larman (2004) 6(37) Iterative development is lower risk; the waterfall is higher risk. Early risk mitigation and discovery. Accommodates and provokes early change; consistent with new product development. Manageable complexity. Confidence and satisfaction from early, repeated success. Early partial product. Relevant process tracking; better predictability. Higher quality; less defects. Final product better matches true client desires. Early and regular process improvement. Communication and engagement required. IKIWISI required [IKIWISI = I ll Know It When I See It].
7 Benefits in different product development settings 7(37) Customer benefits in the development of tailored systems: Getting an early release and understanding of the system by using it. Getting regular releases at a sensible pace so that the new system can be learned and all necessary adaptations can be made in time. Ability to make changes to plans during the process in a flexible way. Benefits in mass-market product development: Manufacturer s desire to control risks. Ability to be fast in responding to competition and emerging market needs.
8 Positive conclusions for agile safetycritical development 1/2 8(37) Customers need time to understand all safety percussions and early releases allow for that. Communicating design and safety information is easier, as agile emphasises verbal communication, not just written documentation. If a new technology should prove to be unreliable, the situation can be detected early and changes be made. Risk analysis has a gradually evolving scope (the concept), which should improve its quality. Safety assessments made in small increments can be more focused, delivering better results.
9 Positive conclusions for agile safetycritical development 2/2 9(37) A rhythmic process of integration at all levels, from code to customer production systems should reduce many kinds of problems. Even if the increments are not targeted for production, their behaviour can be well tested, assessed and understood in simulation. Any corrective measures can be based on practical observations from executing the system, not just analysis. Agile can provide a good learning experience for all involved, if applied properly.
10 Different goals => different approaches to Agile 10(37) Goals influence how companies approach the development process. Some companies may start the agile process with a very vague idea of a concept. Some may see it as a way to make software production more controlled Others simply aim to get a row of productive solutions, new releases to customers. => All these require different processes and activities. Release orientation and release readiness are seen as a key element of agile approaches.
11 11(37) Risks of new processes Safety-critical development is all about managing risks. Just as in taking new components into use, new ways of action need to be carefully analysed. Suitability. Risks. What the change influences. Business risks, safety risks, quality risks. Etc... Boehm and Turner present a rule that is particularly well suited to safety-critical development: Is it riskier for me to apply (more of) this process component or to refrain from applying it?
12 12(37) Risk analysis of the transformation A risk analysis should be made for the process change in order to identify potential pitfalls. A transformation of project practices is very much a cultural change. Pure processes are easy to change, but in software development it is a question of how people work together. Elements of software process practices, processes, techniques and tools can be thought to form a toolbox of items that we are free to choose from. There many moments when we need to make a decision: shall we use that particular practice or not?
13 Problems in Agile culture according to Kruchten (2011) 1/2 13(37) 1. Commercial interests censoring failure. 2. Pretending agile is not a business. 3. Failure to dampen negative behaviour. 4. Context and Contextual applicability of practices. 5. Context gets in the way of dogma. 6. Hypocrisy. 7. Politic. 8. Anarchism. 9. Elitism. 10.Agile Alliance.
14 Problems in agile culture according to Kruchten (2011) 2/2 14(37) 11.Certification (the zombie elephant ). 12.Abdicating responsibility for product success (to others, e.g., product owners). 13.Business value. 14.Managers and management are bad. 15.Culture. 16.Role of architecture and design. 17.Self-organising team. 18.Scaling naïveté (e.g., scrum of scrums). 19.Technical debt. 20.Effective ways of discovering info without writing source code.
15 No generic "safety-critical system" under development 15(37) Type of product and system. From medical devices to machines to nuclear power plants. The role of software in the system. Is it mainly a software-based system or is software still only in a restricted role and the product is perceived as a mechanical device, for example. The size and scope of the system. Clearly small personal devices require a very differ-ent approach to large plant level systems. The risk level of the system. Factory machines have a very different risk level than nu-clear power plants.
16 16(37) What we need to do in agile way? The process in IEC has this kind of properties: Emphasis not up-front or end phases, but both and all inbetween! Requirement specification based on the overall system. Quality of architecture. Quality of plans and implementation. Quality of verification testing etc. Safety assessessment whenever designs change. Validation in relation to what really is needed in the context of the overall system. Solid documenting with not gaps. Very strong configuration management and tracing of things. Competence and roles of process participants. See end of slide set for reference
17 What is forgotten in agile?... Hybrid approaches are needed 17(37) By Coplien & Bjørnvig (2010): Architecture. Handling dependencies between requirements. Foundations for usability. Documentation. Common sense, thinking and caring. Analytical approach. Safety-critical development is very analytical by nature. Must not be lost in transition. Principles of Lean are used to add some missing elements. Agile development is never fully agile. Hybrid methods (see Kennaley (2010)). Each SDLC model is based on history. => Hybrid models allow for choosing essential elements.
18 18(37) Anatomy of agile development Principles (including values). Project model. Software development lifecycle. Software engineering methods, techniques and practices....and beside that the whole global Agile culture...
19 19(37) Lean Lean is an approach that is often associated in the context of agile development. Lean was originally called Lean production, but today Lean represents only a vision of good efficient way of action. It has been applied mostly in manufacturing industries, but lately it has been coming into the software development world to complement agile development (see for example Poppendieck (2007)). Therefore, we included analysis of Lean principles in our study. Yet, Lean actually has very different principles than Agile. More about this in the report (Vuori, 2011).
20 Guidance for going agile 20(37) Based on the study we offer the following guidance to companies who aim to develop their processes into more agile.
21 21(37) Prerequisites 1/2 Shared sense of a need to change. Agile is not a goal as such, but a means to meet some business or other goals. For any change in an organisation, there should be a clear, shared sense of urgency to change processes and a feeling that the current way of action is not sufficient anymore. Solid process understanding and vision. There should be an understanding of software and product development processes agile and otherwise. The aim is not to be agile as such, but get the best results, meet goals. A nice read: Barry Boehm's and Richard Turner's book "Balancing Agility and Discipline A Guide for the Perplexed".
22 22(37) Prerequisites 2/2 Professionalism in action. Before transformation the organisation needs to be able to fulfil, for example, all the requirements of IEC  or other applicable standards with no problems. That provides a baseline. Experts and collaboration. Expertise on agile is needed in the transformation, to guide the rest of the people in the transformation process. Process people or consultants are needed who can lead the transformation. Agile consultants do not necessarily understand all the process requirements of safety-critical development and the leading principles of safety and risk management. Even world class agile experts may have a limited understanding of testing and verification and validation!
23 Ten generic guidelines for process development 1/3 23(37) 1. Respect your own engineering skills and experiences in the process development. 2. Do not follow fashion. Seek proven practices and analyse their suitability in your environment and culture. 3. Understand that not everything needs to be agile and that more agile will not mean better. 4. Remember that the more safety-critical the system and its development are, the more control is required for the process and that will usually mean less agility. 5. No single paradigm is sufficient. Being just agile or just plan-driven is not enough. Agility in some areas may need less agility in others, for specific process needs and for balance.
24 Ten generic guidelines for process development 2/3 24(37) 6. Much of any company s current activity is tacit in nature and not formulated or documented. Thus, you might be blind to your current success factors. External consultants are often needed to see the essentials in your activities. 7. Safety-critical development is all about managing risks. In the same way, you need to manage the risks of making process changes. 8. Find the style that is best for you, is the message in all development. If you act like everyone else, how could you be the best in your branch?
25 Ten generic guidelines for process development 3/3 25(37) 8. Process developments are never just mechanistic process issues. Agility needs to fit into the corporate culture, which is a hard thing to change. 10. Co-operation and collaboration between all stakeholders is one key issue in Agile. The same applies to process development.
26 Develop basic elements that provide value for any process model 26(37) More thorough unit testing and code quality assurance. So that there is a solid base for changing the product. Continuous integration so that there is always a working product at hand, to assess how it behaves and to learn from it. Test automation. Automating as many as possible of the tasks that are required for efficient verification and validation, yet supporting many test paradigms (among others exploratory testing) for diversity and test effectiveness. Agile process automation. Automated reporting tools and information systems that can easily be tailored to changing situations in a project. Automated tracing. When a requirement or design or implementation is being planned to change, or has changed, tools are needed to see immediately what it affects and what also needs to be addressed.
27 27(37) Make rules clear Who owns the products, the product business and safety? Who owns the development process? What are the principles of product development? Is it customer-led or innovation-led? Both may require different processes and participation. How do we weight the stakeholders' opinions. Is product development a democratic process or is some party clearly leading it? How open do we really want to be towards the customers? How much do we really wish to engage subcontractors?
28 28(37) Communication and collaboration More self-reflection is needed in the process. All participants need to look into the product and process frequently to see what in their way of action needs to be improved. This calls for frequent lessons learned / retrospect meetings in the process. Team building and improved leading of teams. Teams need to able to work as teams and learning that, and learning to lead teams in more collaborative ways, takes a time. Improved communications tools. Anything that helps people to communicate better, yet provides a peaceful environment for those tasks and for persons that will benefit from it. Improved communication between distributed sites (including any subcontractor sites). No party should be left in a secondary role in communication.
29 29(37) Make time-consuming phases efficient Creation of external processes outside the incremental main development process. Clear understanding of at what times the validation related tasks need to be carried out. Making a very clear distinction between safety-critical and other requirements, and SIL levels So that the elements requiring validation or re-validation can be identified exactly. Efficient information systems so that any paperwork or routines or finding and checking of development records do not take time. Flexible arrangements for validation. If external validators are used, the situation can be reassessed could the validation be carried out internally?
30 30(37) Provide control Split requirements into smaller items, aiming for similar size to aid in planning and estimation. Improve meetings make them more frequent, get all people to participate; develop meeting cultures. Create dashboards and information systems that visualize the project's status to every-one.
31 31(37) Split the process A chain of events from planning of what to do, to evaluation of what has been achieved. Aiming for a demonstrative whole at the end of each increment. True planning in the beginning of an increment. Utilising real product development practices in defining requirements. That is, the input should be something that provides value: new use case, user story or similar, but NOT a technical specification or a change request. Change requests belong in the domain of maintenance, not in the domain of new product development lifecycle.
32 32(37) Increase number of releases Practice the making of release plans that are rougher and based on value and risk, not just technology and functions. The increment-based lifecycle can be exercised during implementing select features to implement and test during an increment and in the second phase, transfer more design work inside the increments. At the same time, the practices of architecture design need to be developed so that it can also evolve sufficiently. Development of release processes and practices so that all steps leading to the customer s utilisation of the product are as efficient as possible, yet do not compromise safety in any way. When the processes are in good shape, releases can be added in a controllable manner if there is benefit gained from that.
33 33(37) Add any other practices that bring value There are and will be many good practices in the agile culture. The idea is not to implement all of them, but only those that really bring value. For example, while pair programming an important old agile practice seems to have lost its appeal somewhat lately, it could be a tool in transferring practical knowledge and experience from older developers to new developer generation. Any mature software development shall not restrict its views to one paradigm only. The current agile culture did not just emerge, but is a result of process evolution, combining ideas and practices into a new whole. So, for new process development ideas one should look into many relevant areas, not just agility. Yet, in agile, things need to be kept simple.
34 34(37) Continuous improvement Keep improving the process and meeting any problems one at a time. The agile processes applied need to be developed further, just like any processes. Processes are only optimal in a given context and learning changes that not to mention any external influences from technology, changing standards and so on. Continuous improvement should have an important role in any organisation.
35 Read the report for more info 35(37) The full report, containing much more information: Vuori, M Agile Development of Safety-Critical Software. Tampere University of Technology. Department of Software Systems. Report p. Available at:
36 36(37) References 1/2 Vuori, M Agile Development of Safety-Critical Software. Tampere University of Technology. Department of Software Systems. Report p. Available at: Wikipedia. Agile software development. Available at: Larman, C.. Agile and Iterative Development. A Manager s Guide. Addison-Wesley. 342 p. Kruchten, P The Elephants in the Agile Room. Philippe Kruchten's Weblog. Available at:
37 37(37) References 2/2 Kennaley, M SDLC 3.0. Beyond a Tacit Understanding of Agile. Towards the next generation of Software Engineering. Fourth Medium Press. 280 p. Poppendieck, M. & T Implementing Lean Software Development: From Concept to Cash. Addison-Wesley. 276 p. Boehm, B. & Turner, R Balancing Agility and Discipline A Guide for the Perplexed. Addison Wesley. 266 p. Coplien, J.O. & Bjørnvig, G Lean Architecture: for Agile Software Development. Wiley. 376 p.
Tampereen teknillinen yliopisto. Ohjelmistotekniikan laitos. Raportti 14 Tampere University of Technology. Department of Software Systems. Report 14 Matti Vuori Agile Development of Safety-Critical Software
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
Comparing Plan-Driven and Agile Project Approaches A Personal Perspective Presented by: Craig D. Wilson Matincor, Inc. Copyright 2006-2010 2010 Outline Introduction to System Development Methodology Contrasting
Introduction to Software Project Management CITS3220 Software Requirements & Project Management "A project gets a year late one day at a time." "Anything that can be changed will be changed until there
ATAC Model-based testing in modern agile software development How to integrate it into the development process? Project number: ITEA 2 10037 Edited by: Matti Vuori, TUT Date: 2014/03/18 Document version
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
3C05: Unified Software Development Process 1 Unit 5: Unified Software Development Process Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases 2
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
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
A Viable Systems Engineering Approach Presented by: Dick Carlson (email@example.com) Philip Matuzic (firstname.lastname@example.org) i i Introduction This presentation ti addresses systems engineering
www.ijcsi.org 457 Agile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations Prakash.V SenthilAnand.N Bhavani.R Assistant
A Cynical View on Agile Software Development from the Perspective of a new Small-Scale Software Industry Apoorva Mishra Computer Science & Engineering C.S.I.T, Durg, India Deepty Dubey Computer Science
Edith Cowan University Research Online Australian Information Warfare and Security Conference Security Research Institute Conferences 2010 Success of Agile Environment in Complex Projects Abbass Ghanbary
3.0 Methodology 3.1 Introduction In this chapter, five software development life cycle models are compared and discussed briefly. The most suitable system methodology for the proposed system is drawn out.
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
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 email@example.com, 2 firstname.lastname@example.org,
How Silk Central brings flexibility to agile development The name agile development is perhaps slightly misleading as it is by its very nature, a carefully structured environment of rigorous procedures.
Model-Based Conceptual Design through to system implementation Lessons from a structured yet agile approach Matthew Wylie Shoal Engineering Pty Ltd email@example.com Dr David Harvey Shoal Engineering
Agile with XP and Scrum Amit Goel National Agile Software Workshop @ Indore Agile India Conference Agile Software Community of India Disclaimer and Credits Most of material in this presentation has been
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
Enabling Continuous Delivery by Leveraging the Deployment Pipeline Jason Carter Principal (972) 689-6402 Jason.firstname.lastname@example.org Pariveda Solutions, Inc. Dallas,TX Table of Contents Matching
Value, Flow, Quality BCS PRACTITIONER CERTIFICATE IN AGILE SYLLABUS BCS Practitioner Certificate in Agile Introduction: In the last decade Agile has moved from being an idea on the fringe of software development
What is meant by the term, Lean Software Development? Scope of this Report November 2014 This report provides a definition of Lean Software Development and explains some key characteristics. It explores
Agile Development for Application Security Managers www.quotium.com When examining the agile development methodology many organizations are uncertain whether it is possible to introduce application security
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
AGILE FOUNDATION CERTIFICATE SAMPLE FOUNDATION QUESTIONS WITH ANSWERS This document is a set of sample questions, in the style of the Agile Foundation Certificate Examination, which is a 60 question, 1
The Agile Business Analyst IT s all about being Agile? You re working as a Business Analyst in a traditional project environment, specifying the requirements for IT Developers to build. Suddenly everyone
Lean and Agile Development With Scrum (Part 1) Lucio Davide Spano email@example.com firstname.lastname@example.org 3 May 2012 Agile Programming http://www.dilbert.com Traditional Software Development Waterfall
Business Assessment: A Quick-Reference Summary Intro to MIKE2 methodology and phase 1 The methodology that will be used throughout the specialist track is based on the MIKE2 methodology. MIKE stands for
What is Software Engineering Introduction to Software Engineering Prof. Lyle N. Long email@example.com http://www.personal.psu.edu/lnl Sources of Material What is software? Software Engineering, 7 th Edition,
University of Dublin Trinity College ST3006 - Software Engineering Anthony Harrington Department of Computer Science Trinity College Dublin Anthony.Harrington@cs.tcd.ie Lifecycles A software project goes
"Agile Software Engineering" Overview for external offering of ASE ABAP Juergen Heymann, CPO Software Engineering There are many ingredients for successful software projects Experienced Developers Domain
1 www.stephenbarkar.se Lean vs. Agile similarities and differences 2014-08-29 Purpose with the material 2 This material describes the basics of Agile and Lean and the similarities and differences between
What Does a Business Analyst Do on an Agile Project? By Kent J. McDonald Senior Instructor, B2T Training As the use of agile approaches increases, business analysts struggle to determine how their role
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
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
Transdyne Corporation CMMI Implementations in Small & Medium Organizations Using the Agile Methodology to Mitigate the Risks of Highly Adaptive Projects Dana Roberson Quality Software Engineer NNSA Service
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
Agile Processes and Methodologies: A Conceptual Study Sheetal Sharma Amity School of Engineering & Technology Amity University Noida Sheetal.firstname.lastname@example.org Darothi Sarkar Amity School of Engineering &
Product Derivation Process and Agile Approaches: Exploring the Integration Potential Padraig O Leary, Muhammad Ali Babar, Steffen Thiel, Ita Richardson Lero, the Irish Software Engineering Research Centre,
Adopting Agile Testing A Borland Agile Testing White Paper August 2012 Executive Summary More and more companies are adopting Agile methods as a flexible way to introduce new software products. An important
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)
Continuous Delivery Anatomy of the Deployment Pipeline (Free Chapter) by Jez Humble and David Farley Copyright 2011 ThoughtWorks Inc. All rights reserved www.thoughtworks-studios.com Introduction Continuous
Chapter 2 WHY THE WATERFALL MODEL DOESN T WORK M oving an enterprise to agile methods is a serious undertaking because most assumptions about method, organization, best practices, and even company culture
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...
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
Taking the first step to agile digital services Digital Delivered. Now for Tomorrow. 0207 602 6000 email@example.com @CACI_Cloud 2 1. Background & Summary The Government s Digital by Default agenda has
SATORI CONSULTING LEAN AGILE POCKET GUIDE Software Product Development Methodology Reference Guide PURPOSE This pocket guide serves as a reference to a family of lean agile software development methodologies
Agile Project Management Jim Highsmith Chapter 5 An Agile Project Management Model We improve effectiveness and reliability through situationally specific strategies, processes, and practices. One of the
Testing in Scrum Projects Kalevi Evans Logica 2008. All rights reserved About Me Logica Suomi Oy (formerly WM-Data) Over 6 years experience Experience working in projects that apply the following software
Non-Technical Issues in Software Development David E. Kieras! University of Michigan 1 Introduction Question: Why isn't software of higher quality?! More useful, more usable, more reliable?! Many large
Versions 2.0 Version Date Remarks 1.0 12/4/2012 Initial version 2.0 3/8/2008 REVISION HISTORY Updated knowledge areas Added questions examples Updated suggested readings section Page 2 of 15 Version 2.0
TEN TIPS FOR ENTERPRISE AGILE REQUIREMENTS Ten Tips for Enterprise Agile Requirements Organizations are finding that they need better ways to develop the applications that are critical to the enterprise.
LECTURE 1. SYSTEMS DEVELOPMENT 1.1 INFORMATION SYSTEMS System A system is an interrelated set of business procedures used within one business unit working together for a purpose A system has nine characteristics
International Journal of Research in Information Technology (IJRIT) www.ijrit.com ISSN 2001-5569 A Comparison between Five Models of Software Engineering Surbhi Gupta, Vikrant Dewan CSE, Dronacharya College
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
AGILE METHODOLOGY IN SOFTWARE DEVELOPMENT Shivangi Shandilya, Surekha Sangwan, Ritu Yadav Dept. of Computer Science Engineering Dronacharya College Of Engineering, Gurgaon Abstract- Looking at the software
Adapting Agile Software Development to Regulated Industry Paul Buckley Section 706 Section Event June 16, 2015 Agenda FDA s expectations for Software Development What is Agile development? Aligning Agile
The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has
The Journal of Applied Science Vol. 11 No. Vol. 2:45-50 11 No. 2  ISSN 1513-7805 Printed in Thailand Review Article Software Development Process Selection Approaches Phongphan Danphitsanuphan Department
Software Development Life Cycle Models - Process Models Week 2, Session 1 PROCESS MODELS Many life cycle models have been proposed } Traditional Models (plan-driven) } Classical waterfall model } Iterative
Best-Practice Software Engineering: Software Processes to Support Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems Dietmar.Winkler@qse.ifs.tuwien.ac.at
Agile Software Development Mohsen Afsharchi I. Agile Software Development Agile software development is a group of software development methods based on iterative and incremental development, where requirements
Driving Quality Improvement and Reducing Technical Debt with the Definition of Done Noopur Davis Principal, Davis Systems Pittsburgh, PA NDavis@DavisSys.com Abstract This paper describes our experiences
Master thesis in Applied Information Technology REPORT NO. 2008:014 ISSN: 1651-4769 Department of Applied Information Technology or Department of Computer Science Bottlenecks in Agile Software Development
Benefits of Test Automation for Agile Testing Manu GV 1, Namratha M 2, Pradeep 3 1 Technical Lead-Testing Calsoft Labs, Bangalore, India 2 Assistant Professor, BMSCE, Bangalore, India 3 Software Engineer,
Applied Agile Practices for Large-scale Organizations COMPLIANCE AND EFFICIENCY WITH STAGES AT THE STAGES INSIGHT Peter Pedross - CEO, PEDCO Page 1 Scaled Agility is for nuts OR FOR THE NOT SERIOUS COMPANIES,
Phios Corporation White Paper The Phios Whole Product Solution Methodology Norm Kashdan Phios Chief Technology Officer 2010 Phios Corporation Page 1 1 Introduction The senior staff at Phios has several
What CMMI Cannot Give You: Good Software Ivar Jacobson firstname.lastname@example.org email@example.com Objective To understand what CMM/CMMI is and what it is not To demonstrate how the unified process helps you
Agile Development: Demystified by Scott Warner Sprint, Agile, Scrum - words we normally associate with sports. Agile Methodology is 1 very much [like ] a sport with a highly-structured, rules-based engagement
E Learning Volume 5 Number 1 2008 www.wwwords.co.uk/elea Agile Software Development SOLY MATHEW BIJU University of Wollongong in Dubai, United Arab Emirates ABSTRACT Many software development firms are
Implementing Models and Standards for Software Development Benefits and Risks Tsvetelina Kovacheva, Quality Manager Musala Soft June 19, 2007 Agenda Difference between Model and Standard Software Development
Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation
Requirements Analysis and Emergent Design in Agile Software Development Practices Bruno Rossi Department of Computer Systems and Communications, Lasaris (Lab of Software Architectures and Information Systems)
Success Factors of Agile Software Development Subhas C. Misra, Vinod Kumar, and Uma Kumar Carleton University, Ottawa, Canada Abstract Agile software development methodologies have recently gained widespread
The role of the Business Analyst This document is intended as a guide only. Readers are advised that before acting on any matter arising from this document, they should consult FINNZ. 2013 FINNZ Limited.
INTERNATIONAL JOURNAL OF COMPUTER SCIENCE AND MOBILE APPLICATIONS - IJCSMA Agile Unified Process Charles Edeki Ph.D, American Intercontinental University, Department of Information Technology, 160 Parkside
Continuous User Experience Development Kati Kuusinen Tampere University of Technology Tampere, Finland Korkeakoulunkatu 1, FI-33101 Tampere firstname.lastname@example.org Abstract. Continuous approaches for software