Docstoc
EXCLUSIVE OFFER FOR DOCSTOC USERS
Try the all-new QuickBooks Online for FREE.  No credit card required.

Software Process Models _1_

Document Sample
Software Process Models _1_ Powered By Docstoc
					  Iterative Development
   Royce, “Successful Software
 Management Style: Steering and
Balance”, IEEE Software sep/oct 05


         541Sp8Jan22iterdev2         1
Key Ideas and/or Questions




          541Sp8Jan22iterdev2   2
 Rationale of Iterative Development
“Traditional project management approaches in software-
intensive projects don’t encourage the steering and
adjustment needed to reconcile significant levels of
uncertainty in the
■ problem space (what the user really wants or needs),
■ solution space (what architecture and technology mix is
most appropriate), and
■ planning space (including cost and time constraints, team
composition and productivity, stakeholder communication,
and incremental result sequences).”



                      541Sp8Jan22iterdev2                     3
Measurement

  Just as the movie industry gets action on
  film, we too must get increments of software
  into executable form to make things tangible
  enough to assess progress and quality.




                 541Sp8Jan22iterdev2             4
 Results
This iterative management style is results rather
than activity-based. In the world of software, real results
are executable programs.

Everything else (requirements documents, usecase
models, design models, test cases, plans, processes,
documentation, and inspections) is secondary—simply
part of the means to the end.




                      541Sp8Jan22iterdev2                     5
Precision vs Accuracy
 A common failure pattern is developing a
 five-digits-of-precision specification when the
 stakeholders have only a one-digit-of-precision
 understanding of the problem, solution, or plan.




                  541Sp8Jan22iterdev2               6
Evaluation of these ideas




           541Sp8Jan22iterdev2   7
What do we apply to 541 project?




           541Sp8Jan22iterdev2     8
Iterative Rework: the Good, the
Bad and the Ugly
    Richard E Fairley and Mary Jane
    Willshire, IEEE Computer, Sep 05



            541Sp8Jan22iterdev2        9
Key Ideas and/or Questions




          541Sp8Jan22iterdev2   10
  Rework
Incremental build lets developers produce weekly builds of an
evolving product.

Each iteration involves a certain amount of rework to enhance and
fix existing capabilities (the good). However, excessive rework
could indicate problems in the requirements, the developers’ skills
and motivation, the development processes or technology used, or
all of the above (the bad). Exorbitant levels of rework result in truly
untenable situations (the ugly).




                       541Sp8Jan22iterdev2                          11
Fig 3 – four dimensions




          541Sp8Jan22iterdev2   12
 Amount of rework
For several years, our rule of thumb has been that total rework
(evolutionary plus both types of avoidable) is acceptable at 10 to
20 percent of the total effort for each reporting period in an
iterative development process. The reporting period typically
varies from a week to a month. Weekly analysis of rework data is
desirable in a project’s early stages. Less frequent reporting and
analysis is appropriate once rework stabilizes and remains within
the desired range.




                      541Sp8Jan22iterdev2                        13
Excessive rework




          541Sp8Jan22iterdev2   14
Insufficient Rework




          541Sp8Jan22iterdev2   15
    Our Goal: Project Plan
 The size and important features of the
  product to be produced
 The division of tasks into iterations
 Size and effort estimations of work tasks




             541Sp8Jan22iterdev2              16
Identify Subtasks
  Identify all the different subtasks necessary
   to achieve product
   – Include units if possible, e.g. number of ppt
     slides
  For each subtask, identify milestone(s) and
   completion criteria
  Establish dependencies



               541Sp8Jan22iterdev2                   17
Checkpoints, Milestones, or Inch-
pebbles
   “A  checkpoint is an objectively identifiable
    point in a project”
   e.g. not “coding is 90% complete”
   possible – “design is ready for review,
    design has been reviewed by all team
    members.”
   “a checkpoint for every five hours or so of
    work”

               541Sp8Jan22iterdev2              18
Project Plan
  establish subtasks (wbs)
  establish checkpoints (wbs)
  establish dependencies (gannt or pert)
  establish dates (gannt chart)
  assign subtasks




               541Sp8Jan22iterdev2          19
Project Plan for Iteration 1
  Must   have time in minutes for each leaf task
  No leaf task can be more than 7 days before
   successor
  Each leaf task must have completion
   criterion




              541Sp8Jan22iterdev2              20
Thursday, Jan 24
  Read   about Earned Value
   – Stellman and Greene “track the performance
     …” pp63-66
   – SOS 3.7 – work through exercise 3.6 on page
     36 – make sure you can get the same answers




              541Sp8Jan22iterdev2                  21

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:8/15/2012
language:Unknown
pages:21