1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.

Slides:



Advertisements
Similar presentations
Agile Development : an introduction
Advertisements

Chapter 3 Process Models
1 Prescriptive Process Models. 2 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process.
April 30, April 30, 2015April 30, 2015April 30, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University,
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.1.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Coming up: The Manifesto for Agile Software Development 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 3 Agile Development Software Engineering:
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 3 CS435: Introduction to Software Engineering Dr. M. Zhu
Agile Process: Overview n Agile software engineering represents a reasonable compromise to conventional software engineering for certain classes of software.
Software Engineering Lecture No:12. Lecture # 7
An Agile View of Process
SEC 308 Yazılım Mühendisliği Software Process Models
Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2, 3, &4 Process copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.1.
Developed by Reneta Barneva, SUNY Fredonia Agile Development.
Chapter 4 Agile Development
Chapter 5 Agile Development Chapter 5 Agile Development Moonzoo Kim KAIST 1.
Chapter 4 An Agile View of Process
Chapter 4 Agile Development 1. The Manifesto for Agile Software Development 2 “We are uncovering better ways of developing software by doing it and helping.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 5 애자일 개발 Agile Development
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Coming up: The Manifesto for Agile Software Development 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 3 Agile Development Software Engineering:
Software Engineering Saeed Akhtar The University of Lahore Lecture 5 Originally shared for: mashhoood.webs.com.
1 The Manifesto for Agile Software Development “We are uncovering better ways of developing software by doing it and helping others do it. Through this.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 4 Agile Development Discussion of Agile Development and Agile Process.
Chapter 3 Agile Development
1 Chapter 3: Lecture 3 Agile Development Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright.
3.1 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering If prescriptive process models strive for structure.
Software Engineering (CSI 321) An Agile View of Process 1.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.1.
1 Agile Development. The Manifesto for Agile Software Development 2 “We are uncovering better ways of developing software by doing it and helping others.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
CS 4500: Software Development Software Process. Materials Sommmerville Chapters 1, 2 and 3 Software Cycle and Models:
TIK 302 Rekayasa Perangkat Lunak Agile Proses. Agile View of Process Represents a reasonable compromise between conventional software engineering for.
1 The economies of ALL developed nations are dependent on software The economies of ALL developed nations are dependent on software More and more systems.
Chapter 5 Agile Development Moonzoo Kim KAIST
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Chapter 4 & Chapter 5 Important Concepts
Chapter 3 An Agile view of process.
Software & Software Engineering Pertemuan-4 Dosen :Kundang K Juman
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Agile Development.
Software Engineering: A Practitioner’s Approach, 7/e Chapter 3 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Chapter 5 Agile Development
Software Engineering (CSI 321)
Agile Software Development
Chapter 3 Agile Development
Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Chapter 3 Agile Development
Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Agile Process: Overview
Process Models Coming up: Prescriptive Models.
Chapter 3 Agile Development
Chapter 3 Agile Development
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 4 Agile Development copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University.
The Manifesto for Agile Software Development
Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Chapter 3 Agile Development
Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Advanced Software Engineering Ch. 2 – SE as Engineering Science
Presentation transcript:

1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada,

2 Lecture 2 Process Models and Agile Development

3 Prescriptive Models They define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineering high-quality software. They are not perfect, but they do provide a useful roadmap for software engineering work. They define a distinct set of activities, actions, tasks, milestones, and work products that are required to engineering high-quality software. They are not perfect, but they do provide a useful roadmap for software engineering work.

4 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

5 The Waterfall Model

6 The Incremental Model Communication Planning Modeling (analysis, design) Construction Deployment (deliver, feedback)

7 The RAD Model It is an incremental model that emphasizes a short development cycle by using component-based approach.

8 Evolutionary Models: Prototyping communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

9 Strengths and Weaknesses of Prototyping Strengths of Prototyping Strengths of Prototyping Early functionality. Early functionality. Provides a process to perfect the requirements definition. Provides a process to perfect the requirements definition. Provides risk control. Provides risk control. Documentation focuses on the end product not the evolution of the product. Documentation focuses on the end product not the evolution of the product. Provides a formal specification embodied in an operating replica. Provides a formal specification embodied in an operating replica. Weaknesses of Prototyping Weaknesses of Prototyping Less applicable to existing systems than to new, original development. Less applicable to existing systems than to new, original development. Bad reputation among conservatives as a "quick and dirty" method. Bad reputation among conservatives as a "quick and dirty" method. Suffers from bad documentation. Suffers from bad documentation. Sometimes produces a system with poor performance. Sometimes produces a system with poor performance. Tendency for difficult problems to be pushed to the future so that the initial promise of the prototype is not met by subsequent products. Tendency for difficult problems to be pushed to the future so that the initial promise of the prototype is not met by subsequent products.

