Presentation is loading. Please wait.

Presentation is loading. Please wait.

Iterative Development Royce, “Successful Software Management Style: Steering and Balance”, IEEE Software sep/oct 05 1 541Sp8Jan22iterdev2.

Similar presentations


Presentation on theme: "Iterative Development Royce, “Successful Software Management Style: Steering and Balance”, IEEE Software sep/oct 05 1 541Sp8Jan22iterdev2."— Presentation transcript:

1 Iterative Development Royce, “Successful Software Management Style: Steering and Balance”, IEEE Software sep/oct 05 1 541Sp8Jan22iterdev2

2 Key Ideas and/or Questions 2 541Sp8Jan22iterdev2

3 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).” 3 541Sp8Jan22iterdev2

4 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. 4 541Sp8Jan22iterdev2

5 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. 5 541Sp8Jan22iterdev2

6 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. 6 541Sp8Jan22iterdev2

7 Evaluation of these ideas 7 541Sp8Jan22iterdev2

8 What do we apply to 541 project? 8 541Sp8Jan22iterdev2

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

10 Key Ideas and/or Questions 10 541Sp8Jan22iterdev2

11 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). 11 541Sp8Jan22iterdev2

12 Fig 3 – four dimensions 12 541Sp8Jan22iterdev2

13 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. 13 541Sp8Jan22iterdev2

14 Excessive rework 14 541Sp8Jan22iterdev2

15 Insufficient Rework 15 541Sp8Jan22iterdev2

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

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

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

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

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

21 Thursday, Jan 24 u 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 21 541Sp8Jan22iterdev2


Download ppt "Iterative Development Royce, “Successful Software Management Style: Steering and Balance”, IEEE Software sep/oct 05 1 541Sp8Jan22iterdev2."

Similar presentations


Ads by Google