The Work Breakdown Structure and Project Estimation

1. The Work Breakdown Structure and Project Estimation

2. The Work Breakdown Structure (WBS) The WBS represents a logical decomposition of the work to be performed and focuses on how the product, service, or result is naturally subdivided. It is an outline of what work is to be performed. Gregory T. Haugan (2002)

3. The Work Breakdown Structure (WBS) • The WBS provides a framework for developing a tactical plan to structure the project work. • Work packages are major work items, or collection s of related tasks, required to produce a component.

4. Work Package

5. Deliverables and Milestones • Deliverables • Tangible, verifiable work products • Reports, presentations, prototypes, etc. • Milestones • Significant events or achievements • Acceptance of deliverables or phase completion • Cruxes (proof of concepts) • Quality control • Keeps team focused

6. Developing the WBS • Develop work packages for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC)

7. Work Breakdown Schedule

8. Approaches to Developing WBSs • Using guidelines: Some organizations, like the DoD, provide guidelines for preparing WBSs • The analogy approach: Review WBSs of similar projects and tailor to your project • The top-down approach: Start with the largest items of the project and break them down • The bottom-up approach: Start with the detailed tasks and roll them up • Mind-mapping approach: Write down tasks in a non-linear format and then create the WBS structure

9. Sample Mind-Mapping Approach

10. Developing the WBS- Keep in Mind • The WBS Should Be Deliverable-Oriented • Should produce something, not merely on completing a specified number of activities. • The WBS Should Support the Project's MOV • Ensure WBS allows for the delivery of all the project’s deliverables as defined in project scope • The Level of Detail Should Support Planning and Control • Should support not only the development of the project plan but also allow the project manager and project team to monitor and compare the project’s actual progress to the original plan’s schedule and budget

11. Developing the WBS- Keep in Mind • Developing the WBS Should Involve the People Who Will Be Doing the Work • Learning Cycles and Lessons Learned Can Support the Development of a WBS • Lessons learned from previous projects can be helpful in ensuring that the WBS and subsequent project plan are realistic and complete.

12. Project Estimation The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling,irrational commitments, unprofessional estimating techniques,and carelessness of the project management function are the factors that tend to introduce terminal problems. Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably. T. Capers Jones

13. Project Estimation • Guesstimating • Delphi Technique • Involves multiple, anonymous experts • Each expert makes an estimate • Estimates compared • If close, can be averaged • Else do another iteration until consensus is reached

14. Project Estimation • Top-Down Estimating • Estimate for the whole project and then break down • Often estimate in terms of what a project should cost and how long it should take as decreed by a member of top management who thinks those parameters are appropriate. • May be a response to the business environment • May lead to a death march project.

15. Project Estimation • Bottom-Up Estimating • Most common form of project estimation • Divide project into small modules and directly estimate time and effort in person-hours, weeks, or months for each module. • Analogous estimating based on similarity between current projects and others. • Estimates a function of activity and the duration is dependent on: • complexity of module • structure of module • resources and support assigned to module

16. Software Engineering Metrics and Approaches • software engineering • focuses on the processes, tools, and methods for developing a quality approach to developing software • metrics • provide the basis for software engineering and refers to a broad range of measurements for objectively evaluating computer software.

17. Determinates of application estimate

18. The Mythical Man-Month – Frederick Brooks • First, our techniques of estimation are poorly developed.More seriously, they reflect an unvoiced assumption which is quite untrue i.e., that all will go well. • Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. • Third, because we are uncertain of our estimates,software managers often lack the courteous stubbornness of Antoines chef): Good cooking takes time. If you are made to wait, it is to serve you better,and to please you. (From the menu of Antoines,a restaurant in New Orleans)

19. The Mythical Man-Month – Frederick Brooks • Fourth, schedule progress is poorly monitored.Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. • Fifth, when schedule slippage is recognized, the natural tendency (and traditional) response it to add more manpower. Like dousing a fire with gasoline,this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

20. The Mythical Man-Month – Frederick Brooks Brooks Law: “Adding manpower to a late software project makes it later.”

21. Software Estimation • Direct measurement • LOC • Indirect measurement • Heuristics • Function point • Feature point • 3D Function point

22. Lines of Code (LOC) • Lines of Code (LOC) • Most traditionally used metric for project sizing • Most controversial • Count comments? • Declaring variables? • Efficient code vs. code bloat • Language differences • Easier to count afterwards than to estimate

23. Lines of Code (LOC)

24. Software Estimation • Heuristics • Rules of thumb approach to estimating • Require a predictable percentage of the overall effort • 30% planning • 20% coding • 25% component testing • 25% system testing • Estimating Software Costs -Capers

25. Function Points • Function Points • analysis based on evaluation of data and transactional types: • Internal Logical File (ILF) • External Interface File (EIF) • External Input (EI) • External Output (EO) • External Inquiry (EQ)

26. The Application Boundary for Function Point Analysis

