COMP2110 in 2005 Software Design Lecture 16: Agile development

1
COMP2110 in 2005 Software DesignLecture 16
Agile development

• assessment scheme
• agile and classic methods of development
• an intro to DSDM
• a little bit of UP

2
Assessment scheme (summary) (1)2005
COMP2510 exam includes 20 question on
professional component.

• 1. Assignment component 2 assignments (total
  55)
• 2. Tutorial preparation and participation 5
• 3. Final examination 40
• Assignments
• 1. Minor assignment written, 15 due 6pm
  Monday 15 August (before week 5)
• topic area Requirements
• 2. Major assignment in 2 parts
• topic area reverse engineered
  requirements and draft design
• 1. (in teams) short presentation
  and written report 10
• A joint report and text of presentation due
  9am Monday 29 August (before week 7)
• Presentations by the team in their
  registered lab class session of week 7
• 2. (individual) written final
  design and critique 30
• report due 6pm Friday 21
  October (end of week 12)

3
Assessment scheme (summary) (2) 2005

• 1. Assignment component 2 assignments (total
  55)
• 2. Tutorial preparation and participation 5
• 3. Final examination 40 written, sit-down,
  open book
• Final course mark
• will be the sum of the components,minimum 40 in
  each major component (assignments, exam)
• Late penalties
• Written assignment reports will be accepted up to
  5 days (120 hours) after the due date - except
  the text of slides for the short presentation
  will not be accepted late unless you have
  specific permission.
• Each additional day past the due date will reduce
  the value of the mark awarded by a further 10
  percent(10 reduction for 1 day late, 20 for 2
  days etc.)
• Extensions only for illness (medical
  certificate), personal or family emergencies, etc.

4
classic development methods...

• the waterfall is an extreme among the classic
  methods
• even the waterfall has some feedback epicycles
• analysis -gt requirements -gt high level design -gt
  detailed design -gt implementation -gt test
• interaction with client during analysis
  eliciting requirements and acceptance test
• many structured methods proposed, using different
  analysis techniques and information models
• Structured Analysis and Design
• JSD
• ...

5
agile development methods

• respond to time pressures as most important
• interact with client a lot
• decide on functionality (requiremetns) while
  doing detailed design and implementation
• many methods
• Rapid Application Development RAD
• test-driven development
• DSDM dynamic systems development method
• XP extreme programming
• ...

6
Classic versus agile methods

• classic methods
• processes and tools
• comprehensive documentation
• contract negotiation
• following a plan

• agile methods
• individuals and interactions
• working software
• customer collaboration
• responding to change

Barry Boehm 2002, in Budgen Software Design ed 2
p. 242
7
At the limits - classic and agile methods

• classic methods
• processes and tools
• comprehensive documentation
• contract negotiation
• following a plan

• agile methods
• individuals and interactions
• working software
• customer collaboration
• responding to change

• unstructured hacking
• uncontrolled effort and cost
• low quality,
• non reusable

• Analysis paralysis
• Bureaucratic, document bound

8
Classic and agile development

• differences in emphasis both kinds of processes
  evidently produce products
• choose?
• by anticipated use
• e.g. avionics software vs games software
• time pressure vs quality pressure
• grab market position, test product in market
• by people and personalities
• organising large teams, replaceable qualityvs a
  few premium quality people

9
Incremental Design intro to DSDM and MoSCoW
Rules
from Budgen 2e p245
agree basic requirements
do partial detailed design
develop architecural design
develop prototype, test evaluate
implement and test final system
Dynamic Systems Development Method
10
DSDM 9 Principles, apply as you go

• 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 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 lifecycle
• collaborative and cooperative approach between
  all stakeholders

Budgen p248
11
DSDM MoSCoW Rules

• how to deal with requirements
• a form of Requirements Triage during
  development
• Must have
• minimal usable set of requirements for the
  product
• Could have
• can safely be left out of current deliverable
  nice to have but not essential
• Want to have
• but wont this time -waiting list for the future

12
Agile methods

• iterative process
• requirements and designs are still important
  working items
• the Unified Process is a variant
• Craig Larman Applying UML and Patterns
• using UML class diagrams and sequence diagrams as
  notations for doing design by individuals and
  teams
• design a bit, implement a bit
• then reverse engineer document most important
  parts of design that was developed in
  implementation
• use for start of next itereation design a bit
  more...