1 / 53

Lecture topics

Lecture topics. Software project management XP. The P 3 formula of software development success. People Competence Dedication Training Problem Scope and objectives Cost and deadlines Risks Process discussed. P 3 = People  Problem  Process. Human players in a software project.

stevenmcdonald
Télécharger la présentation

Lecture topics

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. 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

More Related