27. Function Points • Application Boundaries • The application is planned to be developed in multiple stages, using more than one development project should be counted, estimated, and measured as separate projects, including all inputs, outputs, interfaces and inquiries crossing all boundaries. • The application is planned to be developed as a single application using one development project, but it is so large divide it into subapplications

28. Function Points • Application Boundaries (con’t) • The subapplications should be counted separated, but none of the inputs, outputs, interfaces, and inquiries crossing the arbitrary internal boundaries should be counted. • The function points of the subapplications should be summed to give the total function points of the application.

29. Function Points- Steps • Classify and count the five user function types • 3 level of complexity • Adjust for processing complexity • Make the function point calculation

30. Weight Factor count measurement parameter average complex count simple count number of user inputs x 3 + x 4 + x 6 = number of user outputs x 4 + x 5 + x 7 = number of user inquiries x 3 + x 4 + x 6 = number of user files x 7 + x 10 + x 15 = number of ext. interfaces x 5 + x 7 + x 10 = count = total complexity multiplier function points Function Points

31. Function Points • External Input Types are screen or forms through which human users of an application or other programs add new data or update existing data. • Count each unique user data or user control input type that enters the external boundary of the application being measured, and adds or changes data in a logical internal file type. • An external input type should be considered unique if it has a different format, or requires a processing logic different from other external input types of the same format.

32. Function Points • External Input Type • Simple: few data element types included in the external input type, and few logical internal file types are referenced by the external input type. User human factors considerations are not significant in the design of the external input type. • Average: is not clearly either simple or complex • Complex: many data element types are included in the external input type, and many logical internal file types are referenced by the external input type. User human factors considerations significantly affect the design of the external input type.

33. Function Points • External Output Types are screens or reports, or messages which the application produces for humans use or for other programs. • Count each unique user data or control output type that leaves the external boundary of the application being measured. • An external output type should be considered unique if it has a different format, or requires a processing logic different from other external output types of the same format

34. Function Points • External Output Type • Simple: one or more columns, simple data element transformation • Average: multiple columns with subtotals, multiple data element transformation • Complexity: intricate data element transformations, multiple and complex file references to be correlated, significant performance considerations.

35. Function Points • Logical Internal File Types are logical collections of records which the application modifies or updates. • Count each major logical group of user data or control information in the application, include logical file, or within a data base, each logical group of data from the viewpoint of the user, that is generated, used, and maintained by the application.

36. Function Points • Logical Internal File Types • Simple: few record types, few data element types, no significant performance or recovery considerations. • Average: is not clearly either simple or complex • Complex: many record types, many data element types, performance and recovery are significant considerations.

37. Function Points • External Interface File Types are files passed or shared with other applications. • Count each major logical group of user data or control information that enters or leaves the application. • Complexity classification: use definition similar to those for logical internal file types.

38. Function Points • External Inquiries Types are screens which allow users to interrogate the application and ask for assistance or information. • Count each unique input/output combination, where an input causes and generates an immediate output. • An external inquiry type should be considered unique if it has a format different from other external inquiry types in either its input or output parts, or requires a processing logic different from other external inquiry type of the same format.

39. Function Points • External Inquiry Types • classify the input part using definitions similar to the external input type • classify the output part using definition similar to the external output type. • The complexity of the external inquiry type is the greater of the two classifications.

40. IFPUG File Type Complexity

41. IFPUG External Input Complexity

42. IFPUG External Output Complexity

43. Processing Complexity • Estimate the degree of influence of each of the 14 general characteristics • Sum the 14 degree of influences and develop an adjustment factor • Multiply the adjustment factor to the work-product measure

44. Data Communications Distributed Data Processing Performance Heavily Used Configuration Transaction Rate Online Data Entry End User Efficiency Online Update Complex Processing Reusability Installation Ease Operational Ease Multiple Sites Facilitate Change 14 General Characteristics

45. GSC and Total Adjusted Function Point

46. Fi M Function Point - Calculation • Adjustment factor = 0.65 + 0.01 X • Function Point = count-total X adjustment factor

47. Sensors test sensor zone setting password User SafeHome User Interface Function zone inquiry messages User panic button sensor status sensor inquiry activate/ deactivate activate/deactivate alarm alert Monitoring & Response Subsystem Password, sensor, … System configuration data Example

48. Feature Points • Feature Points were originally invented to solve the measurement problems of classical MIS. • Feature Point measure accommodates applications in which algorithmic complexity is high such as real time software, systems software, embedded software. • Algorithm is defined as the set of rules which must be completely expressed to solve a significant computational problem.

49. Example: Feature Points Approach

50. 3D Function Point • Data dimension is evaluated in the same way as Function Point (inputs, outputs, inquiries, logical files, interface files) • Functional dimension is measured by considering the number of internal operations required to transform input to output data. • Input and output data may be either internal to the application, external application , or both. • Level of complexity of each transformation is a function of the number of processing steps and the number of semantic statements that control the processing steps.