Managing Software Projects: Principles and Team Organization

1. Lecture topics • Software project management • XP

2. The P3 formula of software development success • People • Competence • Dedication • Training • Problem • Scope and objectives • Cost and deadlines • Risks • Process • discussed P3 = People  Problem  Process

3. Human players in a software project • Senior managers • Define the business policies, make high-level decisions • Technical managers • Plan, organize, and control software projects • Practitioners • Carry out software development • Customers • Define requirements • End users • Use the software once it is released

4. Is managing easy? • A good manager should be able to • Encourage creativity • And provide ideas too • Organize • Choose the right software process model • Assemble teams • Balance control and freedom • Resolve conflicts and tensions • Understand abilities, strengths, and weaknesses • Errors are unavoidable • “In engineering, experience gained is directly proportional to the amount of equipment ruined” Stephen Baxter, Manifold Time

5. Human resource allocation for software development • Personal assignments • A manager assigns one or more tasks to each person • Relatively little communication among individuals • Informal teams • People work together on some tasks • Informal team leaders • The manager provides team coordination • Formal teams • Teams have well-defined structure • Coordination done both by teams and the manager

6. Generic team organization types • Democratic decentralized (DD) • No permanent leader • Task coordinators may be assigned • Decisions made by the group consensus • Controlled decentralized (CD) • A defined team leader • Also possibly secondary leaders • Team task is partitioned into subtasks by the leader • Controlled centralized (CC) • A defined team leader • Rigid hierarchy and task assignment

7. How should I organize my team? • The problem to be solved is very difficult, but its size is relatively small • DD • The problem size is very large • CD or CC • The team lifetime is very long • CD or CC • The problem is modular • CD or CC • The software system has to be highly reliable • DD or CD • The delivery date is very rigid • CC • High degree of communication required • DD

8. Software project planning • Important to do • Provides crucial estimates • Effort involved (person-months) • Time required • Cost • Evaluates potential risks • Hard to do • Predicting is always hard • Software complexity and uniqueness makes it even harder • E.g. compare to civil engineering • Plans may (and usually do) change

9. What is an estimate? • Estimated resource • Time requirements • Personnel requirements • Cost • Involves considering multiple scenarios • Worst case • Best case • Estimated average

10. Planning for human resources • Has to be done after the initial requirements stage • Identify required skills • Technical • Managerial • Identify the amount of human resources required • Per skill • Per stage of the project

11. Reusable software components • Off-the shelf components • Do not need modifications • The rule of thumb is, use whenever possible • Full experience components • Software from past projects that requires little modification • In most cases, good idea to use it • Partial experience components • Software from past projects that requires significant modification • Has to be evaluated carefully before being used • New components • Built from scratch • Can be outsourced

12. Ways of doing software project estimation • No estimation • “Whenever we are done, you’ll pay our costs and 20% extra” • Use experience from previous project • May work if the previous projects are quite similar to the current • But even subtle differences can play havoc with estimates • Use empirical models for estimation • Those from the last lecture • Use decomposition techniques • Do estimation for subsystems • Could be combined with using experience from previous projects and empirical models

13. LOC (or FP) -based estimation • Modules of the project are estimated separately • Estimate the LOC (FP) for each module • The known organization productivity metric LOC/person-months (FP/person-months) is used to estimate effort • E.g. the size of module M is estimated 30,000 LOC. On average, on similar projects, the organization produces 500 LOC per person per month. The effort is estimated as 30,000 / 500 = 60 person-months • An expected value of of the estimate is computed • EV(size) = (Sopt + 4Sml + Spess)/6 • Soptis optimistic estimate, Sml is the most likely estimate, is pessimistic estimate • Coefficients (1, 4, 1 before Sopt,Sml,Spess respectively) may vary

14. Example: required resources for Scheduler, LOC-based estimation • Module sizes, in LOC (optimistic, most likely, pessimistic) • PersistentStorage (2000, 3000, 4000) • Calendar (1300, 2100, 2300) • Dayplan (13000, 15000, 17000) • PerformanceView (13000, 21000, 23000) • Task and Timing (4000, 5000, 6000) • The company’s average productivity on similar projects: 1000 LOC/person-month • Average cost of 1 person-month is $12,000

