MOE 225-Software Project Management.ppt


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MOE 225-Software Project Management.ppt

  1. 1. Software Project Management <ul><li>MOE 225 Software Engineering </li></ul><ul><li>Topic 8 </li></ul>
  2. 2. Project Teams - Overview <ul><li>Team organization </li></ul><ul><li>Democratic team approach </li></ul><ul><li>Classical chief programmer team approach </li></ul><ul><li>Beyond chief programmer and democratic teams </li></ul><ul><li>Synchronize-and-stabilize teams </li></ul><ul><li>Extreme programming teams </li></ul>
  3. 3. Programming Team Organization <ul><li>A product must be completed within 3 months, but 1 person-year of programming is still needed </li></ul><ul><li>Solution </li></ul><ul><ul><li>If one programmer can code the product in 1 year, four programmers can do it in 3 months </li></ul></ul><ul><li>Nonsense </li></ul><ul><ul><li>Four programmers will probably take nearly a year </li></ul></ul><ul><ul><li>The quality of the product is usually lower </li></ul></ul>
  4. 4. Task Sharing <ul><li>If one farm hand can pick a strawberry field in 10 days, ten farm hands can pick same strawberry field in 1 day </li></ul><ul><li>One woman can produce a baby in 9 months, but nine women cannot possibly produce that baby in 1 month </li></ul><ul><li>Unlike baby production, it is possible to share coding tasks between members of team </li></ul><ul><li>Unlike strawberry picking, team members must interact in meaningful and effective way </li></ul>
  5. 5. Programming Team Organization <ul><li>Example: </li></ul><ul><ul><li>Freda and Joe code two modules, mA and mB , say. </li></ul></ul><ul><li>What can go wrong? </li></ul><ul><ul><li>Both Freda and Joe may code mA , and ignore mB </li></ul></ul><ul><ul><li>Freda may code mA , Joe may code mB . When mA calls mB it passes 4 parameters; but mB requires 5 parameters </li></ul></ul><ul><ul><li>Or, the order of parameters in mA and mB may be different </li></ul></ul><ul><ul><li>Or, the order may be same, but the data types may be slightly different </li></ul></ul><ul><li>This has nothing whatsoever to do with technical competency </li></ul><ul><ul><li>Team organization is a managerial issue </li></ul></ul>
  6. 6. Communications Problems <ul><li>Example </li></ul><ul><ul><li>There are three channels of communication between 3 programmers working on project. The deadline is rapidly approaching but the code is not nearly complete </li></ul></ul><ul><li>“ Obvious” solution: </li></ul><ul><ul><li>Add a fourth programmer to the team </li></ul></ul><ul><li>But other three have to explain in detail </li></ul><ul><ul><li>What has been accomplished </li></ul></ul><ul><ul><li>What is still incomplete </li></ul></ul><ul><li>Brooks’s Law </li></ul><ul><ul><li>Adding additional programming personnel to a team when product is late has the effect of making the product even later </li></ul></ul>
  7. 7. Democratic Team Approach <ul><li>Basic underlying concept— egoless programming </li></ul><ul><li>Programmers can be highly attached to their code </li></ul><ul><ul><li>They even name their modules after themselves </li></ul></ul><ul><ul><li>They see their modules as extension of themselves </li></ul></ul><ul><li>If a programmer sees a module as an extension of his/her ego, he/she is not going to try to find all the errors in “his”/“her” code </li></ul><ul><ul><li>If there is an error, it is termed a bug  </li></ul></ul><ul><ul><li>The fault could have been prevented if code had been better guarded against the “bug” </li></ul></ul><ul><ul><li>“ Shoo-Bug” aerosol spray </li></ul></ul>
  8. 8. Democratic Team Approach <ul><li>Proposed Solution </li></ul><ul><ul><li>Egoless programming </li></ul></ul><ul><ul><ul><li>Restructure the social environment </li></ul></ul></ul><ul><ul><ul><li>Restructure programmers’ values </li></ul></ul></ul><ul><ul><ul><li>Encourage team members to find faults in code </li></ul></ul></ul><ul><ul><ul><li>A fault must be considered a normal and accepted event </li></ul></ul></ul><ul><ul><ul><li>The team as whole will develop an ethos, group identity </li></ul></ul></ul><ul><ul><ul><li>Modules will “belong” to the team as whole </li></ul></ul></ul><ul><ul><ul><li>A group of up to 10 egoless programmers constitutes a democratic team </li></ul></ul></ul>
  9. 9. Democratic Team Approach <ul><li>Strengths of Democratic Team Approach </li></ul><ul><ul><li>Democratic teams are enormously productive </li></ul></ul><ul><ul><li>They work best when the problem is difficult </li></ul></ul><ul><ul><li>They function well in a research environment </li></ul></ul><ul><ul><li>Problem: </li></ul></ul><ul><ul><ul><li>Democratic teams have to spring up spontaneously </li></ul></ul></ul><ul><li>Difficulties with Democratic Team Approach </li></ul><ul><ul><li>Management may have difficulty </li></ul></ul><ul><ul><ul><li>Difficult to introduce into an undemocratic environment </li></ul></ul></ul>
  10. 10. Chief Programmer Teams <ul><li>Consider a 6-person team </li></ul><ul><ul><li>Fifteen 2-person communication channels </li></ul></ul><ul><ul><li>The total number of 2-, 3-, 4-, 5-, and 6-person groups is 57 </li></ul></ul><ul><ul><li>This team cannot do 6 person-months of work in 1 month </li></ul></ul>
  11. 11. Chief Programmer Teams (contd) <ul><li>Six programmers, but now only 5 lines of communication </li></ul>
  12. 12. Classical Chief Programmer Teams <ul><li>Basic idea behind the concept </li></ul><ul><ul><li>Analogy: chief surgeon directing operation, assisted by </li></ul></ul><ul><ul><ul><li>Other surgeons </li></ul></ul></ul><ul><ul><ul><li>Anesthesiologists </li></ul></ul></ul><ul><ul><ul><li>Nurses </li></ul></ul></ul><ul><ul><ul><li>Other experts, such as cardiologists, nephrologists </li></ul></ul></ul><ul><li>Two key aspects </li></ul><ul><ul><li>Specialization </li></ul></ul><ul><ul><li>Hierarchy </li></ul></ul>
  13. 13. Classical Chief Programmer Teams <ul><li>Chief programmer </li></ul><ul><ul><li>Successful manager and highly skilled programmer </li></ul></ul><ul><ul><li>Does the architectural design </li></ul></ul><ul><ul><li>Allocates coding among the team members </li></ul></ul><ul><ul><li>Writes the critical (or complex) sections of code </li></ul></ul><ul><ul><li>Handles all the interfacing issues </li></ul></ul><ul><ul><li>Reviews the work of the other team members </li></ul></ul><ul><ul><li>Is personally responsible for every line of code </li></ul></ul><ul><li>Back-up programmer </li></ul><ul><ul><li>Necessary only because the chief programmer is human </li></ul></ul><ul><ul><li>The back-up programmer must be in every way as competent as the chief programmer </li></ul></ul><ul><ul><li>Must know as much about the project as the chief programmer </li></ul></ul><ul><ul><li>Does black-box test case planning and other tasks that are independent of the design process </li></ul></ul>
  14. 14. Classical Chief Programmer Teams <ul><li>Programming secretary </li></ul><ul><ul><li>A highly skilled, well paid, central member of the chief programmer team </li></ul></ul><ul><ul><li>Responsible for maintaining the program production library (documentation of project), including: </li></ul></ul><ul><ul><ul><li>Source code listings </li></ul></ul></ul><ul><ul><ul><li>JCL </li></ul></ul></ul><ul><ul><ul><li>Test data </li></ul></ul></ul><ul><ul><li>Programmers hand their source code to the secretary who is responsible for </li></ul></ul><ul><ul><ul><li>Conversion to machine-readable form, </li></ul></ul></ul><ul><ul><ul><li>Compilation, linking, loading, execution, and running test cases (1971, remember!) </li></ul></ul></ul><ul><li>Programmers </li></ul><ul><ul><li>Do nothing but program </li></ul></ul><ul><ul><li>All other aspects are handled by the programming secretary </li></ul></ul>
  15. 15. Classical Chief Programmer Teams <ul><li>Strengths of CPT Approach </li></ul><ul><ul><li>It works </li></ul></ul><ul><ul><li>Numerous successful projects have used variants of CPT </li></ul></ul><ul><li>Weaknesses of the CPT Approach </li></ul><ul><ul><li>Chief programmer must be a highly skilled programmer and a successful manager </li></ul></ul><ul><ul><ul><li>Shortage of highly skilled programmers </li></ul></ul></ul><ul><ul><ul><li>Shortage of successful managers </li></ul></ul></ul><ul><ul><ul><li>Programmers and managers “are not made that way” </li></ul></ul></ul><ul><ul><li>Back-up programmer must be as good as the chief programmer </li></ul></ul><ul><ul><ul><li>But he/she must take a back seat (and a lower salary) waiting for something to happen to the chief programmer </li></ul></ul></ul><ul><ul><ul><li>Top programmers, top managers will not do that </li></ul></ul></ul><ul><ul><li>Programming secretary does nothing but paperwork all day </li></ul></ul><ul><ul><ul><li>Software professionals hate paperwork </li></ul></ul></ul><ul><ul><li>Classical CPT is impractical </li></ul></ul>
  16. 16. Beyond CP and Democratic Teams <ul><li>We need ways to organize teams that </li></ul><ul><ul><li>Make use of the strengths of democratic teams and chief programmer teams, and </li></ul></ul><ul><ul><li>Can handle teams of 20 (or 120) programmers </li></ul></ul><ul><li>Democratic teams </li></ul><ul><ul><li>Positive attitude to finding faults </li></ul></ul><ul><li>Use CPT in conjunction with code walkthroughs or inspections </li></ul><ul><li>Potential Pitfall </li></ul><ul><li>Chief programmer is personally responsible for every line of code. </li></ul><ul><ul><li>He/she must therefore be present at reviews </li></ul></ul><ul><li>Chief programmer is also the team manager </li></ul><ul><ul><li>He/she must therefore not be present at reviews! </li></ul></ul>
  17. 17. Beyond CP and Democratic Teams <ul><li>Solution </li></ul><ul><ul><li>Reduce the managerial role of the chief programmer </li></ul></ul>
  18. 18. Beyond CP and Democratic Teams <ul><li>It is easier to find a team leader than a chief programmer </li></ul><ul><li>Each employee is responsible to exactly one manager—lines of responsibility are clearly delineated </li></ul><ul><li>Team leader is responsible for only technical management </li></ul><ul><li>Budgetary and legal issues, and performance appraisal are not handled by the team leader </li></ul><ul><li>Team leader participates in reviews—the team manager is not permitted to do so </li></ul><ul><li>Team manager participates at regular team meetings to appraise the technical skills of the team members </li></ul>
  19. 19. Larger Projects <ul><li>Nontechnical side is similar </li></ul><ul><li>For even larger products, add additional layers </li></ul>
  20. 20. Beyond CP and Democratic Teams <ul><li>Decentralize the decision-making process where appropriate </li></ul><ul><li>Useful where the democratic team is good </li></ul>
  21. 21. Synchronize-and-Stabilize Teams <ul><li>Used by Microsoft </li></ul><ul><li>Products consist of 3 or 4 sequential builds </li></ul><ul><li>Small parallel teams </li></ul><ul><ul><li>3 to 8 developers </li></ul></ul><ul><ul><li>3 to 8 testers (work one-to-one with developers) </li></ul></ul><ul><ul><li>Team is given the overall task specification </li></ul></ul><ul><ul><li>They may design the task as they wish </li></ul></ul><ul><li>Why this does not degenerate into hacker-induced chaos </li></ul><ul><ul><li>Daily synchronization step </li></ul></ul><ul><ul><li>Individual components always work together </li></ul></ul>
  22. 22. Synchronize-and-Stabilize Teams <ul><li>Rules </li></ul><ul><ul><li>Must adhere to the time to enter the code into the database for that day's synchronization </li></ul></ul><ul><li>Analogy </li></ul><ul><ul><li>Letting children do what they like all day … but with a 9 P.M. bedtime </li></ul></ul><ul><li>Will this work in all companies? </li></ul><ul><ul><li>Perhaps if the software professionals are as good as at Microsoft </li></ul></ul><ul><ul><li>Again, more research is needed </li></ul></ul>
  23. 23. Extreme Programming Teams <ul><li>Feature of XP </li></ul><ul><ul><li>All code is written by two programmers sharing a computer </li></ul></ul><ul><ul><li>“ Pair programming” </li></ul></ul><ul><li>Advantages of Pair Programming </li></ul><ul><ul><li>Test cases drawn up by one member of team </li></ul></ul><ul><ul><li>Knowledge not all lost if one programmer leaves </li></ul></ul><ul><ul><li>Inexperienced programmers can learn </li></ul></ul><ul><ul><li>Centralized computers promote egoless programming </li></ul></ul>
  24. 24. Final Remarks on Team Organization <ul><li>There is no one solution to the problem of team organization </li></ul><ul><li>The “correct” way depends on </li></ul><ul><ul><li>The product </li></ul></ul><ul><ul><li>The outlook of the leaders of the organization </li></ul></ul><ul><ul><li>Previous experience with various team structures </li></ul></ul><ul><li>Very little research has been done on software team organization </li></ul><ul><ul><li>Instead, team organization has been based on research on group dynamics in general </li></ul></ul><ul><li>Without relevant experimental results, it is hard to determine optimal team organization for a specific product </li></ul>
  25. 25. Planning and Estimating Overview <ul><li>Planning and the software process </li></ul><ul><li>Estimating duration and cost </li></ul><ul><li>Software project management plan components </li></ul><ul><li>Software project management plan framework </li></ul><ul><li>IEEE software project management plan </li></ul><ul><li>Planning of testing </li></ul><ul><li>Planning of object-oriented projects </li></ul><ul><li>Training requirements </li></ul><ul><li>Documentation standards </li></ul>
  26. 26. Planning and Estimating <ul><li>Before starting to build software, it is essential to plan the entire development effort in detail </li></ul><ul><li>Planning continues during development and then maintenance </li></ul><ul><ul><li>Initial planning is not enough </li></ul></ul><ul><ul><li>The earliest possible detailed planning is after the specification phase </li></ul></ul>
  27. 27. Planning and the Software Process <ul><li>Accuracy of estimation increases as the process proceeds </li></ul>
  28. 28. Planning and the Software Process <ul><li>Example </li></ul><ul><ul><li>Cost estimate of $1 million during the requirements phase </li></ul></ul><ul><ul><ul><li>Likely actual cost is in the range ($0.25M, $4M) </li></ul></ul></ul><ul><ul><li>Cost estimate of $1 million in the middle of the specification phase </li></ul></ul><ul><ul><ul><li>Likely actual cost is in the range ($0.5M, $2M) </li></ul></ul></ul><ul><ul><li>Cost estimate of $1 million end of the specification phase (earliest appropriate time) </li></ul></ul><ul><ul><ul><li>Likely actual cost is in the range ($0.67M, $1.5M) </li></ul></ul></ul><ul><li>This model is old (1976) </li></ul><ul><ul><li>Estimating techniques have improved </li></ul></ul><ul><ul><li>But the shape of the curve is likely to be similar </li></ul></ul>
  29. 29. Estimating Duration and Cost <ul><li>Accurate duration estimation is critical </li></ul><ul><li>Accurate cost estimation is critical </li></ul><ul><ul><li>Internal, external costs </li></ul></ul><ul><li>There are too many variables for accurate estimate of cost or duration </li></ul>
  30. 30. Human Factors <ul><li>Sackman (1968) showed differences of up to 28 to 1 between pairs of programmers </li></ul><ul><li>He compared matched pairs of programmers </li></ul><ul><ul><li>Product size </li></ul></ul><ul><ul><li>Product execution time </li></ul></ul><ul><ul><li>Development time </li></ul></ul><ul><ul><li>Coding time </li></ul></ul><ul><ul><li>Debugging time </li></ul></ul><ul><li>Critical staff members may resign during project </li></ul>
  31. 31. Metrics for the Size of a Product <ul><li>Lines of Code (LOC) </li></ul><ul><li>Software Science </li></ul><ul><li>FFP </li></ul><ul><li>Function Points </li></ul><ul><li>COCOMO </li></ul>
  32. 32. Lines of Code <ul><li>Lines of code (LOC), or </li></ul><ul><li>Thousand delivered source instructions (KDSI) </li></ul><ul><ul><li>Source code is only a small part of total software effort </li></ul></ul><ul><ul><li>Different languages  different lengths of code </li></ul></ul><ul><ul><li>LOC not defined for nonprocedural languages (like LISP) </li></ul></ul><ul><ul><li>It is not clear how to count lines of code </li></ul></ul><ul><ul><ul><li>Executable lines of code? </li></ul></ul></ul><ul><ul><ul><li>Data definitions ? </li></ul></ul></ul><ul><ul><ul><li>Comments? </li></ul></ul></ul><ul><ul><ul><li>JCL statements? </li></ul></ul></ul><ul><ul><ul><li>Changed/deleted lines? </li></ul></ul></ul><ul><ul><li>Not everything written is delivered to the client </li></ul></ul>
  33. 33. Lines of Code (contd) <ul><li>LOC is known when the product finished </li></ul><ul><li>Estimation based on LOC is doubly dangerous </li></ul><ul><ul><li>To start estimation process, LOC in finished product must be estimated </li></ul></ul><ul><ul><li>LOC estimate is then used to estimate the cost of the product — uncertain input to an uncertain cost estimator </li></ul></ul>
  34. 34. Software Science <ul><li>Metrics based on number of operands, operators </li></ul><ul><li>Limited predictive power—metrics can be computed only after the product has been implemented </li></ul><ul><li>There are major doubts about the validity of Software Science </li></ul>
  35. 35. Metrics for the Size of a Product <ul><li>Metrics based on measurable quantities that can be determined early in software life cycle </li></ul><ul><ul><li>FFP </li></ul></ul><ul><ul><li>Function Points </li></ul></ul>
  36. 36. FFP Metric <ul><li>For cost estimation of medium-scale DP systems </li></ul><ul><li>The three basic structural elements of DP systems </li></ul><ul><ul><li>files, flows, and processes </li></ul></ul><ul><li>Given number of files ( Fi ), flows ( Fl ), processes ( Pr ) </li></ul><ul><ul><li>Size ( S ), cost ( C ) given by </li></ul></ul><ul><ul><ul><li>S = Fi + Fl + Pr </li></ul></ul></ul><ul><ul><ul><li>C = b  S </li></ul></ul></ul><ul><li>Constant b varies from organization to organization </li></ul><ul><li>Validity and reliability of FFP metric were demonstrated using a purposive sample </li></ul><ul><ul><li>BUT, the metric was never extended to include databases </li></ul></ul>
  37. 37. Function Points <ul><li>Based on number of inputs ( Inp ), outputs ( Out ), inquiries ( Inq ), master files ( Maf ), interfaces ( Inf ) </li></ul><ul><li>For any product, size in “function points” is given by </li></ul><ul><ul><ul><li>FP = 4  Inp + 5  Out + 4  Inq + 10  Maf + 7  Inf </li></ul></ul></ul><ul><li>Oversimplification of a 3-step process. </li></ul>
  38. 38. Function Points (contd) <ul><li>1. Classify each component of product ( Inp, Out, Inq, Maf, Inf ) as simple, average, or complex. </li></ul><ul><ul><li>Assign appropriate number of function points </li></ul></ul><ul><ul><li>Sum gives UFP (unadjusted function points) </li></ul></ul>
  39. 39. Function Points (contd) <ul><li>2. Compute technical complexity factor ( TCF ) </li></ul><ul><ul><li>Assign value from 0 (“not present”) to 5 (“strong influence throughout”) to each of 14 factors such as transaction rates, portability </li></ul></ul><ul><ul><li>Add 14 numbers  total degree of influence ( DI ) </li></ul></ul><ul><ul><ul><li>TCF = 0.65 + 0.01  DI </li></ul></ul></ul><ul><ul><li>Technical complexity factor ( TCF ) lies between 0.65 and 1.35 </li></ul></ul><ul><li>3. Number of function points ( FP ) given by </li></ul><ul><ul><ul><li>FP = UFP  TCF </li></ul></ul></ul>
  40. 40. Analysis of Function Points <ul><li>Function points are usually better than KDSI—but there are some problems </li></ul><ul><li>“ Errors in excess of 800% counting KDSI, but only 200% in counting function points” (Jones, 1987) </li></ul><ul><li>Like FFP, maintenance can be inaccurately measured </li></ul>
  41. 41. Techniques of Cost Estimation <ul><li>Expert judgment by analogy </li></ul><ul><li>Experts compare target product to completed products </li></ul><ul><ul><li>Guesses can lead to hopelessly incorrect cost estimates </li></ul></ul><ul><ul><li>Experts may recollect completed products inaccurately </li></ul></ul><ul><ul><li>Human experts have biases </li></ul></ul><ul><ul><li>However, results of estimation by broad group of experts may be accurate </li></ul></ul><ul><li>Bottom-up approach </li></ul><ul><li>Break product into smaller components </li></ul><ul><ul><li>Smaller components may be no easier to estimate </li></ul></ul><ul><ul><li>Process-level costs </li></ul></ul>
  42. 42. Techniques of Cost Estimation <ul><li>Algorithmic models </li></ul><ul><li>Metric used as input to model to compute cost, duration </li></ul><ul><ul><li>An algorithmic model is unbiased, and superior to expert opinion </li></ul></ul><ul><ul><li>However, estimates are only as good as the underlying assumptions </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>SLIM Model </li></ul></ul><ul><ul><li>Price S Model </li></ul></ul><ul><ul><li>CO nstructive CO st MO del (COCOMO) </li></ul></ul><ul><li>COCOMO consists of three models </li></ul><ul><ul><li>Macro-estimation model for product as a whole </li></ul></ul><ul><ul><li>Intermediate COCOMO </li></ul></ul><ul><ul><li>Micro-estimation model which treats product in detail </li></ul></ul><ul><li>We examine intermediate COCOMO </li></ul>
  43. 43. Intermediate COCOMO <ul><li>1. Estimate length of product in KDSI </li></ul><ul><li>2. Estimate product development mode (organic, semidetached, embedded) </li></ul><ul><li>Example </li></ul><ul><ul><li>Straightforward product (“organic mode”) </li></ul></ul><ul><ul><li>Nominal effort = 3.2  (KDSI) 1.05 person-months </li></ul></ul>
  44. 44. Intermediate COCOMO <ul><li>3. Compute nominal effort </li></ul><ul><li>Example </li></ul><ul><ul><li>Organic product, est. 12,000 delivered source statements (12 KDSI) </li></ul></ul><ul><ul><li>Nominal effort = 3.2  (12) 1.05 = 43 person-months </li></ul></ul><ul><li>4. Multiply nominal value by 15 software development cost multipliers </li></ul><ul><li>Example </li></ul><ul><ul><li>Product complexity multiplier </li></ul></ul><ul><li>Intermodule control and decision tables </li></ul>
  45. 45. Intermediate COCOMO (contd) <ul><li>Software development effort multipliers </li></ul>
  46. 46. Intermediate COCOMO (contd) <ul><li>Example </li></ul><ul><ul><li>Microprocessor-based communications processing software for electronic funds transfer network with high reliability, performance, development schedule, and interface requirements </li></ul></ul><ul><li>1. Complex (“embedded”) mode </li></ul><ul><li>2. Estimate: 10,000 delivered source instructions </li></ul><ul><li>3. Nominal effort = 2.8  (10) 1.20 = 44 person-months </li></ul><ul><li>4. Product of effort multipliers = 1.35, so estimated effort for project is </li></ul><ul><ul><li>1.35  44 = 59 person-months </li></ul></ul>
  47. 47. Intermediate COCOMO (contd) <ul><li>Software development effort multipliers </li></ul>
  48. 48. Intermediate COCOMO (contd) <ul><li>Estimated effort for project (59 person-months) used as input for additional formulas for </li></ul><ul><ul><li>Dollar costs </li></ul></ul><ul><ul><li>Development schedules </li></ul></ul><ul><ul><li>Phase and activity distributions </li></ul></ul><ul><ul><li>Computer costs </li></ul></ul><ul><ul><li>Annual maintenance costs </li></ul></ul><ul><ul><li>Related items </li></ul></ul><ul><li>Intermediate COCOMO has been validated with respect to broad sample </li></ul><ul><li>Actual values within 20% of predicted values about 68% of time </li></ul><ul><ul><li>Intermediate COCOMO was most accurate estimation method of its time </li></ul></ul>
  49. 49. COCOMO II <ul><li>1995 extension to 1981 COCOMO that incorporates </li></ul><ul><ul><li>Object orientation </li></ul></ul><ul><ul><li>Modern life-cycle models </li></ul></ul><ul><ul><li>Rapid prototyping </li></ul></ul><ul><ul><li>Fourth-generation languages </li></ul></ul><ul><ul><li>COTS software </li></ul></ul><ul><li>COCOMO II is far more complex than the first version </li></ul><ul><li>Three different models </li></ul><ul><ul><li>Application composition model for early phases </li></ul></ul><ul><ul><ul><li>Based on feature points (like function points) </li></ul></ul></ul><ul><ul><li>Early design model </li></ul></ul><ul><ul><ul><li>Based on function points </li></ul></ul></ul><ul><ul><li>Post-architecture model </li></ul></ul><ul><ul><ul><li>Based on function points or KDSI </li></ul></ul></ul>
  50. 50. COCOMO II (contd) <ul><li>COCOMO Effort model is effort = a (size) b </li></ul><ul><ul><li>Intermediate COCOMO </li></ul></ul><ul><ul><ul><li>Three values for ( a , b ) </li></ul></ul></ul><ul><ul><li>COCOMO II </li></ul></ul><ul><ul><ul><li>b varies depending on values of certain parameters </li></ul></ul></ul><ul><li>COCOMO II supports reuse </li></ul><ul><li>COCOMO II has 17 multiplicative cost drivers (was 15) </li></ul><ul><ul><li>Seven are new </li></ul></ul><ul><li>It is too soon for results regarding </li></ul><ul><ul><li>Accuracy of COCOMO II </li></ul></ul><ul><ul><li>Extent of improvement (if any) over Intermediate COCOMO </li></ul></ul>
  51. 51. Tracking Duration and Cost Estimates <ul><li>Whatever estimation method used, careful tracking is vital </li></ul><ul><li>Components of a software project management plan (SPMP) </li></ul><ul><ul><li>Work to be done </li></ul></ul><ul><ul><li>Resources with which to do it </li></ul></ul><ul><ul><li>Money to pay for it </li></ul></ul><ul><li>Resources needed for software development: </li></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Hardware </li></ul></ul><ul><ul><li>Support software </li></ul></ul>
  52. 52. Use of Resources Varies with Time <ul><li>Rayleigh curves accurately depict resource consumption </li></ul><ul><li>Entire software development plan must be a function of time </li></ul>
  53. 53. Work Categories <ul><li>Project function </li></ul><ul><ul><li>Work carried on throughout project </li></ul></ul><ul><ul><li>Examples: </li></ul></ul><ul><ul><li>project management, quality control </li></ul></ul><ul><li>Activity </li></ul><ul><ul><li>Work that relates to a specific phase </li></ul></ul><ul><ul><li>Major unit of work </li></ul></ul><ul><ul><li>With precise beginning and ending dates </li></ul></ul><ul><ul><li>That consumes resources , and </li></ul></ul><ul><ul><li>Results in work products like budget, design, schedules, source code, or users’ manual </li></ul></ul><ul><li>Task </li></ul><ul><ul><li>An activity comprises a set of tasks (the smallest unit of work subject to management accountability) </li></ul></ul>
  54. 54. Completion of Work Products <ul><li>Milestone: Date on which the work product is to be completed </li></ul><ul><li>It must first pass reviews performed by </li></ul><ul><ul><li>Fellow team members </li></ul></ul><ul><ul><li>Management </li></ul></ul><ul><ul><li>Client </li></ul></ul><ul><li>Once the work product has been reviewed and agreed upon, it becomes a baseline </li></ul>
  55. 55. Work Package <ul><li>Work product, plus </li></ul><ul><ul><li>Staffing requirements </li></ul></ul><ul><ul><li>Duration </li></ul></ul><ul><ul><li>Resources </li></ul></ul><ul><ul><li>Name of responsible individual </li></ul></ul><ul><ul><li>Acceptance criteria for work product </li></ul></ul><ul><li>Money </li></ul><ul><ul><li>Vital component of plan </li></ul></ul><ul><ul><li>Detailed budget must be worked out as a function of time </li></ul></ul><ul><ul><li>Money must be allocated, as function of time, to </li></ul></ul><ul><ul><ul><li>Project functions </li></ul></ul></ul><ul><ul><ul><li>Activities </li></ul></ul></ul>
  56. 56. How to Plan Software Development <ul><li>State problem clearly (Specification Phase) </li></ul><ul><li>Determine viable solution strategies (Specification Phase) </li></ul><ul><li>Should client be advised to computerize? </li></ul><ul><ul><li>Cost–benefit analysis </li></ul></ul><ul><li>If so, which viable solution strategy? Decide by </li></ul><ul><ul><li>Minimizing total cost to client, or </li></ul></ul><ul><ul><li>Maximizing total return on investments, or </li></ul></ul><ul><ul><li>Other methods </li></ul></ul><ul><li>Develop SPMP for product as whole </li></ul>
  57. 57. Software Project Management Plan (SPMP) <ul><li>Determine work units </li></ul><ul><li>Estimate resources required </li></ul><ul><li>Draw up budget </li></ul><ul><li>Come up with detailed timetable </li></ul><ul><li>Framework for SPMP </li></ul><ul><ul><li>IEEE Standard 1058.1 </li></ul></ul><ul><ul><ul><li>Standard widely agreed upon </li></ul></ul></ul><ul><ul><ul><li>Designed for use with all types of software product </li></ul></ul></ul><ul><ul><ul><li>Advantages of standardization </li></ul></ul></ul>
  58. 58. IEEE SPMP
  59. 59. Planning of Testing <ul><li>SPMP must explicitly state what testing is to be done </li></ul><ul><ul><li>Traceability </li></ul></ul><ul><ul><li>All black box test cases must be drawn up as soon as possible after specifications are complete </li></ul></ul><ul><li>Testing during the Planning Phase </li></ul><ul><ul><li>Must check SPMP as a whole </li></ul></ul><ul><ul><li>Pay particular attention to duration and cost estimates </li></ul></ul>
  60. 60. Planning of Object-Oriented Projects <ul><li>Object-oriented product consists of largely independent pieces </li></ul><ul><li>Planning is somewhat easier </li></ul><ul><li>Whole is more than the sum of its parts </li></ul><ul><li>Use COCOMO II ( or modify intermediate COCOMO estimators) </li></ul><ul><li>However, reuse destroys everything </li></ul><ul><ul><li>Reuse of existing components during development </li></ul></ul><ul><ul><li>Production of components for future reuse </li></ul></ul><ul><li>These work in opposite directions </li></ul><ul><li>Newer data: savings outweigh costs </li></ul>
  61. 61. Training Requirements <ul><li>“ We don’t need to worry about training until the product is finished, and then we can train the user ” </li></ul><ul><ul><li>Training is generally needed by the members of the development group, starting with training in software planning </li></ul></ul><ul><ul><li>New software development method necessitates training for every member of the group </li></ul></ul><ul><ul><li>Introduction of hardware or software tools of any sort necessitates training </li></ul></ul><ul><ul><li>Programmers may need training in the operating system, implementation language </li></ul></ul><ul><ul><li>Documentation preparation training may be needed </li></ul></ul><ul><ul><li>Computer operators require training </li></ul></ul>
  62. 62. Documentation Standards <ul><li>How much documentation is generated by a product? </li></ul><ul><ul><li>IBM internal commercial product (50 KDSI) </li></ul></ul><ul><ul><ul><li>28 pages of documentation per KDSI </li></ul></ul></ul><ul><ul><li>Commercial software product of same size </li></ul></ul><ul><ul><ul><li>66 pages per KDSI </li></ul></ul></ul><ul><ul><li>IMS/360 Version 2.3 (about 166 KDSI) </li></ul></ul><ul><ul><ul><li>157 pages of documentation per KDSI </li></ul></ul></ul><ul><ul><li>(TRW) For every 100 hours spent on coding activities, 150–200 hours were spent on documentation-related activities </li></ul></ul>
  63. 63. Types of Documentation <ul><li>Planning </li></ul><ul><li>Control </li></ul><ul><li>Financial </li></ul><ul><li>Technical </li></ul><ul><li>Source code </li></ul><ul><li>Comments within source code </li></ul>
  64. 64. Documentation Standards <ul><li>Reduce misunderstandings between team members </li></ul><ul><li>Aid SQA </li></ul><ul><li>Only new employees have to learn standards </li></ul><ul><li>Standards assist maintenance programmers </li></ul><ul><li>Standardization is important for user manuals </li></ul>
  65. 65. CASE Tools for the Planning Phase <ul><li>Word processor, spreadsheet </li></ul><ul><li>Automated intermediate COCOMO/COCOMO II </li></ul><ul><li>Management tools assist with planning and monitoring </li></ul><ul><ul><li>MacProject, Microsoft Project </li></ul></ul>
  66. 66. Software Project Management - the Big Picture <ul><li>For a broader coverage of the other aspects of software project management refer to “ Software Project Management ” (Version 2 Handout); the contents of which are as follows: </li></ul><ul><ul><li>Project Planning and Management (Slide 3-38) </li></ul></ul><ul><ul><li>Managing People (Slide 39-89) </li></ul></ul><ul><ul><li>Software Cost Estimation (Slide 90-147) </li></ul></ul><ul><ul><li>Quality Management (Slide 148-201) </li></ul></ul><ul><ul><li>Process Improvement (Slide 202-235) </li></ul></ul><ul><ul><li>Legacy Systems (Slide 236-273) </li></ul></ul><ul><ul><li>Software Change (Slide 274-312) </li></ul></ul><ul><ul><li>Software Re-engineering (Slide 313-348) </li></ul></ul><ul><ul><li>Configuration Management (Slide 349-400) </li></ul></ul><ul><li>Exercise 5: An as exercise, go though the presentation and take note of the key points. </li></ul>