1 / 43

Διαχείριση αντικειμένου εργασιών & Καταγραφή απαιτήσεων

Διαχείριση αντικειμένου εργασιών & Καταγραφή απαιτήσεων. Βασίλης X. Γερογιάννης, PhD. Laws of project management. American Production and Inventory Control Society – Cyril Northcote Parkinson

georgebjames
Download Presentation

Διαχείριση αντικειμένου εργασιών & Καταγραφή απαιτήσεων

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Διαχείριση αντικειμένου εργασιών & Καταγραφή απαιτήσεων Βασίλης X. Γερογιάννης, PhD

  2. Laws of project management American Production and Inventory Control Society – Cyril Northcote Parkinson • No major project is ever installed on time, within budget or with the same staff that started it. Yours will not be the first • Projects progress quickly until they become 90% complete, then they remain at 90% complete forever • When things are going well, something will go wrong • When things just cannot get any worst, they will • When things appear to be going better, you have overlooked something • If project content is allowed to change freely, the rate of change will exceed the rate of progress • No system is ever completely debugged. Attempts to debug a system inevitably introduce new bugs that are even harder to find • A carelessly planned project will take three times longer to complete than expected. A carefully planned project will take only twice as long • Project teams detest progress reporting because it vividly manifests their lack of progress.

  3. The Requirements Problem

  4. Requirements Problem • What is the ultimate objective? • Quality SW • On time • Within budget • That meets users’ needs!! • Don’t lose sight of the goal!

  5. The requirements problem • The goal of software development is to develop qualitysoftware—on time and on budget—that meetscustomers real needs. • Project success depends on good requirementsmanagement. • Requirements errors are the most common type ofsystems development error and the most costly to fix. • A few key skills can significantly reduce requirementserrors and thus improve software quality.

  6. Major software development problems European Software Process Improvement Training Initiative (ESPITI) • 2 largest problems are: • Requirement specs • Managing reqs • Coding is rarely a major problem • Though it is typically the biggest cost item!

  7. Requirements Problem • Why do SW projects fail? Standish study (1994) reports that in US… • The 3 most commonly cited factors • 13% Lack of user input • 12% Incomplete reqs & specs • 12% Changing reqs & specs • All directly related to managing reqs!! • All related with communication issues!!

  8. Requirements Problem • Why do projects succeed? • 16% User involvement • 14% Executive management support • 12% Clear requirements

  9. Defect summary(Capers Jones - 1994) • Delivered Defects = Defect Potentials x (1 - Removal Efficiency) • Reqs contribute most defects to delivered SW • (Because they’re so hard to remove) • Design defects 2nd only to Reqs. defects • 56% of defects due to Reqs & Design!

  10. Example Calculate (pre-delivery) Defects Removal Efficiency?

  11. Example (pre-delivery) DRE = (250 / 300) x 100 = 83,3%

  12. Defect Removal Effectiveness • How defects are injected and removed during software development • How to measure defect removal effectiveness at the different stages of software development

  13. Defect Removal Effectiveness Background • Defect removal effectiveness is important because: • It improves the quality of the software produced • e.g. less defects are left in the shipped release • It improves the productivity and scheduling of the development process • e.g it ensures defects are found early and less time is spent fixing mistakes found late in the process • It helps to reduce the cost of development • e.g. if productivity improves and scheduling does not fall behind then costs go down.

  14. Relative Cost to Repair

  15. Defect Injection and Removal

  16. Defects found by removal operation ________________________________ X 100 Removal Effectiveness = Defects present at removal operation Defect Removal Effectiveness • Defects present at removal operation • Defects found during removal operation + defects found later • Defects found later may be determined ex post facto (after the fact), or using a statistical prediction model • Since the latent defects in a software product is unknown at any point in time, it is approximated by adding the number of defects removed during the phase to the number of defects found later (but that existed during that phase).

  17. Defect Injection and Removal

  18. Defects Injected (new mistakes) Undetected Defects Net Defects Defect Detection (inspection) Life Cycle Phase Unfixed Defects + Bad Fix Defects NetDefectsfrom previous Phase Known Defects Bad Fix Defects Fixed Defects Defect Injection & Removal Model Applies to each life cycle phase

  19. Defect Injection and Removal (similar model)

  20. Defect Removal Effectiveness • Defect removal effectiveness = (# of defects found by inspection) /(# of defects originally present) *100

  21. Defect Matrix Assumptions • Defects are removed in the same life cycle phase when they are found • No defects are knowingly left unfixed • No bad fixes – or at least they are blended into the number of defects created in that life cycle phase

  22. Sample Defect Matrix—When Originated vs. When Found W H E N F O U N D / F I X E D WHEN ORIGINATED (INJECTED OR CREATED) Calculate DRE for I0, I1, UT etc. ?

  23. Defects Created this Phase Defects passed from Previous life cycle phases Defects passed to Next life cycle phase Life cycle Phase(s) Defects Found & removed this Phase Defect Removal Effectiveness Next = (Previous + Created) – FoundDRE = Found / (Previous + Created) * 100

  24. Sample Defect Matrix—When Originated vs. When Found DRE for I0 W H E N F O U N D / F I X E D WHEN ORIGINATED (INJECTED OR CREATED) Defects found and removed at I0 = 730 Defects existing on step entry (escapes from Reqs) = 122 Defects injected in current phase (I0) = 859

  25. High Level Design Effectiveness • High (Top) Level Design (I0) Inspection Effectiveness • Defects found and removed at I0: 730 • Defects existing on step entry (escapes from requirements phase: 122 • Defects injected in current phase: 859 • E(I0) = 730/(122+859) x 100 = 74%

  26. Sample Defect Matrix—When Originated vs. When Found DRE for I1 W H E N F O U N D / F I X E D WHEN ORIGINATED (INJECTED OR CREATED) Defects found and removed at I1 = 729 Defects existing on step entry (escapes from Reqs & I0) = 122 + 859 – 730 = 251 Defects injected in current phase = 939

  27. Low Level Design Effectiveness • Low Level Design (I1) Inspection Effectiveness • Defects found and removed at I1: 729 • Defects existing on step entry (escapes from requirements phase and I0): 122+859-730 = 251 • Defects injected in current phase: 939 • E(I1) = 729/(251+939) x 100 = 61%

  28. Code Inspection Effectiveness • Code Inspection (I2) Effectiveness • Defects found and removed at I2: 1095 • Defects present on step entry (escapes from requirements phase, I0, and I1): 122+859+939-730-729 = 461 • Defects injected in current phase: 1537 • E(I2)= 1095/(461+1537) x 100 = 55%

  29. Unit Testing Effectiveness • Unit Testing (UT) Effectiveness • Defects found and removed at UT: 332 • Defects existing on step entry (escapes from previous phases): 122+859+939+1537-730-729-1095 = 903 • Defects injected in current phase (bad fixes): 2 • E(UT) = 332/(903+2) x 100 = 37%

  30. Summary Effectiveness Measures • Overall Design & Coding Inspection Effectiveness • IE = (730+729+1095)/(122+859+939+1537) x 100 = 74% • Overall Effectiveness of all Testing activities • TE = (332+387+111)/(903+2+4+1)x100 = 91% • Overall Defect Removal Effectiveness of the development process • DRE = (0+730+729+1095+332+387+111)/(122+859+ 939+1537+2+4+1) x 100 = 3384/3464*100 = 97.7%

  31. Phase Detected Requirements Design Coding/Unit Test Requirements 10 - - Design 3 18 - Coding 0 4 26 Test 2 5 8 Field 1 2 7 For example, assume that the following table reflects the defects detected during the specified phases and the phase where those defects were introduced. WHEN ORIGINATED (INJECTED OR CREATED) W H E N F O U N D / F I X E D

  32. The Defect Removal Effectiveness for each of the phases would be as follows: Requirements DRE = 10 / (10+3+0+2+1) x 100% = 63% Design DRE = (3+18) / (3+0+2+1+18+4+5+2) x 100% = 60% Coding DRE = (0+4+26) / (0+2+1+4+5+2+26+8+7) x 100% = 55% Testing DRE = (2+5+8) / (2+1+5+2+8+7) x 100% = 60% Defect Removal Effectiveness can also be calculated for the entire development cycle to examine defect detection efforts before the product is released to the field. According to Capers Jones, world class organizations have Development DRE greater than 95%. Development DRE = (Pre-release Defect) / (Total Defects) x 100% = (10+3+2+18+4+5+26+8) / (10+3+2+1+18+4+5+2+26+8+7) x 100 = 88%

  33. Example WBS/phase

  34. Γενικά χαρακτηριστικά Ορίζει τη ιεραρχία των παραδοτέων Προσδιορίζει την δουλειά που πρέπει να γίνει έτσι ώστε να αναπτύξουμε ένα παραδοτέο Δίνει την εικόνα του αντικειμένου των εργασιών του έργου. Διευκολύνει την παρακολούθηση του έργου Διευκολύνει την κοστολόγηση των παραδοτέων και την χρονο-δρομολόγηση των εργασιών. Βασικές συνιστώσες Δομή Διαγράμματα, κείμενο Μέθοδοι υποδιαίρεσης Δομική Ανάλυση Προϊόντος (PBS) Οργανωτική κατάτμηση (ΟBS) Δομική ανάλυση κόστους (CBS) Δομική ανάλυσησυμβάσεων Γεωγραφικής κατανομής Κωδικοποίηση Επίπεδο ανάλυσης Αριθμός επιπέδων Ενοποίηση WBS και OBS Work Breakdown Structure

  35. Κοιτάξτε όλο το project, το τελικό προϊόν Ψάξτε να δείτε ποια είναι τα παραδοτέα Αναλύστε στο επίπεδο που μπορείτε να διαχειριστείτε την παραγωγή των παραδοτέων Κάθε WBS στοιχείο αντιπροσωπεύει ένα παραδοτέο Κάθε WBS στοιχείο είναι η σύνθεση όλων των από κάτω Κάθε WBS στοιχείο έχει μόνο ένα πατέρα στοιχείο Το κάθε στοιχείο είναι διαφορετικό. Κανόνες για την κατασκευή WBS

  36. Apportion Method of Allocating Project Costs Using the Work Breakdown Structure

More Related