COSC 4406 Software Engineering - PowerPoint PPT Presentation

Cosc 4406 software engineering
1 / 37

  • Uploaded on
  • Presentation posted in: General

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, , Lecture 2 Process Models and Agile Development.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentationdownload

COSC 4406 Software Engineering

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Cosc 4406 software engineering l.jpg

COSC 4406Software Engineering

Haibin Zhu, Ph.D.

Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada,,

Lecture 2 process models and agile development l.jpg

Lecture 2Process Models and Agile Development

Prescriptive models l.jpg

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.

Prescriptive models4 l.jpg

Prescriptive Models

  • 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?

  • 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?

The waterfall model l.jpg

The Waterfall Model

The incremental model l.jpg

The Incremental Model



Modeling (analysis, design)


Deployment (deliver, feedback)

The rad model l.jpg

The RAD Model

It is an incremental model that emphasizes a short development cycle

by using component-based approach.

Evolutionary models prototyping l.jpg

Evolutionary Models: Prototyping





Quick design


delivery &



of prototype

Strengths and weaknesses of prototyping l.jpg

Strengths and Weaknesses of Prototyping

  • Strengths of Prototyping

    • Early functionality.

    • Provides a process to perfect the requirements definition.

    • Provides risk control.

    • Documentation focuses on the end product not the evolution of the product.

    • Provides a formal specification embodied in an operating replica.

  • Weaknesses of Prototyping

    • Less applicable to existing systems than to new, original development.

    • Bad reputation among conservatives as a "quick and dirty" method.

    • Suffers from bad documentation.

    • 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.

Comparing the incremental model and the prototyping model l.jpg

Comparing the incremental model and the prototyping model

  • Same:

    • They are iterative

  • Difference:

    • 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.

Evolutionary models the spiral l.jpg

Evolutionary Models: The Spiral

It couples the iterative nature of prototyping with the controlled and

systematic aspects of the waterfall model.

Evolutionary models concurrent l.jpg

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.

Still other process models l.jpg

Still Other Process Models

  • Component based development—the process to apply when reuse is a development objective

  • Formal methods—emphasizes the mathematical specification of requirements

  • 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)

The unified process up l.jpg

The Unified Process (UP)



Introduce agile features into

The activities of the waterfall model.

Iterative, incremental.


Up phases l.jpg

UP Phases

Up work products l.jpg

UP Work Products

Agile software engineering l.jpg

Agile Software Engineering

  • It combines a philosophy and a set of development guidelines.

  • The philosophy encourages

    • customer satisfaction and early incremental delivery of software;

    • small, highly motivated project teams;

    • informal methods;

    • minimal software engineering products; and

    • overall development simplicity.

  • The development guidelines stress delivery over analysis and design and active and continuous communication between developers and customers.

The manifesto for agile software development l.jpg

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 tools

    • Working software / comprehensive documentation

    • Customer collaboration / contract negotiation

    • Responding 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

Human factors l.jpg

Human Factors

  • Competence

  • Common Focus

  • Collaboration

  • Decision-making ability

  • Fuzzy problem-solving ability

  • Mutual trust and respect

  • Self-organization

What is agility l.jpg

What is “Agility”?

  • Effective (rapid and adaptive) response to change

  • Effective communication among all stakeholders

  • Drawing the customer onto the team

  • Organizing a team so that it is in control of the work performed

    Yielding …

  • Rapid, incremental delivery of software

An agile process l.jpg

An Agile Process

  • Is driven by customer descriptions of what is required (scenarios)

  • Recognizes that plans are short-lived

  • Develops software iteratively with a heavy emphasis on construction activities

  • Delivers multiple ‘software increments’

  • Adapts as changes occur

  • Assumptions:

  • It is difficult to predict in advance the requirements;

  • Phases are interleaved.

  • All the phases are not predictable.

Extreme programming xp l.jpg

Extreme Programming (XP)

  • The most widely used agile process, originally proposed by Kent Beck

  • XP Planning

    • Begins with the creation of “user stories”

    • Agile team assesses each story and assigns a cost

    • Stories are grouped for a deliverable increment

    • A commitment is made on delivery date

    • After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

Extreme programming xp25 l.jpg

Extreme Programming (XP)

  • XP Design

    • Follows the KIS principle

    • Encourage the use of CRC cards (see Chapter 8)

    • For difficult design problems, suggests the creation of “spike solutions”—a design prototype

    • Encourages “refactoring”—an iterative refinement of the internal program design

  • XP Coding

    • Recommends the construction of a unit test for a store before coding commences

    • Encourages “pair programming”

  • XP Testing

    • All unit tests are executed daily

    • “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality

Extreme programming xp26 l.jpg

Extreme Programming (XP)

Adaptive software development l.jpg

Adaptive Software Development

  • Originally proposed by Jim Highsmith

  • ASD — distinguishing features: Self-oraganisation

    • Mission-driven planning

    • Component-based focus

    • Uses “time-boxing” (See Chapter 24)

    • Explicit consideration of risks

    • Emphasizes collaboration for requirements gathering

    • Emphasizes “learning” throughout the process

Adaptive software development28 l.jpg

Adaptive Software Development

Dynamic systems development method l.jpg

Dynamic Systems Development Method

  • 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.

  • DSDM—distinguishing features

    • Similar in most respects to XP and/or ASD

    • Nine guiding principles

      • Active user involvement is imperative.

      • DSDM teams must be empowered to make decisions.

      • The focus is on frequent delivery of products.

      • 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.

      • All changes during development are reversible.

      • Requirements are baselined at a high level

      • Testing is integrated throughout the life-cycle.

Dynamic systems development method30 l.jpg

Dynamic Systems Development Method

Scrum l.jpg


  • Originally proposed by Schwaber and Beedle

  • Scrum—distinguishing features

    • Development work is partitioned into “packets”

    • Testing and documentation are on-going as the product is constructed

    • Work occurs in “sprints” and is derived from a “backlog” of existing requirements

    • Meetings are very short and sometimes conducted without chairs

    • “demos” are delivered to the customer with the time-box allocated

Scrum32 l.jpg


Crystal l.jpg


  • Proposed by Cockburn and Highsmith

  • Crystal—distinguishing features

    • Actually a family of process models that allow “maneuverability” based on problem characteristics

    • Face-to-face communication is emphasized

    • Suggests the use of “reflection workshops” to review the work habits of the team

Feature driven development l.jpg

Feature Driven Development

  • Originally proposed by Peter Coad et al

  • FDD—distinguishing features

    • Emphasis is on defining “features”

      • afeature “is a client-valued function that can be implemented in two weeks or less.”

    • Uses a feature template

      • <action> the <result> <by | for | of | to> a(n) <object>

    • A features list is created and “plan by feature” is conducted

    • Design and construction merge in FDD

Feature driven development35 l.jpg

Feature Driven Development

Agile modeling l.jpg

Agile Modeling

  • Originally proposed by Scott Ambler

  • Suggests a set of agile modeling principles

    • Model with a purpose

    • Use multiple models

    • Travel light

    • Content is more important than representation

    • Know the models and the tools you use to create them

    • Adapt locally

Summary l.jpg


  • Prescriptive Models

    • The Waterfall Model

    • The Incremental Model

    • The RAD Model

    • Evolutionary Models

      • Prototyping

      • The Spiral Model

      • The Current Development Model

    • UP Phase

  • Agile Development

    • Agile processes

    • Agile process models

      • XP, ASD, DSDM, Scum, Crystal, FDD, AM

  • Login