By Jack T. Marchewka Northern Illinois University Power Point Slides by Gerald DeHondt Grand Valley State University
Define Activities
Identifying what activities must be completed to produce the project scope deliverables Determining whether activities can be completed sequentially or in parallel and any dependencies that may exist among them Identifying the type of resources (people, technology, facilities, etc.) and the quantity of resources needed to carry out project activities Estimating the time to complete each activity Based on the availability of resources, the activities, their sequence, and time estimates, a schedule for the entire budget can be developed Ensuring that proper processes and procedures are in place in order to control changes to the project schedule
Sequence Activities
Develop Schedule
Control Schedule
6-3
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 Provides a link between the projects scope and detailed project plan Once the activities are defined, the next step is to estimate the duration of each activity
Estimation is not an exact science but the estimates improve as more details about the project are uncovered
6-4
Work Package
The WBS subdivides the project into smaller components and more manageable units of work called work packages
Enables the development of a project plan schedule, budget and subsequent monitoring of the projects progress
Each phase should provide at least one specific deliverable (a tangible and verifiable piece of work)
Work Package
6-6
Deliverables
Milestones
Significant events or achievements that provides evidence that the deliverable has been completed or that a phase is formally over Focuses on the achievement, not the deliverable
Smaller, shorter term deliverables keep the team focused Cruxes (proof of concepts)
Successfully use a piece of software for the first time on small set of data, validates proof of concept for expanding to full blown database
Quality control
6-7 No
A work package is developed for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC) Focus on Testing box with deliverable of Test Plan and Test Results
6-8
Logical Activities to produce the test results document: 1. Review the test plan with the client so that key stakeholders are clear as to what will be tested, how the tests will be conducted, and when the tests will be carried out. 2. Carry out the tests as outlined in the plan. 3. Once the test results are collected, we need to analyze them. 4. The results should be summarized in the form of a report and presentation to the client. 5. If all goes well, the client will sign-off or approve the test results and then we can move on to the implementation phase of the project. If not, then we need to address and fix any problems. What are the deliverables? Milestones?
6-9
6-10
6-11
The WBS
Should be deliverable oriented Should support the projects MOV The level of detail should support planning and control
WBS is bridge between scope and schedule/budget The experience and expertise of those involved will ensure that the level of detail will be appropriate
Learning cycles and lessons learned can support the development of a WBS
6-12
Focus on what they know (facts), what they think they know (assumptions) and what they need to find out (research) in order to develop a more useful WBS. Lessons learned help keep the project plan realistic and complete.
6-13
6-14
Estimation Questions
6-15
Time to complete an activity impacts cost due to resource(s) needed the project budget is thus impacted
Guesstimating Delphi Technique Time Boxing Top-Down Bottom-Up Analogous Estimates (Past experiences) Parametric Modeling (Statistical)
6-16
Guestimating
Estimation by guessing or just picking numbers out of the air is not the best way to derive a projects schedule and budget.
Unfortunately, many inexperienced project managers tend to guesstimate, or guess at the estimates, because it is quick and easy.
When put on the spot to give an estimate, give a range of time and cost and say that more research will enable a more confident estimate
6-17
18
Delphi Technique
Involves multiple, anonymous experts Each expert makes an estimate Estimates compared
Can take longer than most other estimation methods, but can be very effective and provide reasonable assurance
6-19
Time Boxing
Can focus a team if used effectively Can demoralize a team if not used effectively
6-20
Top-Down
Mandate from above has predetermined the time and cost of the project (competitor, satisfy client) Top & middle managers determine overall project schedule &/or cost Lower level managers are expected to breakdown schedule/budget estimates into specific activities (WBS)
6-21
Top-Down
When top-down estimation is done by people independent of the project it may be overly optimistic or overly aggressive
Death March project Project schedule has been compressed 50% or more Staff has been reduced by 50% or more Budget and resources have been reduced by 50% or more Functionality, features or other requirements are twice what they should be under typical circumstances Can force the PM to examine the project's risks more closely so that a specific budget or schedule target can be achieved 22
Bottom-Up
Schedules & budgets are constructed from WBS Starts with people who will be doing the work Schedules & budgets are the aggregate of detailed activities & costs Analogous estimation use information from previous, similar projects as a basis for estimation
6-23
Parametric Modeling
Use project characteristics (parameters) in a mathematical model to estimate Example: $50/ LOC based on:
6-24
How did we come up with these estimates? Using a technique, or combination of techniques, with the exception of guestimating!
6-25
Software engineering techniques focus on estimating the size of the system to be developed
6-26
Software engineering focuses on processes, tools and methods for developing a quality approach to developing software Metrics provide the basis for SE and refers to a broad range of measurements for objectively evaluating computer software
The greatest challenge for estimating an IT project is estimating the time and effort for the largest deliverable of the project the application system
True for maintenance projects and installation of packaged software as well Trying to estimate something that is not well defined until the later stages of the project life cycle The complexity and technical challenges are unknown or 27project optimistically glossed over in the early stages of the
Determinants of Estimating the Largest Deliverable of the Project The Application System
Application Estimate
Complexity
28
Proposed by Allan Albrecht of IBM in 1979 It is a synthetic metric much as hours, kilos and Celsius are Focuses on the functionality and complexity of the application Independent of the Technology
Avoids the program of different programming languages or technology platforms FP analysis is reliable in the sense that two analysts trained in FP analysis will obtain the same results within a margin of error
Two main organizations oversee the rules, guidelines, standards and certification for FP analysis
29
A FAP is done early on based on the projects scope followed by a more detailed analysis during the analysis and design stage FAP is based on an evaluation of five data and transactional types that define the application boundary 5 Primary Elements
30
6-31
Internal Logical File (ILF) AN ILF is a logical file that stores data within the application boundary.
For example, each entity in an E-R diagram would be considered an ILF. The complexity of an ILF can be classified as low, average, or high based on the number of data elements and subgroups of data elements maintained by the ILF.
External interface file (EIF)An EIF is similar to an ILF; however, an EIF is a file maintained by another application system. The complexity of an EIF is determined using the same criteria used for an ILF. External input (El)An El refers to processes or transactional data that originate outside the application and cross the application boundary from outside to inside. The data generally are added, deleted, or updated in one or more files internal to the application (i.e., internal logical files).
A common example of an EI would be a screen that allows the user to input information using a keyboard and a mouse. Data can, however, pass through the application boundary from other applications.
For example, a sales system may need a customers current balance from an accounts receivable system. Based on its complexity, in terms of the number of internal files referenced, number of data 32 elements (i.e., fields) included, and any other human factors, each EI is classified as low, average, or high.
External output (EO)Similarly, an EO is a process or transaction that allows data to exit the application boundary.
Examples of EOs include reports, confirmation messages, derived or calculated totals, and graphs or charts. This data could go to screens, printers, or other applications. After the number of EOs are counted, they are rated based on their complexity, like the external inputs (El).
External inquiry (EQ)An EQ is a process or transaction that includes a combination of inputs and outputs for retrieving data from either the internal files or from files external to the application.
EQs do not update or change any data stored in a file. They only read this information. Queries with different processing logic or a different input or output format are counted as a single EQ. Once the EQs are identified, they are classified based on their complexity as low, average or high, according to the number of files referenced and number of data elements included in the query
33
Once all of data and transactional types are counted and their relative complexities rated, an unadjusted function point (UAF) count is determined The following has been determined after reviewing the application system
EIF: 2 average
EI: 3 low, 5 average and 4 complex EO: 4 low, 2 average and 1 complex EQ: 2 low, 5 average and 3 complex It is based on the Degrees of Influence (DI), often called Processing Complexity Adjustment (PCA) Derived from the 14 General Systems Characteristics (GSC) To determine the total DI, each GSC is rated based on the following
1 = incidental influence
2 = moderate influence 3 = average influence 4 = significant influence 5 = strong influence
34
After reviewing the application, the Total Adjusted Function Points (TAFP) is computed to be 210 That number can be transformed into development estimates
Productivity how many function points can a programmer produce in a given period of time
LOC convert function points into lines of code based on the programming language
Backfiring technique which allows for direct conversion from source code to a function point count
Accuracy not high due to individual programming styles but can be use to create a FP inventory of an organizations project portfolio
35
Complexity
Degree of Influence
3 2 4 3 3 4 4 3 3 2
Low
Average
High
Total
_3 x 7 = 21
_2 x 10 = 20
_1 x 15 = 15
56
__ x 5 = __
_2 x 7 = 14
__ x 10 = __
14
Reusability
_3 x 3 = 9
_5 x 4 = 20
_4 x 6 = 24
53
Installation Ease
Operational Ease
3
3 1 2 40 VAF = (40 * .01) + .65 = 1.05
_4 x 4 = 16
_2 x 5 = 10
_1 x 7 = 7
33
_2 x 3 = 6
_5 x 4 = 20
_3 x 6 = 18
44
200
Total Adjusted Function Points = FP = UAF * VAF FP = 200 * 1.05 = 210
36
Based on LOC estimates, used to estimate cost, effort and schedule Open model (all equations, assumptions, definitions, etc. are freely available) It is a parametric model because it uses dependent variables such as cost or duration, based upon one or more independent variables that are quantitative indices of performance and/or physical attributes of the system
6-37
Organic Routine
Technology, processes and people are expected to all work together smoothly Person Months = 2.4 * KDSI1.05 System to support a new business process or new ground for the organization People may be less experienced and the processes and technology less mature Person Months = 3.6 * KDSI1.20 Not simple or straightforward but the organization feels confident that the processes, people and technology are adequate to meet the challenge Person Months = 3.0 * KDSI1.12 38
Embedded Challenging
Semi-Detached Middle
Semi-Detached
200 total adjusted function points Using Table 6.3 we know Java averages 53 SLOC per FP 200 FP * 53 10,600 Java LOC Assuming the project is of medium difficulty, we use the semi-detached equation to compute the effort
Person Months = 3.0 * KDSI1.12 = 3.0 * (10.6) 1.12 = 42.21
Having computed effort, we can now determine duration using the following formulas
Organic Duration = 2.5 * Effort0.38 Semi-Detached Duration = 2.5 * Effort0.35 Embedded Duration = 2.5 * Effort0.32
39
40
COCOMO
Intermediate COCOMO
Estimates the software development as a function of the size and a set of 15 subjective cost drives that include attributes of the end product, the computer used, the personnel staffing and the project environment Includes all the characteristics of intermediate COCOMO but with an assessment of the cost drivers impact over four phases of development: product design, detailed design, coding/testing and integration/testing More suited for projects developed using 4GLs (VB, Delphi, Power Builder) Uses LOC to estimate the projects size and 22 questions to calibrate the model 41
Advanced COCOMO
COCOMO II
SLIM
The same base activities will be required for a typical s/w development project and these activities will require a predictable percentage of the overall effort
Use knowledge gained from previous project experience when scheduling a software task: 1/3 Planning 1/6 Coding 1/4 Component test and early system test 1/4 System test, all components in hand
6-42
T. Capers Jones provides these heuristics Creeping user requirements will grow at an average rate of 2% per month from design through coding phases FPs raised to the 1.25 power predict the approximate defect potential for new s/w projects Each formal design inspection will find and remove 65% of the bugs present Maintenance programmers can repair 8 bugs per staff month FPs raised to the 0.4 power predict the approximate development schedule in calendar months FPs divided by 150 predict the approximate number of personnel required for the application FPs divided by 750 predict the approximate number of maintenance personnel required to keep the application updated Rules of thumb are easy, but they are not always 43 accurate
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, 1988 Page 120
6-44
Brooks Law
Adding manpower to a late software project makes it later.
6-45
People
Time versus number of workers perfectly partitionable task i.e., No communication among them e.g., reaping wheat.
6-46
People
When a task that cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule.
Adding People
The work & disruption of repartitioning Training new people Added intercommunication
6-47
6-48
Scope changes Overlooked tasks Poor developeruser communication Poor understanding of project goals Insufficient analysis
No (or poor) methodology Changes in team Red tape Lack of project control Not identifying or understanding impact of risks
6-49
Rate at which requirements may change Experience & capabilities of project team Process or methods used in development Specific activities to be performed Programming languages or development tools to be used Probable number of bugs or defects & removal methods Environment or ergonomics of work space Geographic separation of team across locations Schedule pressure placed on the team
6-50
Experience!
Lessons learned
Best Practices
6-51