10 Comparing the incremental model and the prototyping model Same: Same: They are iterative They are iterative Difference: Difference: The former focuses on the delivery of an operational product with each increment. The former focuses on the delivery of an operational product with each increment. The latter focuses on a representation of those aspects of the software that will be visible to the customer/end-user. The latter focuses on a representation of those aspects of the software that will be visible to the customer/end-user.

11 Evolutionary Models: The Spiral It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.

12 STRENGTHS Water- fall Increme ntal Spiral Allows for work force specializationXXX Orderliness appeals to managementXXX Can be reported aboutXXX Facilitates allocation of resourcesXXX Early functionalityXX Does not require a complete set of requirements at the onsetX*X Resources can be held constantX Control costs and risk through prototypingX * The incremental model may be used with a complete set of requirements or with less defined general objectives.

13 WEAKNESSES Water fall Incre mental Spiral Requires a complete set of requirements at the onset X Enforcement of non-implementation attitude hampers analyst/designer communications X Beginning with less defined general objectives may be uncomfortable for management XX Requires clean interfaces between modules X Incompatibility with a formal review and audit procedure XX Tendency for difficult problems to be pushed to the future so that the initial promise of the first increment is not met by subsequent products XX

14 Evolutionary Models: Concurrent For each framework activity of the waterfall model, there is a state transition diagram. Each activity follows the diagram. Therefore, all these activities are in concurrency.

15 Still Other Process Models Component based development—the process to apply when reuse is a development objective Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

16 inception The Unified Process (UP) inception elaboration Introduce agile features into The activities of the waterfall model. Iterative, incremental.

17 UP Phases

18 UP Work Products

19 Agile Software Engineering It combines a philosophy and a set of development guidelines. It combines a philosophy and a set of development guidelines. The philosophy encourages The philosophy encourages customer satisfaction and early incremental delivery of software; customer satisfaction and early incremental delivery of software; small, highly motivated project teams; small, highly motivated project teams; informal methods; informal methods; minimal software engineering products; and minimal software engineering products; and overall development simplicity. overall development simplicity. The development guidelines stress delivery over analysis and design and active and continuous communication between developers and customers. The development guidelines stress delivery over analysis and design and active and continuous communication between developers and customers.

20 The Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions / processes and toolsIndividuals and interactions / processes and tools Working software / comprehensive documentationWorking software / comprehensive documentation Customer collaboration / contract negotiationCustomer collaboration / contract negotiation Responding to change / following a planResponding to change / following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck et al

21 Human Factors Competence Competence Common Focus Common Focus Collaboration Collaboration Decision-making ability Decision-making ability Fuzzy problem-solving ability Fuzzy problem-solving ability Mutual trust and respect Mutual trust and respect Self-organization Self-organization

22 What is “Agility”? Effective (rapid and adaptive) response to change Effective (rapid and adaptive) response to change Effective communication among all stakeholders Effective communication among all stakeholders Drawing the customer onto the team Drawing the customer onto the team Organizing a team so that it is in control of the work performed Organizing a team so that it is in control of the work performed Yielding … Rapid, incremental delivery of software Rapid, incremental delivery of software

23 An Agile Process Is driven by customer descriptions of what is required (scenarios) Is driven by customer descriptions of what is required (scenarios) Recognizes that plans are short-lived Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Develops software iteratively with a heavy emphasis on construction activities Delivers multiple ‘software increments’ Delivers multiple ‘software increments’ Adapts as changes occur Adapts as changes occur Assumptions: 1.It is difficult to predict in advance the requirements; 2.Phases are interleaved. 3.All the phases are not predictable.

24 Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck The most widely used agile process, originally proposed by Kent Beck XP Planning XP Planning Begins with the creation of “user stories” Begins with the creation of “user stories” Agile team assesses each story and assigns a cost Agile team assesses each story and assigns a cost Stories are grouped for a deliverable increment Stories are grouped for a deliverable increment A commitment is made on delivery date A commitment is made on delivery date After the first increment “project velocity” is used to help define subsequent delivery dates for other increments After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