15. Example: required resources for Scheduler, process-based estimation • General process activities (estimated time in person-months) • Communication with customers: 1.5 • Requirements specification: 4 • Testing: 10 • Process activities per module (PersistentStorage, Calendar, DayPlan, PerformanceView, Task and Timing) estimated time in person-months • System design: 0.5, 0.5, 0.3, 1.2, 1 • Object-level design: 1.2, 1, 0.8, 2, 2 • Coding: 0.5, 0.5, 0.5, 1.5, 1 • Module testing: 1, 1, 0.8, 2.5, 2.2 • Average cost of 1 person-month is $12,000

16. Risk management • Project risks are things that can potentially go wrong with a software project • E.g. risk of going over budget • A risk that comes true is a materialized risk • Risk management involves activities dealing with reducing likelihood and severity of risks • Risk identification • Risk estimation • Risk avoidance and monitoring

17. General types of risks • Project risks • Negatively impact the project plan • Increase costs • Throw off the schedule • Technical risks • Negatively impact the quality and functionality of the project • Complicate development and may lead to project termination • Business risks • Negatively impact the economical viability of the product • A wide variety of managerial, budgetary, market, and strategic risks

18. Risk identification • The task of describing some of the project risks • Have to guess as many risks as possible • Known risks are those that can be obtained from the careful examination of the project plan • Predictable risks are those that can be obtained from the experience of previous projects • Two general subcategories for each risk category: • Generic risks • Common for all projects • E.g. market risk is often a reality • Product-specific risks • Cutting edge products often involve technology risks

19. Examples of risks related to product size • Estimated code size is significantly larger (smaller) than the size of previous comparable projects • Amount of memory required for the product to run is too large • Amount of reused software in the project is very large • Degree of confidence in the size estimate is low

20. Examples of business impact risks • The project is not strategically important for the company • The product would have a lot of competition on the market • The number of potential users is too low • The proposed deadline may not be feasible

21. Examples of customer related risks • The customer’s technological sophistication may not be sufficient to understand and use the product • The customer does not have a complete set of requirements • The company did not work with the customer in the past • The customer may not be willing to participate in meetings in the course of the project

22. Examples of process risks • Software process is not well defined on the organization level • The project members are far from enthusiastic about using process • The process does (does not) incorporate: • Technical reviews • Configuration management • Methods for generation of test suites • Regression testing • Software tools are not used for process support • Process does not incorporate metric collection

23. Examples of technology risks • The technology required for the project is new • May not be a new technology per se, just new for the organization • The product has to interact with new software or hardware technologies • Specific requirements exist that force the use of specialized (untried by the organization) process activities • Performance constraints on the product are excessive • The customer insists on using outdated technology

24. Examples of development environment risks • Process and project management tools are not available • Available compilers are not suitable for the product requirements • Requirements and design tools are not available • Configuration management tools are not available • Testing tools are not available • Project members are not trained in the use of necessary tools

25. Examples of staff size and experience risks • Available personnel do not have the necessary skills • There are not enough people to finish the project on time • The expected staff turnover is high • A large portion of staff are inexperienced in the projects of this type

26. Risk estimation • Done once all risks are identified • Estimates for each of the identified risks • The likelihood that the risk will materialize • Risk impact: consequences of the risk materialization • Based on these estimates, the risks are rated and managed

27. Risk impact • Four categories • Catastrophic • Results in project termination • Critical • The project may deliver not fully functional product • The resulting product may be difficult to maintain • The project may be over the budget and off schedule • Marginal • Minor negative effects on the project cost and schedule and the product performance and maintainability • Negligible • These risks can generally be ignored

28. Risk assessment • Prioritize risks • By the likelihood • By the impact • Re-examine the accuracy of risk estimation • Determine the risks that have to be managed • Some risks are not significant enough, so they are ignored • Define risk break points for managed risks • Points at which the decision has to be made whether to proceed with the project or terminate it • Combine risk break pint values for different risks into a termination decision framework

29. Risk avoidance, monitoring, and management • Risk avoidance • Mostly based on common sense • E.g. if risk of insufficient technical skills of programmers is present, train them ahead of time • Risk monitoring • Estimate whether the risk is becoming more or less likely as the project proceeds • E.g. an increased rate of errors uncovered by formal design reviews may be an indication that the risk of insufficient technical skills grows • Monitor the effectiveness of risk avoidance activities • Risk management • Assumes that risk materialized • E.g. if the programmers do not know how to implement a part of the project, hire some experts

