1 / 16

Dr. Peter Hantos XEROX (310) 333 – 9038 peter.hantos@usa.xerox.com

Task-Unit Approach to Software Cost Estimation of Iterative Development. Dr. Peter Hantos XEROX (310) 333 – 9038 peter.hantos@usa.xerox.com. Objectives. Emphasize the importance of bottom-up estimation Address some known concerns with bottom-up estimation

gina
Télécharger la présentation

Dr. Peter Hantos XEROX (310) 333 – 9038 peter.hantos@usa.xerox.com

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. Task-Unit Approach to Software Cost Estimation of Iterative Development Dr. Peter Hantos XEROX (310) 333 – 9038 peter.hantos@usa.xerox.com © 2001 Peter Hantos

  2. Objectives • Emphasize the importance of bottom-up estimation • Address some known concerns with bottom-up estimation • Highlight the differences between activities vs. task-units • Present an incremental integration and test model • Present a step-by-step approach to task-unit determination © 2001 Peter Hantos

  3. Issues • Top-down estimation models are not good enough • Even the best models are inaccurate • For example COCOMO II Estimates within 25% of actuals 68% of the time • The granularity of top-down estimates is not high enough • Based on estimates one can not put together a detailed implementation plan • Use of classic WBS for bottom-up estimation is limited • Does not reflect integration and higher level relations between subsystems • Does not reflect the temporal aspects of development • Test is usually treated as the “red-headed stepchild” • Viewed as an independent entity, subordinated to development • Close interaction with development is not acknowledged © 2001 Peter Hantos

  4. System SA SN Subsystem Subsystem SS SS A N SAM SAA Subsystem Subsystem SS SS AA AM Component 1 Component 2 Component K Product Hierarchy WBS* *Source: Barry Boehm © 2001 Peter Hantos

  5. ITERATIONS RUP Core Process Workflows* INCEPTION ELABORATION CONSTRUCTION TRANSITION Preliminary #1 #2 #n #n+1 #n+2 #m #m+1 Business Modeling Requirements Analysis & Design Implementation Test Deployment * Source: http://www.rational.com © 2001 Peter Hantos

  6. Top Down Estimation • The building block is activity in a phase. For example in the Requirements Activity Category*: • Inception • Requirements development • Vision specification • Use Case modeling • Elaboration • Requirements base-lining • Vision base-lining • Use Case model base-lining • Construction • Requirements maintenance • Transition • Requirements maintenance *Source: Walker Royce's book © 2001 Peter Hantos

  7. Bottom Up Estimation • The building block is task-unit, bringing in an additional, component focus. For example in the Requirements Activity Category: • Elaboration • Feature/Function requirements base-lining for Component X © 2001 Peter Hantos

  8. Estimation and Test Planning • Typical* Test Planning: • Establish schedules for each test phase • Establish schedules and responsibilities for each test activity • Determine the availability of tools, facilities, and test libraries • Establish procedures and standards to be used • Set the criteria for test completion • What is missing? • Acknowledgment of the inter-twined nature of development and test activities in an incremental/iterative environment • Acknowledgement that test duration is really the length of a full cycle of test – fix – re-test activities * Source: Watts Humphrey © 2001 Peter Hantos

  9. Referenced Description High-level Objective Responsible Entity  Alpha Test Internal Validation Independent Test Group  Testability Preparation for Alpha Test Internal Validation Independent Test Group  Beta Test External Validation Launch Manager/Field Support Unit Test DVT SVT  Testability Test  Test DVT Design Verification Test Design Iteration Verification Independent Test Group SVT Software Verification Test Design Iteration Verification Engineering Test Group Unit Test Pre-integration software test First Design Verification Individual Software Developer Test Model for Task Unit Planning Note: Regression Test is not a separate category – It is a special test suite in any integration test matrix © 2001 Peter Hantos

  10. Incremental Integration & Testing Component X1 Component X2 Component X3 Component X4 SVTX1 SVTX2 SVTXn  SubsystemX DVTXY1 DVTXY2 SubsystemY SVTYn SVTY2 SVTY1 Component Y4 Component Y3 Component Y2 Component Y1 © 2001 Peter Hantos

  11. Example Task Unit Determination High-end Networked Digital Copier Product Line Core* Layers Component Names Component Depiction * 6 Architectural Layers, Total of 76 Major Components at design, 3000+ KLOC © 2001 Peter Hantos

  12. Example Generic Use Case: Image Path Scan Service Print Service Encoded Document TIFF PDL EXCHANGE EXCHANGE PDL Decomposition Image Formatting PDL Imaging Object Tokenize/ OCR Image Coding Partial Expand SCAN Raster Image PRINT PRINT Raster Image SCAN Image Coding Image Expand COPY Input Structure Analysis Color Processing Input Signature Correction Output Rendering COPY FROM SCANNER TO MARKER © 2001 Peter Hantos

  13. Use Case Approach High-end Networked Digital Copier Product Line Core* Use Case X © 2001 Peter Hantos

  14. N N j th Integration Test j th Integration Test Component Y development activities Component X development activities Unit Test Unit Test 1st Integration Test 1st Integration Test Regression Regression Task-Unit Model Component Task-Units: Planned increments of new features/functions Fixing Defects from First Integration Fixing Defects due to Regression System-wide Task-Units: All planned Integration Tests Alpha Test Beta Test © 2001 Peter Hantos

  15. Summary • Incremental Integration and Test enables the development of more accurate bottom-up estimates and project plans • The presented Task-Unit model allows higher visibility into regression management and provides tighter project control • Planning takes more discipline and effort, but the use of this approach increases software quality and delivery predictability © 2001 Peter Hantos

  16. References [1] Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981 [2] Walker Royce, Software Project Management, A Unified Framework, Addison-Wesley, 1998 [3] Watts S. Humphrey, Managing the Software Process, Addison-Wesley, 1989 © 2001 Peter Hantos

More Related