software quality and agile sw development
Download
Skip this Video
Download Presentation
Software Quality and Agile SW Development

Loading in 2 Seconds...

play fullscreen
1 / 30

Software Quality and Agile SW Development - PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on

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

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 'Software Quality and Agile SW Development' - libitha


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

Software Quality and Agile SW Development

Johan Lindvall

TY 22.4.2005

content
Content
  • Backround and problems
  • IID
  • Scrum
  • XP
  • Quality
backround and problems
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
IID
  • Interative and incremental development
  • Agile methods are a subset of iterative and evolutionary methods
  • The key practices:

iterative development

risk-driven and client-driven

timeboxing

evolutionary development

evolutionary requirements

adaptive planning

iterative development
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
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
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
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
Timeboxing
  • 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
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
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
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
Delivery
  • 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
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
  • http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365
the agile manifesto
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
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
Scrum
  • 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
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
Development:
  • 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

Release:

  • operational deployment
  • or each release begins with staging
slide20
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
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
XP
  • 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
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
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
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
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
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
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
Quality
  • 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
References
  • 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
  • http://www.digitoday.fi/showPage.php?page_id=9&news_id=28365
ad