Software quality and agile sw development l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

Software Quality and Agile SW Development PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Software Quality and Agile SW Development. Johan Lindvall TY 22.4.2005. Content. Backround and problems IID Scrum XP Quality. Backround and Problems. waterfall: response to ad-hoc code-and-fix 1960’s, Winston Royce (proponent of iterative dev.) e.g. DoD standard 2167

Download Presentation

Software Quality and Agile SW Development

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

Software quality and agile sw development l.jpg

Software Quality and Agile SW Development

Johan Lindvall

TY 22.4.2005

Content l.jpg


  • Backround and problems

  • IID

  • Scrum

  • XP

  • Quality

Backround and problems l.jpg

Backround and Problems

  • waterfall: response to ad-hoc code-and-fix 1960’s, Winston Royce (proponent of iterative dev.)

  • e.g. DoD standard 2167

  • system should be clearly specified before its design and implemention

  • the clients are not sure what they want

  • details will only be revealed during development

  • as the product develop, clients change their minds

  • external forces (competitor’s product)

    -> high change rate, not predictable manufactoring

Slide4 l.jpg


  • Interative and incremental development

  • Agile methods are a subset of iterative and evolutionary methods

  • The key practices:

    iterative development

    risk-driven and client-driven


    evolutionary development

    evolutionary requirements

    adaptive planning

Iterative development l.jpg

Iterative Development

  • ID is an approach to build sw of several iterations

  • each iteration a mini-project

    • requirements analysis, design, programming, test

    • iteration release: a stable, integrated and tested internal (external) partially complete system

Slide6 l.jpg

  • iteration by iteration system grows incrementally with new features

     iterative and incremental development IID

  • at least 3 iterations

  • recommended lenght is 1-6 weeks per itr.

  • early risk mitigation and discovery

    • riskiest problems first

    • a study [Johnson2002]:

      • 45% of features were not used

      • 19% rarely

      • 16% sometimes

      • 13% often

      • 7% always

Slide7 l.jpg

  • final product better matches true client desires

     quality

  • iterative development is lower risk and better success, productivity, and defect rates than WF

  • early and regular process improvement

    • a per-iteration assessment

  • confidence and satisfaction from early, repeated success  team self-confidence  customer confidence in the team

Risk driven and client driven iterative planning l.jpg

Risk-Driven and Client-Driven Iterative Planning

  • What to do in the first/next iteration?

  • Risk-driven: the riskiest, most difficult elements for the early iterations

  • Client-driven: the choice of features comes from client, the currently highest business value

Timeboxing l.jpg


  • the practice of fixing the iteration end-date and not allow it to change

  • if short of time, reduce the scope and leave features to the next iteration

  • no adding of new tasks to iteration

Evolutionary and apadtive development l.jpg

Evolutionary and Apadtive Development

  • requirements, plan, estimates, solution evolve and are refined

  • requires feedback from users, tests, developers

  • consept:

    evolutionary ~ adaptive = iterative-timebox

Evolutionary requirements analysis l.jpg

Evolutionary Requirements Analysis

  • requirements are not always changing (Boehm 1988 25%)

  • most requirements discovery and refinement usually occours during early iterations

  • e.g. 1-2 day req. workshop/itr.

  • early top-ten high-level req. (e.g. load, usability)

  • a study (1995, 107 projects)

    • 18% of the projects completed the reqs. in 1 iteration

    • 32% in 2 iterations

    • 50% in 3 or more iterations

Evolutionary and adaptive planning l.jpg

Evolutionary and Adaptive planning

  • an initial phase of high uncertainty which drops

  • cone of uncertainty (effort, cost, shedule /time)

  • apadtive planning: no detailed schedule are created

Delivery l.jpg


  • partial software produced, not merely documents

  • incremental delivery: system into production, deliveries between 3-12 months

  • evolutionary delivery: attempt to capture feedback, promoted in agile development

Agile sw development l.jpg

Agile sw development

  • requiring feedback to guide direction, early testing, early demos

  • agility – rapid and flexible response to change

  • motto: embrace change

  • practices and principles: simplicity, lightness, communication, self-directed teams, programming over documents

  • eg. Scrum and XP

  • whiteboard (wall sketches), snapshots

  • timeboxed iterative and evolutionary development, adaptive planning, promote evolutionary delivery


The agile manifesto l.jpg

The Agile Manifesto

Individuals and interactions

over process and tools

Working software

over comprehensive documentation

Customer collaboration

over contract negotiation

Responding to change

over following the plan

The agile principles l.jpg