30. How much risk management? • Risk management is costly • Time taken by risk identification, estimation, and monitoring • Some risk avoidance activities may be costly • E.g. have an “alternate” for each team member • Non-critical and non-catastrophic risks may have to be ignored to save time • Pareto rule: 80% of the probability of the project failure depends on 20% of the risks

31. Project scheduling • The main goal is to prevent the project from being delivered late • Customer may need the product by a certain date • The faster the organization is done with this project, the sooner it goes to the next one • Having a schedule lets software managers: • Created detailed plans for the project • Track the progress of the project • Notice timing problems early • So steps to fix the problems can be taken early

32. What delays a project? • Unrealistic deadlines • Change in requirements • Overly optimistic planning and allocation of resources • Inadequate risk avoidance and management procedures • Unpredictable risks • Lack of understanding from higher-ups

33. Project scheduling: a top-down approach • Create a macroscopic (general) schedule • Schedule the major activities (steps of the software process) • Create a microscopic (detailed) schedule • For each major activity, schedule tasks that comprise it • Good decomposition into tasks is essential! • The macroscopic schedule may be adjusted based on the microscopic schedule

34. Project plan structure • Introduction • Project organisation • Risk analysis • Hardware and software resource requirements • Work breakdown • Project schedule • Monitoring and reporting mechanisms

35. Activity organization • Activities in a project should be organised to produce tangible outputs for management to judge progress • Milestones are the end-point of a process activity • Deliverables are project results delivered to customers • The waterfall process allows for the straightforward definition of progress milestones

36. Milestones in the RE process

37. Project scheduling • Split project into tasks and estimate time and resources required to complete each task • Organize tasks concurrently to make optimal use of workforce • Minimize task dependencies to avoid delays caused by one task waiting for another to complete • Dependent on project managers intuition and experience

38. The project scheduling process

39. Scheduling problems • Estimating the difficulty of problems and hence the cost of developing a solution is hard • Productivity is not proportional to the number of people working on a task • Adding people to a late project may make it later because of communication overheads • The unexpected always happens. Always allow contingency in planning

40. Bar charts and activity networks • Graphical notations used to illustrate the project schedule • Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two • Activity charts show task dependencies and the the critical path • Bar charts show schedule against calendar time

41. Task durations and dependencies

42. Activity network

43. Activity timeline

44. Staff allocation

45. So what do we do with schedules? • Schedule tracking includes procedures for ensuring that the project stays on schedule • Tracking time and effort spent on each task • Tracking the milestones • Getting input from team members about possible problems • If the project falls behind schedule, corrective steps are taken • Increased control over the project • Additional human resources requested • Careful there! • Overtime • Extension of deadlines • Delivery of the product in increments

46. eXtreme Programming (XP) • Inventors/promoters: • Kent Beck • Chris Collins • Roy Miller • … • An agile approach to software development • What does agile mean? • Roy Miller: “…balances all the forces to develop software intelligently” • Why is it “extreme”? • Roy Miller: “XP takes proven industry best practices and turns the knobs up to 10” • Roy Miller: “XP combines those practices … to produce something greater than the sum of the parts”

47. XP values • The ideas behind XP are based on four high-level values: • Communication • Promotes communication among all members of the development team • Simplicity • Always do the simplest thing that gets the job done • Feedback • Most important decisions are based on the feedback from the customers • Courage • In the context of the other three • It takes courage to communicate?

48. XP practices • XP is defined by 19 practices, separated into four categories: • Joint practices • Apply to all members of the team • Programmer practices • Management practices • Customer practices

49. Joint practices • Common vocabulary • Everybody uses the same terminology • Open workspace (in short, no cubicles) • Promotes communication • Does this work for large teams? • Iterations • Planning (iteration planning meeting) • Coding/testing • User acceptance testing • Retrospectives • Discuss lessons learned

50. Programmer practices • Test-first development • Write tests before writing code • Pair programming • One person looks over the shoulder of the other, jumps in with suggestions • Can switch roles • Refactoring • Improving the design of the existing code • Collective ownership • Anybody can change anything • Everybody is responsible for everything • Continuous integration • Nightly builds • YAGNI (You Aren’t Gonna Need It) • Means simple design