1' Make sure the SDD reflects latest version of detailed design, as settled on after inspections'

1
Bring the ProjectUp-to-Date After Completing
Detailed Design

• 1. Make sure the SDD reflects latest version of
  detailed design, as settled on after inspections.
• 2. Give complete detail to the schedule (SPMP).
• 3. Allocate precise tasks to team members
  (SPMP).
• 4. Improve project cost time estimates (see
  below).
• 5. Update the SCMP to reflect the new parts.
• 6. Review process by which the detailed design
  was created, determine improvements. Include
  ...
• time taken broken down to include
• preparation of the designs
• inspection
• change
• defect summary
• number remaining open, found at detailed design,
  closed at detailed design
• where injected include previous phases
  detailed design stages

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
2
Estimate Size Time from Detailed Designs
One way to ...

• 1. Start with the list of methods
• ensure completeness, otherwise underestimate will
  result
• 2. Estimate the lines of code (LOC) for each
• classify as very small, small, medium, large,
  very large
• normally in 7 / 24 / 38 / 24 / 7
  proportions
• use personal data to covert to LOC
• otherwise use Humphrys table below
• 3. Sum the LOC
• 4. Covert LOC to person-hours
• use personal conversion factor if possible
• otherwise use published factor
• 5. Ensure that your estimates of method sizes
  and time will be compared and saved at project
  end.

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
3
Lines of Code
4
Normal Distribution of Medium, Small etc.
Approximate percentage of methods classified
with this description
M
S
L
38
24
24
7
7
VS
VL
0
1
-1
2
-2
Standard deviations from the mean
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5
Inspect Detailed Designs 1 of 2
One way to ...

• 1. Prepare to record metrics during the design
  process.
• Include (1.1) time taken (1.2) type of defect
  (1.3) severity
• 2. Ensure each architecture module is expanded.
• 3. Ensure each detail is part of the
  architecture.
• if a detail does not belong to any such module,
  the architecture may have to be revised
• 4. Ensure the design fulfills its required
  functions
• 5. Ensure that design is complete (classes
  methods)
• 6. Ensure that the design is testable.

See chapter 1 for inspection procedures.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
Inspect Detailed Designs 2 of 2

• 7. Check detailed design for --
• simplicity
• a design that few can understand (after a
  legitimate effort!) is expensive to maintain, and
  can result in defects
• generality
• enables design of similar applications?
• expandability
• enables enhancements?
• efficiency
• speed, storage
• portability
• 8. Ensure all details are provided
• only code itself is excluded as a detail
• the detail work must be done eventually, and this
  is the best time to do it dont postpose

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
Table 6.2 IEEE 1044.1 Severity classification
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
8
Types of Defects (1) (IEEE)

• PS Logic problem
  (forgotten cases or steps duplicate logic
  extreme conditions neglected unnecessary
  functions misinterpretation missing condition
  test checking wrong variable iterating loop
  incorrectly etc.)
• PS Computational problem (Equation
  insufficient or incorrect precision loss sign
  convention fault)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
Types of Defects (3)

• XDOC, PS Data problem (sensor data incorrect or
  missing operator data incorrect or missing
  embedded data in tables incorrect or missing
  external data incorrect or missing output data
  incorrect or missing input data incorrect or
  missing)
• XDOC, PS Documentation problem (ambiguous
  statement etc.)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
Types of Defects (4)

• XDOC, PS Document quality problem (Applicable
  standards not met etc.)
• XDOC, PS Enhancement (change in program
  requirements etc.)
• XDOC, PS Failure caused by a previous fix

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
Types of Defects (5)

• Performance problem
• XDOC, PS Interoperability problem (not
  compatible with other software or component)
• XDOC, PS Standards conformance problem
• XDOC, PS Other (none of the above)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
12
Summary of Detailed Design

• Should be sufficient to code from
• Try standard design patterns
• Define selected algorithms
• flowcharts
• pseudocode
• Apply select tools
• e,g., Javadoc

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
13
Framdrift 1

• Enkel metode alle arbeidspakker på nederste
  nivå gies en av tre verdier
• Ikke påbegynt A 0.0
• Påbegynt men ikke ferdig A 0.5
• Ferdig A 1.0
• Ferdiggrad SAi / N

14
Framdrift 2

• For at den enkle metoden skal fungere må vi ha
• Arbeidspakkene som er omtrent like store målt i
  antall timeverk.
• Mer enn 10 15 arbeidspakker.

15
Framdrift - 3

• Vi får et mer riktig, og derfor også mer nyttig,
  resultat ved å bruke verdimetoden.
• Hver arbeidspakke blir estimert. Dette er verdien
  til arbeidspakka.
• Når ei arbeidspakke er ferdig, har vi produsert
  en verdi lik den estimerte verdien til pakka.
• Vi kan nå sammenlikne to beløp
• Produsert verdi
• Forbrukte ressurser

16
Framdrift - 4

• Flere måter å sette verdi på
• All verdien tilordnes når arbeidspakka er ferdig
• Halvparten av verdien tilordnes når vi begynner,
  resten når arbeidspakka er ferdig.
• Vi kan definere milepæler der vi er X ferdig
  med arbeidspakka

17
Framdriftsplott

• For å få oversikt over framdrift plotter vi tre
  serier i samme plott
• Planlagt ressursforbruk og produsert verdi fra
  prosjektplanen.
• Virkelig ressursforbruk fra statusrapportene.
• Produsert verdi fra statusrapportene

18
Planlagte kostnader og verdi
Ressurser Verdi
Planlagt produsert verdi
Tid
19
Virkelige kostnader og verdi - 1
Ressurser Verdi
Planlagt produsert verdi
Konsumerte ressurser
Produsert verdi
Tid
20
Virkelige kostnader og verdi- 2
Ressurser Verdi
Planlagt produsert verdi
Konsumerte ressurser
Planavvik
Overforbruk
Produktivitetsavvik
Produsert verdi
Tid
Forsinkelse
21
Replanlegging - 1

• Når overforbruk eller forsinkelse blir store må
  vi gjøre to ting
• Se etter årsaker hvorfor skjer det? Eksempel på
  årsaker er
• Ny teknologi
• Mye endringer i kundekrav
• Replanlegge viktig for å ha en plan som
  prosjektdeltakerne tror på. utdaterte planer gjør
  at deltakerne mister all interesse for å følge
  planer og fører til at alle kjører sitt eget
  løp.

22
Replanlegging - 2

• Strategier for å replanlegge
• Får utsatt sluttidspunktet. Dette er det mest
  effektive.
• Kutt funksjonalitet, i det minste i den første
  leveransen. Få kunden til å prioritere. Hva
  trenger de nå og hva kan vente til senere.
• Let etter aktiviteter som ikke bidrar direkte til
  leveransen.

23
Triage in Project Management

• Among top items in importance?
• if so, place it in do at once category
• otherwise Could we ignore without substantially
  affecting project?
• if so, place it in last to do category
• otherwise (do not spend decision time on this)
• place in middle category

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
24
Summary

• Project management silver bullet?
• People aspects co-equal technical
• Specify SPMP
• Define and retire risks
• Estimate costs with several methods
• expect to revisit and refine
• use ranges at this stage
• Schedule project with appropriate detail
• Maintain a balance among cost, schedule, quality
  and functionality

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.