Cosc 4406 software engineering
Download
1 / 37

COSC 4406 Software Engineering - PowerPoint PPT Presentation


  • 167 Views
  • Uploaded on

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, [email protected] , http://www.nipissingu.ca/faculty/haibinz. Lecture 2 Process Models and Agile Development.

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

PowerPoint Slideshow about 'COSC 4406 Software Engineering' - chacha


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, [email protected], http://www.nipissingu.ca/faculty/haibinz


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

http://www.stsc.hill.af.mil/crosstalk/1995/01/Comparis.asp


The incremental model l.jpg
The Incremental Model

Communication

Planning

Modeling (analysis, design)

Construction

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

plan

communication

Modeling

Quick design

Deployment

delivery &

feedback

Construction

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)

inception

elaboration

Introduce agile features into

The activities of the waterfall model.

Iterative, incremental.

inception




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



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



Dynamic systems development method l.jpg
Dynamic Systems Development Method

  • Promoted by the DSDM Consortium (www.dsdm.org)

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



Scrum l.jpg
Scrum

  • 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



Crystal l.jpg
Crystal

  • 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



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
Summary

  • 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


ad