530 likes | 558 Views
Explore key software project management topics, from XP to the P3 formula of success, covering team roles, human resource allocation, project planning, estimation methods, and reusable components. Dive into team organization types and see how to effectively plan and estimate resources for successful software development projects.
E N D
Lecture topics • Software project management • XP
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
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
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
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
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
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
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
What is an estimate? • Estimated resource • Time requirements • Personnel requirements • Cost • Involves considering multiple scenarios • Worst case • Best case • Estimated average
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Project plan structure • Introduction • Project organisation • Risk analysis • Hardware and software resource requirements • Work breakdown • Project schedule • Monitoring and reporting mechanisms
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
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
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
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
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
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”
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?
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
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
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