25 Extreme Programming (XP) XP Design XP Design Follows the KIS principle Follows the KIS principle Encourage the use of CRC cards (see Chapter 8) Encourage the use of CRC cards (see Chapter 8) For difficult design problems, suggests the creation of “spike solutions”—a design prototype For difficult design problems, suggests the creation of “spike solutions”—a design prototype Encourages “refactoring”—an iterative refinement of the internal program design Encourages “refactoring”—an iterative refinement of the internal program design XP Coding XP Coding Recommends the construction of a unit test for a store before coding commences Recommends the construction of a unit test for a store before coding commences Encourages “pair programming” Encourages “pair programming” XP Testing XP Testing All unit tests are executed daily All unit tests are executed daily “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality

26 Extreme Programming (XP)

27 Adaptive Software Development Originally proposed by Jim Highsmith Originally proposed by Jim Highsmith ASD — distinguishing features: Self-oraganisation ASD — distinguishing features: Self-oraganisation Mission-driven planning Mission-driven planning Component-based focus Component-based focus Uses “time-boxing” (See Chapter 24) Uses “time-boxing” (See Chapter 24) Explicit consideration of risks Explicit consideration of risks Emphasizes collaboration for requirements gathering Emphasizes collaboration for requirements gathering Emphasizes “learning” throughout the process Emphasizes “learning” throughout the process

28 Adaptive Software Development

29 Dynamic Systems Development Method Promoted by the DSDM Consortium ( Promoted by the DSDM Consortium ( Provides a framework for building systems that meet tight time constraints through the use of incremental prototyping in a controlled project environment. Provides a framework for building systems that meet tight time constraints through the use of incremental prototyping in a controlled project environment. DSDM—distinguishing features DSDM—distinguishing features Similar in most respects to XP and/or ASD Similar in most respects to XP and/or ASD Nine guiding principles Nine guiding principles Active user involvement is imperative. Active user involvement is imperative. DSDM teams must be empowered to make decisions. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible. All changes during development are reversible. Requirements are baselined at a high level Requirements are baselined at a high level Testing is integrated throughout the life-cycle. Testing is integrated throughout the life-cycle.

30 Dynamic Systems Development Method

31 Scrum Originally proposed by Schwaber and Beedle Originally proposed by Schwaber and Beedle Scrum—distinguishing features Scrum—distinguishing features Development work is partitioned into “packets” Development work is partitioned into “packets” Testing and documentation are on-going as the product is constructed Testing and documentation are on-going as the product is constructed Work occurs in “sprints” and is derived from a “backlog” of existing requirements Work occurs in “sprints” and is derived from a “backlog” of existing requirements Meetings are very short and sometimes conducted without chairs Meetings are very short and sometimes conducted without chairs “demos” are delivered to the customer with the time-box allocated “demos” are delivered to the customer with the time-box allocated

32Scrum

33 Crystal Proposed by Cockburn and Highsmith Proposed by Cockburn and Highsmith Crystal—distinguishing features Crystal—distinguishing features Actually a family of process models that allow “maneuverability” based on problem characteristics Actually a family of process models that allow “maneuverability” based on problem characteristics Face-to-face communication is emphasized Face-to-face communication is emphasized Suggests the use of “reflection workshops” to review the work habits of the team Suggests the use of “reflection workshops” to review the work habits of the team

34 Feature Driven Development Originally proposed by Peter Coad et al Originally proposed by Peter Coad et al FDD—distinguishing features FDD—distinguishing features Emphasis is on defining “features” Emphasis is on defining “features” a feature “is a client-valued function that can be implemented in two weeks or less.” a feature “is a client-valued function that can be implemented in two weeks or less.” Uses a feature template Uses a feature template the a(n) the a(n) A features list is created and “plan by feature” is conducted A features list is created and “plan by feature” is conducted Design and construction merge in FDD Design and construction merge in FDD

35 Feature Driven Development

36 Agile Modeling Originally proposed by Scott Ambler Originally proposed by Scott Ambler Suggests a set of agile modeling principles Suggests a set of agile modeling principles Model with a purpose Model with a purpose Use multiple models Use multiple models Travel light Travel light Content is more important than representation Content is more important than representation Know the models and the tools you use to create them Know the models and the tools you use to create them Adapt locally Adapt locally

37 Summary Prescriptive Models Prescriptive Models The Waterfall Model The Waterfall Model The Incremental Model The Incremental Model The RAD Model The RAD Model Evolutionary Models Evolutionary Models Prototyping Prototyping The Spiral Model The Spiral Model The Current Development Model The Current Development Model UP Phase UP Phase Agile Development Agile Development Agile processes Agile processes Agile process models Agile process models XP, ASD, DSDM, Scum, Crystal, FDD, AM XP, ASD, DSDM, Scum, Crystal, FDD, AM