The Agile principles

  • early and continuous delivery of valuable sw

  • welcome changing requirements, even late

  • delivery working sw frequently

  • business people and developers daily together

  • motivated individuals

  • face-to-face conversation for information

  • working sw is the primary measure of progress

  • agile processes promote sustainable development

  • developpers, users maintain constant pace

  • attention to technical excellence and good design enhances agility

  • simplicity essentail – the art of maximizing the amount of work not done

  • the best architectures, requirements and desings emerges from self-organizing teams

  • the team regulary reflects on how to become more effective

Scrum l.jpg


  • by Takeuchi and Nonaka 1986 paper of summarizing common best practises in 10 innovatoive Japanese companies

  • timebox exactly 30 days

  • working in a common room

  • daily meeting, at the same time and place

  • self-directed teams (one team <=7, many teams)

  • external demo at the end of each iter.

Slide18 l.jpg

  • Cockburn scale C, D, E, L and 1-100-…

  • client-driven adaptive planning

  • Lifecycle: plannig, staging,development, release

  • Planning:

    • establish the vision, set expectations, funding

    • write vision, budget, initial Product Backlog

  • Staging:

    • identify more requirements, priorotize enough for first iteration

Slide19 l.jpg


  • implenent a system ready for release in series of 30 days (sprints)

  • Sprint planning: choose goals for the next iteration, how to achieve the requests. Sprint Backlog: tasks (in next 4-16h) to meet the goals

  • during iteration do not add work, uninterrupted focus

  • quality assurance occurs specially in Sprint, with less new development


  • operational deployment

  • or each release begins with staging

Slide20 l.jpg

  • Product Backlog

    a list of all product requirements,

    functionality, features, techlogy

    never finished  evolves

  • Sprint Backlog

    daily estimate of work remaining for each task

    Scrum is based on the insight that SW development is creative and unpredictible new product development, and therefore empairical rather than defined methods are needed.

Scrum values l.jpg

Scrum values

  • Commitment

    • the team commits to a defined goal and decide themselves how best to meet it

  • Focus

    • team not distracted, chickens and pics-rule, srcum master

  • Openness

    • product backlog makes visible the work and priorities

  • Respect – self-organizing

  • Courage – trust the team

Slide22 l.jpg


  • eXtreme Programming, Kent Beck 1980’s

  • truly adobted by developpers!

  • Cockburn scale C, D, E and 1-20

  • small team projects, <10 developpers

  • emphasizes collaboration, quick and early sw creation

  • the cost of change may not rise over time

Slide23 l.jpg

  • 4 values

    • communication: pairs, daily meetings, customer on-site

    • simplicity: ’Do simpliest thing that could possbly work’. Eg. avoid creating generalized components.

    • feedback: drives to quality and adaption

    • courage: simple design & tests  rapid and radical changes

Slide24 l.jpg

  • 1-4 weeks iterations

  • story cards to summarize requirements, not required detailed workproducts

  • programming in pairs (deep skill transfer)

  • common project room

  • full-time participation by requirements donor (the client, end user) for ongoing verbal explinations

  • test-driven development, code reviews, frequent integration of all code

    short iterations, early feedback  quality

  • tests written ahead!

  • timeboxed, no working overtime

12 core practices l.jpg

12 core practices

  • The planning game

    • scope, priority, composition of releases, dates of releases

    • estmates, consequences, process, detailed scheduling

  • Small releases

    • the most valuable business requirements

  • Metaphor

    • the basic elements and their relationships, naive statement

  • Simple Design

    • runs all the tests, no duplicated logic, every intention important, fewest possible classes and methods

Slide26 l.jpg

  • Testing

    • unit tests, functional tests

  • Refactoring

    • even more simpler?

  • Pair programming

    • implemention vs. strategy

  • Collective ownership

    • need to change now, not later

  • Continous Integration

    • integrated and tested after few hours - a day

  • 40 hour week

  • On-site customer

  • Coding standards

Others evo l.jpg

Others: Evo

  • 1960’s, published 1976

  • 1-2 weeks iteration

  • evolutionary delivery on each iteration

  • plans iterations by highest value-to-cost ratio

Others up l.jpg

Others: UP

  • Unified Process, 1990’s

  • iterative, not agile

  • risk-driven development in early iterations focusing on creation of the core architecture and driving down the high risks

  • 2-6 weeks iterations

Quality l.jpg


  • research show that shorter steps have lower complexity and risk, better feedback, and higher productivity and success rate

  • early defect removal, less useless work, concentration on essential features

  • each iteration tested for acceptance

    real business value for customer.

References l.jpg


  • Larman, Craig: Agile and Iterative Development, Addison-Wesley, 2004

  • Beck, Kent: Extreme programming explained: embrace change, Addison-Wesley, 2000

  • Scwaber Ken, Beedle Mike:Agile Software Development with Scrum, Prentice-Hall, 2002


  • Login