Software Engineering Jim Murphy CSCI-112 Fall 2001 LESSON 10 To manage projects we need to be able to estimate its size and how long it will take, choose the teams to work on it (staffing), estimate how much it will cost, schedule the various phases (planning), monitor its progress, recognize milestones and missed milestones (tracking), keep everyone working together, deliver on time a quality product that meets all of its requirements. If you do not want to spend all your time managing crisis then you must spend your time avoiding them - failed projects tend to have weak or no management Quantitative approaches are on the increase for cost estimation, cost modeling and cost analysis - these models tend to be within 20% of being accurate 80% of the time. Much of planning and scheduling involves estimation - of complexity of the product, of individual engineers productivity and availability of people Think of management as the art of getting work done through other people People are the most important resource to be managed (then focus on problem and process) The best developers might be 4 to 10 times as productive as the average but they make up only 1 or 2 percent of all developers The worst engineers could even lower the productivity of the team yet some managers think of software engineers as interchangeable Some work best under centrally controlled teams while others work better in a more democratic setting How fast can you really add people to a project that is in trouble when bringing the new people up to speed will take away from your current people for training The people involved include: Senior managers (high level business issues) Project managers (motivate and organize practitioners) Practitioners (worker bees) Customers (specify requirements and pay the bills) End users (at the keyboard) Teams can be controlled in a centralized way, decentralized way, can even be democratic - Table 3.1 on page 63 shows various situations in which each approach has an advantage. As projects become larger coordination and communication require more attention or they too will become a source of difficulty causing eventual failure You may find maintaining all of your project information on four web sites linked together to be of some help in this Each person can then view the latest changes by each contributor and does not have to wait until the next meeting to be brought up to date Quantitative estimates and a plan need to be formulated early in the project - that is, even prior to analysis (how many people need to be on the analysis team for example?) To do this we need at least something equivalent to a context diagram - that is determine the scope of the problem to include Context - how does our project fit into the larger system Information objectives - what data comes in and what goes out Function and Performance - What transformations must occur between input and output and are there any constraints on time Some preliminary partitioning of the problem may also be necessary to make any progress on early estimates At this same early stage a particular process model can be chosen A Common Process Framework (CPF) might include: Customer communication Planning Risk Analysis Engineering Construction and Release Customer Evaluation Where each function of the project must pass through each CPF activity above and so a matrix such as that shown on page 70 could be constructed with major functions to be delivered are listed down the left side with CPF activities across the top Each cell in the matrix can then be filled in with resource estimates with start and end dates for each task The number of tasks in each CPF category might vary and the categories themselves would be quite different from one company to another but within a working group would stay fairly constant from project to project while the major functions would change between projects - but these could also be things like first level prototype, second level prototype etc. Measures, Metrics and Indicators The only way we are going to be able to make any decent early quantitative estimates is to have gathered a good deal of data on previous projects where the more similar the work and workers to the current project the better the estimate will be Attributes of a project to be measured can include size of the project, errors found per person hour prior to release and defects found after release, person hours spent on various tasks Indicators can be calculated based on a number of measurements which can provide insight into the project or process We are primarily interested in measuring productivity and quality Process indicators such as person hours per thousand lines of code can be used over long periods of time to assess any supposed software process improvement as we change methodologies or management strategies or practices - of course there will usually not just be one thing changing at any given time but rather we will have simultaneous changes in product type, people on our teams, development environment, business conditions and on and on - but it will still be easier to determine improvements with quantitative measurements than it would be without them Humphrey suggests keeping private personal metrics on errors and productivity with a Personal Software Process PSP Even keeping just a notebook of your own metrics can be helpful A team may also want to keep records which are available only to the teams members - summary information from individuals and teams can then become public information - a bit the way we share statistical information about people without revealing who it applies to in particular - next what do we measure?