Adaptive Software Engineering G22.3033-007 Session 12 - Main Theme Risk Management in Software Engineering Projects Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Agenda Review Project Planning and Estimation Cooperative Roles of Software Engineering and Project Management Developing Risk Response Strategies Risk Management in Agile Processes Agile Project Planning Summary Project (Part 4) - ongoing 2
Summary of Previous Session Review Testing, Verification, and Validaton Integration and System Testing Static Confirmation Dynamic Testing Traceability Matrices Automated Testing Configuration Management Software Quality Software Quality Assurance (SQA) Project Measurements Software Quality and Agile Methods Project Management Metrics Quality and Process Standards and Guidelines Summary Project (Part 4) - ongoing 3 Part I Project Planning and Estimation (Adapted from Chapter 4 of Ian Sommerville 2000 Software Engineering, 6th edition) 4
Project Management Project management scope: organization, planning and scheduling of software projects 5 Section Objectives To introduce software project management and to describe its distinctive characteristics To discuss project planning and the planning process To show how graphical schedule representations are used by project management To discuss the notion of risks and the risk management process 6
Topics Covered Management activities Project planning Project scheduling Risk management 7 Software Project Management Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software 8
Software Management Distinctions The product is intangible The product is uniquely flexible Software engineering is not recognized as an engineering discipline with the same status as mechanical, electrical engineering, etc. The software development process is not standardized Many software projects are 'one-off' projects 9 Management Activities Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel selection and evaluation Report writing and presentations 10
Management Commonalities These activities are not peculiar to software management Many techniques of engineering project management are equally applicable to software project management Technically complex engineering systems tend to suffer from the same problems as software systems 11 Project Staffing May not be possible to appoint the ideal people to work on a project Project budget may not allow for the use of highlypaid staff Staff with the appropriate experience may not be available An organization may wish to develop employee skills on a software project Managers have to work within these constraints especially when (as is currently the case) there is an international shortage 12 of skilled IT staff
Project Planning Probably the most time-consuming project management activity Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget 13 Types of Project Plan Plan Description Quality plan Describes the quality procedures and standards that will be used in a project. Validation plan Describes the approach, resources and schedule used for system validation. Configuration management plan Describes the configuration management procedures and structures to be used. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development plan. Describes how the skills and experience of the project team members will be developed. 14
Project Planning Process Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverables while project has not been completed or cancelled loop Draw up project schedule Initiate activities according to schedule Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end if end loop 15 Project Plan Structure Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms 16
Activity Organization Activities in a project should be organized 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 17 Milestones in the RE process ACTIVITIES Feasibility study Requirements analysis Prototype development Design study Requirements specification Feasibility report Requirements definition Evaluation report Architectural design Requirements specification MILESTONES 18
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 19 The Project Scheduling Process Identify activities Identify activity dependencies Estimate resources for activities Allocate people to activities Create project charts Software requirements Activity charts and bar charts 20
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 makes it later because of communication overheads The unexpected always happens. Always allow contingency in planning 21 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 critical path Bar charts show schedule against calendar time 22
Task Durations and Dependencies Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) 23 Activity network 4/7/99 start 8 days T1 15 days T2 14/7/99 15 days M1 T3 5 days 25/7/99 T6 M3 20 days T7 4/8/99 M4 15 days T9 25/8/99 M6 7 days T11 10 days T4 25/7/99 M2 18/7/99 M5 10 days T5 11/8/99 M7 15 days T10 5/9/99 M8 10 days T12 25 days T8 Finish 19/9/99 24
Activity timeline 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T1 T2 Start M1 T7 T3 M5 T8 M3 M2 T6 T5 T9 M4 M7 T10 T11 T12 M6 M8 Finish 25 Staff allocation 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Fred T4 T8 T11 T12 Jane T1 T3 T9 Anne T2 T6 T10 Jim T7 Mary T5 26
Risk management Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project. A risk is a probability that some adverse circumstance will occur. Project risks affect schedule or resources Product risks affect the quality or performance of the software being developed Business risks affect the organization developing or procuring the software 27 Software risks Risk Risk type Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organizational management with different priorities. Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule. Requirements change Specification delays Size underestimate Project and product Project and product Project and product Product There will be a larger number of changes to the requirements than anticipated. Specifications of essential interfaces are not available on schedule The size of the system has been underestimated. CASE tools which support the project do not perform as anticipated CASE tool underperformance Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed. 28
The Risk Management Process Risk identification Identify project, product and business risks Risk analysis Assess the likelihood and consequences of these risks Risk planning Draw up plans to avoid or minimize the effects of the risk Risk monitoring Monitor the risks throughout the project 29 The Risk Management Process Risk identification Risk analysis Risk planning Risk monitoring List of potential risks Prioritised risk list Risk avoidance and contingency plans Risk assessment 30
Risk Identification Technology risks People risks Organizational risks Requirements risks Estimation risks 31 Risks and Risk Types Risk type Technology People Organizational Tools Requirements Estimation Possible risks The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality. It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. The organization is restructured so that different management are responsible for the project. Organizational financial problems force reductions in the project budget. The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes. The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated. 32
Risk Analysis Assess probability and seriousness of each risk Probability may be very low, low, moderate, high or very high Risk effects might be catastrophic, serious, tolerable or insignificant 33 Risk Analysis Risk Probability Effects Organizational financial problems force reductions in the Low Catastrophic project budget. It is impossible to recruit staff with the skills required for the High Catastrophic project. Key staff are ill at critical times in the project. Moderate Serious Software components which should be reused contain Moderate Serious defects which limit their functionality. Changes to requirements which require major design rework are proposed. Moderate Serious The organization is restructured so that different High Serious management are responsible for the project. The database used in the system cannot process as many Moderate Serious transactions per second as expected. The time required to develop the software is underestimated. High Serious CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of requirements Moderate Tolerable changes. Required training for staff is not available. Moderate Tolerable The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant 34
Risk Planning Consider each risk and develop a strategy to manage that risk Avoidance strategies The probability that the risk will arise is reduced Minimization strategies The impact of the risk on the project or product will be reduced Contingency plans If the risk arises, contingency plans are plans to deal with that risk 35 Risk Management Strategies Risk Organizational financial problems Recruitment problems Staff illness Defective components Requirements changes Organizational restructuring Database performance Underestimated development time Strategy Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Alert customer of potential difficulties and the possibility of delays, investigate buying-in components. Reorganize team so that there is more overlap of work and people therefore understand each other s jobs. Replace potentially defective components with bought-in components of known reliability. Derive traceability information to assess requirements change impact, maximize information hiding in the design. Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Investigate the possibility of buying a higher-performance database. Investigate buying in components, investigate use of a program generator. 36
Risk Monitoring Assess each identified risks regularly to decide whether or not it is becoming less or more probable Also assess whether the effects of the risk have changed Each key risk should be discussed at management progress meetings 37 Risk Factors Risk type Technology People Organizational Tools Requirements Estimation Potential indicators Late delivery of hardware or support software, many reported technology problems Poor staff morale, poor relationships amongst team member, job availability organisational gossip, lack of action by senior management reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations many requirements change requests, customer complaints failure to meet agreed schedule, failure to clear reported defects 38
Key Points Good project management is essential for project success The intangible nature of software causes problems for management Managers have diverse roles but their most significant activities are planning, estimating and scheduling Planning and estimating are iterative processes which continue throughout the course of a project 39 Key Points (continued) A project milestone is a predictable state where some formal report of progress is presented to management. Risks may be project risks, product risks or business risks Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats 40
Part II Cooperative Roles of Software Engineering and Project Management See: http://www.usenix.org/events/usenix-win2000/invitedtalks/34 (Windows A Software Engineering Odyssey) 41 Projects Launching Guidelines 42
Project Launching Guidelines (continued) Project Plan Contents: Project Organization (life cycle model, team model, roles,...) Managerial Process (assumptions, dependencies, constraints, risk approach, reporting & reviews, staffing approach) Technical Process (methods, tools, techniques, work product being built, reviews of products, and record collection) Work Items, Schedule, & Budget (Work Breakdown Structure (WBS), resource requirements, budget, schedule) Keep plan alive The project plan is NOT shelfware, revisit and update it at regular intervals during project 43 Project Management Goals Software delivered within budget Software delivered within schedule Software is built according to requirements Why? Well-managed projects sometimes fail Badly managed projects inevitably fail Software development process is not standardized 44
Project Manager Responsibilities Proposal Writing Project Costing Project Planning & Scheduling Project Monitoring & Reviews Personnel Selection & Evaluation Report Writing & Presentations 45 Project Planning Process Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverables while project has not been completed or cancelled loop Draw up project schedule Initiate activities according to schedule Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end if end loop 46
So How Do We Do This? Spend time understanding the problem Estimate amount of effort required Number of major functions Difficulty of each function Develop schedule with built in safety nets Increase estimates by some factor Have a backup plan for worst case Make sure schedule is realistic Revise schedule as project understanding increases 47 Estimation Overview Difficult & error prone Gradual refinement At beginning of project, have a fuzzy idea of problem, therefore estimate of time and effort will be fuzzy too Only as the project develops and the problem and solution become clearer, will the estimates increase in accuracy Estimation Process Estimate the size of the product Lines of code (LOC) Function Points Number of functions Estimate the effort Person-months Estimate the schedule Calendar time 48
From Estimation to Scheduling Refinement Initial problem statement Requirements Specification High Level Design Detailed Design Specification Implementation Cases Best Case Most Likely Case Current Case Worst Case 49 Scheduling Activities Split project into tasks Estimate time & resources required Organize tasks concurrently to make optimal use of workforce Minimize task dependencies to avoid delays Problems Estimating is difficult Productivity is not proportional to the number of people Adding people to a late project makes it later The unexpected always happens - allow contingency 50
Scheduling Derived from estimated level of effort required Build in mid-project checkpoints Don t forget testing & integration take time too Be realistic Other classes Outside work/activities Eat& sleep Build in safety nets & backup plans 51 Project Plan Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Milestones - end of process activity Deliverables - project results delivered to customer Project schedule Monitoring and reporting mechanisms 52
In Summary... Good project management is essential for project success Managers have diverse roles, but focus on Planning Estimating Scheduling Planning and estimating are iterative processes 53 Part III Developing Risk Response Strategies See: http://alistair.cockburn.us/crystal/talks/apms1/advancedpmstrategies1-180.ppt 54
Part IV Risk Management in Agile Processes See: http://alistair.cockburn.us/topicalindex.htm (management topics) The Role of the Manager in Modern Agile Projects 55 PM Skills Needed Traditional engineering skills: plan, analyse, design, build, test, install etc. Understand the importance of documenting and signing off the analysis and design before building/coding. Prior Experience: Does this approach match the real world? Is this idea universally applicable? Are there valid alternatives? 56
Extreme Programming (XP) One of a group of agile methods. Created to handle problem domains whose requirements change: Customers may not have a firm idea of what the required system should do. Indeed the system's functionality may be expected to change every few months. In many software environments, dynamically changing requirements is the only constant. 57 Extreme Programming (XP) (continued) XP emphasises team work. The method encourages four values: communication; simplicity; feedback; and courage. Note: XP is as an example of agile methods. Some of XP s effects on project management are shared by DSDM, SCRUM etc. 58
XP Challenges Assumptions XP says that analogies between software engineering and other engineering are false: Software customers requirements change more frequently; Products can be changed more easily; The ratio of design cost/build cost is much higher if we consider coding as design and compile-link as build : the build task is so quick and cheap it should be considered instant and free, almost all software development is design. 59
How XP works As with RAD and DSDM etc. programmers meet and communicate with customers regularly, and the software gets released incrementally. Programmers always work in pairs (considered more productive). 61 How XP works (continued) Important to PM Testing is the start point, not the end: For each user story, the customer first writes an acceptance test. For each unit the programmer writes a set of unit tests. Then each unit in a story is coded. When a unit is ready, its tests are run automatically. Customers are allowed to suggest improvements. Redesigns are common they are part of refactoring - and handled easily. 62
What Effect Does XP Have On Project Management? Project scope XP embraces changes in requirements. There is little value in the traditional project scope that forms a contract for what functionality will be provided for a fixed cost/effort. Instead, the customer writes on cards a set of user stories that describe what they want the new application to do for them. 63 What Effect Does XP Have On Project Management? (continued) Task and project estimating The time (duration) to complete each user story is written on the relevant card. If the story will take more than 3 weeks, it must be split into two or more smaller stories. These stories are prioritized in a release plan; the plan sets out which stories that will be produced in each iteration. XP projects may have fixed time (scope varies) or fixed scope (time varies), but not both. 64
What Effect Does XP Have On Project Management? (continued) Quality management For each user story the customer must write an acceptance test. These are produced before any software is written to satisfy the story. Acceptance tests are normally automated so they can be used as regression tests each time the software is changed. Programmers always work in pairs to ensure learning, adherence to standards, and avoidance of errors. 65 What Effect Does XP Have On Project Management? (continued) Progress monitoring Progress monitoring can be as simple as keeping a track of which story cards have been marked as completed (passed its acceptance test). The XP concept project velocity (the speed at which the developers are producing work) prevents unwarranted optimism! E.g., The first task took too long, so I expect the other tasks will be done more quickly than 66 expected. X X
What Effect Does XP Have On Project Management? (continued) Change control XP is intended for environments where requirements are expected to change several times before the project is over. As new user stories are programmed, changes to existing work may be needed. XP developers put a lot of effort into improving code and keeping it as simple as possible (refactoring). Constant refactoring necessitates regression testing of all affected modules. This reinforces the need for automated testing (see Quality Management above). 67 Are we building the software right? Are we building the right software? What effect does XP have on project management? (continued) Risk management Traditional software development focuses on reducing risk from software errors (verification) by having copious plans and procedures. XP focuses on reducing risk by ensuring customers' requirements are met (validation). Barry Boehm (2002) suggests that the best way to decide whether XP is suitable for a given project is to assess risk exposure. 68
Bibliography Agile Manifesto (2001) http://www.agilemanifesto.org/ Beck, K (1999) Extreme Programming Explained: Embrace Change, Addison-Wesley Boehm, B (2002) Get ready for agile methods, with care. IEEE Computer, January 2002 Wells J D (2002) Extreme Programming: A gentle introduction http://www.extremeprogramming.org/ 69 Part V Agile Project Planning 70
Requirements Specification Usage Scenarios Use Cases User Stories Others 71 Usage Scenarios Sequence of steps describing an interaction between user and system Typically focus on user interface Included in use cases, possibly appended to user stories 72
Use Case ID: short name Actor Precondition, trigger Success and failure end conditions Main scenario Extensions, variations Includes and included-by 73 How to Develop a Use Case Model (review) 1. Identify who is going to be using the system directly - e.g., hitting keys on the keyboard. These are the Actors. 2. Pick one of those Actors. Example: Sales Order Clerk 74
How to Develop a Use Case Model (review) 3. Define what that Actor wants to do with the system. Each of these things that the actor wants to do with the system become a Use Case. 4. For each of those Use Cases decide on the most usual sequence of steps when that Actor is using the system. What normally happens. This is the main scenario. 75 How to Develop a Use Case Model (review) 5. Describe that main scenario for the use case. Describe it as "Actor does something, system does something. Actor does something, system does something." Only describe things that the system does that the actor would be aware of and conversely you only describe what the actor does that the system would be aware of. 76
Main Scenario Example Enter a Sales Order 1. Sales Order Clerk enters the customer s last name. 2. System displays all matching customers. 3. Sales Order Clerk selects one of those customers. 4. System displays that customer s details. 5. For each item that the customer wishes to order, Sales Clerk enters the line details. 6. When all line items have been entered, System confirms the order. 77 How to Develop a Use Case Model (review) 6. Now consider the alternates and add those as extending use cases. Example: In use case Enter a Sales Order, 1. If System finds no customers matching the last name, System displays an error message. 2. System allows Sales Order Clerk to enter a different last name to search against. New Customer Not Found use case extends Enter a Sales Order use case 78
How to Develop a Use Case Model (review) 7.Review each Use Case description against the descriptions of the other Use Cases. Notice any glaring commonality? Extract those out as your common (included) Use Cases. 79 Another Main Scenario Example Credit Check a Customer 1. Sales Order Clerk enters the customer s last name. 2. System displays all matching customers. 3. Sales Order Clerk selects one of those customers. 4. System displays that customer s details. 5. System also displays customer s payment history for past six months. 80
Example Includes New Display Customer Details use case Enter a Sales Order use case includes Display Customer Details use case to lookup and display a customer s details. Credit Check a Customer use case includes Display Customer Details use case to lookup and display a customer s details. Note: Customer Not Found use case extends Display Customer Details use case 81 How to Develop a Use Case Model (review) 8. Repeat steps 2-7 for each Actor. Tips: Don t make use cases too small, limit decomposition into extending and included use cases Don t need to include all details, capture only functional requirements 82
User Stories Alistair Cockburn describes as a Use Case at 2 bits precision (goal, main scenario) Says Use Case typically 4 bits precision (failure conditions extends, modularity - includes) 83 Planning with Use Cases or User Stories Drive creation of acceptance tests Construction of engineering tasks Derivation of time estimates for release plan 84
Time Estimation Based on experience First iteration is guestimate from previous projects Second and later iterations consider velocity within this project Task breakdown Use cases or user stories may require development of underlying infrastructure, e.g., database Consider differences in task difficulty 85 XP Time Estimation XPers rate user stories as 1-3 Perfect Engineering Weeks If estimate is longer than 3 weeks for one story, break the story down into multiple stories If estimate is less than one week, combine stories Estimate only in weeks, not months 86
Ideal Development Time Usually w.r.t. one programmer, or one pair Time it would take to implement if there were no distractions, no other assignments, and you knew exactly what to do No phone calls to take, no meetings to attend, no questions to answer or get answered, no web surfing, 87 Time Estimation Problem Excellent accuracy estimating relative difficulty More experience -> more accuracy Compare to similar stories (or use cases) for existing code Very poor accuracy estimating elapsed time Interruptions, meetings, etc. Individual differences???? 88
Time Estimation Solution Time estimation is scary and difficult Therefore move as quickly as possible to estimating by comparison Story Estimation Units $s Points Estimate resources, estimate velocity Only then convert to time duration 89 Release Plan Meeting Managers, developers, and customers must be present Estimate how long it would take to complete each user story (or use case) Prioritize the stories (or use cases) in terms of importance Pick set of stories (or use cases) to be implemented for next release Developer team arranges into iterations 90
Release Plan 101 H 1 167 H 2 231 M 1 151 H 2 134 H 1 165 M 1 234 H 1 132 H 1 173 M 2 91 XPers Have Frequent Releases Frequent, small releases - each one with more and more functionality Critical in getting early feedback from customer Helps track total amount of work done during each release and the iterations leading up to that release Keeps customer happy Raises developer morale 92
XP Iterations Numerous iterations leading up to each release Each iteration is 1-3 weeks Things to be done in each iteration are planned out in detail just before that iteration User stories to be implemented in this iteration are called engineering tasks May include failed stories from previous iterations Developers sign up for the tasks Do not plan [further] ahead! 93 Iteration Planning About one-half day per iteration Select user stories (or use cases) to implement Developers Ask questions to clarify understanding Determine workflow and screenflow Create Engineering Tasks Estimate tasks (revise/refine user story or use case estimates) Sign up for tasks (promotes ownership) Balance load, get to work 94
Iteration Plan with Cards 101 H 1 167 H 2 231 M 1 151 H 2 134 H 1 165 M 1 234 H 1 132 H 1 173 M 2 95 Iteration Plan with Cards (after First Iteration) 101 H 1 167 H 2 231 H 1 151 H 2 134 M 1 165 M 1 234 H 1 132 H 1 173 M 2 96
Iteration Plan with Cards 101 H 1 167 H 2 231 H 1 151 H 2 134 M 1 165 M 1 234 H 1 132 H 1 173 M 2 97 Iteration Plan with Cards 101 H 1 167 H 2 134 M 1 151 H 2 231 H 1 165 M 1 234 H 1 132 H 1 173 M 2 98
Iteration Tracking XPers do approx. twice weekly Ask each developer, for each task: How much work did you get in on it How much work is there to go Note increasing estimates Possibly too complex, break down Note inability to get much time in Possibly too much overhead, reduce Feed forward into next iteration plan 99 Planning in XP Lifecycle 100
Relative Timing 101 XP Development 102
Other Approaches to Planning 103 Gantt Chart List tasks Graphically represent dependencies among tasks Show duration and time period of each task Heavily dependent on prediction regarding: Activities involved Effort and time required 104
Gantt chart example Programmer working on a small software project Explicit start time, end time, and duration (in days ) ID Task Name Start Fi nish Du ratio Dec 2002 n 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Requirement gathering 12/5/2002 12/6/2002 2d 2 Analysis 12/9/2002 12/9/2002 1d 3 Design 12/10/2002 12/11/2002 2d 4 Coding 12/12/2002 12/17/2002 4d 5 Testing 12/18/2002 12/31/2002 10d Explicit calendar bar 105 Pert chart Start time Alternative to Gantt chart Task Different perspective Focuses on dependencies more than calendar time No fixed format 12/5/2002 2 12/6/2002 Requirement gathering Late Start Slack Late Finish 12/9/2002 1 12/9/2002 Analysis Late Start Slack Late Finish 12/10/2002 2 12/11/2002 Design Late Start Slack Late Finish 12/12/2002 4 12/17/02 Coding Late Start Slack Late Finish 12/18/2002 10 12/31/2002 Testing Duration Late Start Slack Late Finish End time 106
More Pert & Gantt 107 Function Points FP is a unit for estimating time and effort A.J. Albrecht of IBM, c. 1979 Identify set of application activities (building blocks) and sum the weights assigned to each Building blocks identification and weight assignment depend critically on: A world-wide database of FP practices History of the firm Experience of the FP estimators (certification) 108
Function Points Number of basic FP building blocks determined from application, not implementation: Input files Output files Inquiries (snapshot request, no state change) Internal files (transformations) External interfaces (to other systems) Score for each block based on complexity: low, medium, high Unadjusted FP (UFP) is sum of the scores 109 UFP Scores Low Medium High Input files 3 4 6 Output files 4 5 7 Inquiries 3 4 6 Internal files 7 10 15 External interfaces 5 7 10 110
Function Points 14 technical factors related to complexity Grouped under 3 classes of complexity: system, I/O, application Each factor ranked from 0 to 5 Technical complexity factor (TCF) TCF = i= 14 ( TCFi ) 0. 01 1 The sum of the 14 factors ranks Adjusted function points (AFP or FP) FP = UFP * (0.65 + TCF) 111 Using FPs to Estimate Time/Effort Previous measurements of FP per staff month or FP per calendar month Analogous to XP project velocity Applies to maintenance as well as development (considering enhancement function points ) Tables available for lines of code per FP in various programming languages 112
Technical Factors 1. System Complexity 2. I/O Complexity 3. Application Complexity 1.1 Data communication 1.2 Distributed data processing 1.3 Relevance of performance 2.1 Reliable and transaction-oriented data management 2.2 Online data management 2.3 Usability and efficiency of end user 3.1 Algorithms and processing ability 3.2 Need to reuse the code later 3.3 Installation easiness 1.4 Configuration of hardware and software 2.4 Online update of the data 3.4 Startup, shutdown, and operation easiness Partial (1) Partial (2) 3.5 Requirements to run on multiple sites Total 3.6 Readiness to change Partial (3) 113 UFP for Making Cappuccino Name Type (building block) Complexity Value Milk Input File Medium 4 Coffee Input File Medium 4 Water Input File Low 3 Cappuccino Output File High 7 Water Temperature Inquiry Low 3 External Temperature External Interface Medium 7 Total Unadjusted Function Points 28 114
FP for Making Cappuccino 1. System Complexity 2. I/O Complexity 3. Application Complexity 1.1 Data communication 5 2.1 Reliable and transaction-oriented data management 1.2 Distributed data processing 1.3 Relevance of performances 3 2.2 Online data management 4 2.3 Usability and efficiency of the end user 0 3.1 Algorithms and processing ability 4 3.2 Need of reuse of the 0 code 4 3.3 Installation easiness 5 1 1.4 Configuration of the hardware and the software 4 2.4 Online update of the data 2 3.4 Startup, shutdown, and operation easiness 3 Partial (1) 16 Partial (2) 10 3.5 Requirements to run on multiple sites 2 3.6 Readiness to change 2 Partial (3) 13 Total = 39 115 FP for Making Cappuccino FP = UFP * (0.65 + TCF) = 28 * (0.65 + (39 * 0.01)) = 29.12 So what was the time/effort required last time your firm implement 29 FPs? 116
Constructive Cost Model COCOMO estimates best/likely/worst case range for cost, effort and schedule required to develop software Barry Boehm of TRW (now USC), c. 1981, updated c. 1995 (COCOMO II, original renamed COCOMO 81) Also based on empirical data from numerous projects, divided according to, e.g., 3 development modes: organic, semidetached, embedded [COCOMO 81] Assumes separate guestimate of lines of code (or backfired from function points), then considers additional factors 117 Development Modes Organic: relatively small software teams develop software in a highly familiar, inhouse environment Semidetached: intermediate stage between the organic and embedded modes Embedded: Product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures 118
Additional Factors Platform Personnel Project Execution Time Constraints Analyst Capability Use of Modern Programming Practices Main Storage Constraints Programmer Capability Use of Software Tools Platform Volatility Applications Experience Multi-site Development Computer Turnaround Time Platform Experience Language and Tool Experience Personnel Continuity Required Development Schedule Classified Security Application 119 COCOMO Polynomial model Effort( Size) = A Size where A, B > 0 B A and B are computed based on the development mode (or scale factors in COCOMO II) and additional factors Handbooks available as a guide for the calculations of A and B Continued data collection to improve prediction accuracy (questionnaires, software, NDAs) 120
Summary FP and COCOMO macro-estimation based partially on large historical database of contributing software projects from multiple domains and partially on in-house experience Use case and user story micro-estimation entirely in-house, usually based on same or similar projects by same or related project team 121 Part IV Conclusion 122
n n Course Assignments Individual Assignments n Reports based on case studies or exercises Project-Related Assignments n n n n All assignments (other than the individual assessments) will correspond to milestones in the team project. As the course progresses, students will be applying various methodologies to a project of their choice. The project and related software system should relate to a real-world scenario chosen by each team. The project will consists inter-related deliverables which are due on a (bi-) weekly basis. There will be only one submission per team per deliverable and all teams must demonstrate their projects to the course instructor. A sample project description and additional details will be available under handouts on the course Web site. 123 n Project Logistics Course Project n Teams will pick their own projects, within certain constraints: for instance, all projects should involve multiple distributed subsystems (e.g., web-based electronic services projects including client, application server, and database tiers). Students will need to come up to speed on whatever programming languages and/or software technologies they choose for their projects - which will not necessarily be covered in class. n Students will be required to form themselves into "pairs" of exactly two (2) members each; if there is an odd number of students in the class, then one (1) team of three (3) members will be permitted. There may not be any "pairs" of only one member! The instructor and TA(s) will then assist the pairs in forming "teams", ideally each consisting of two (2) "pairs", possibly three (3) pairs if necessary due to enrollment, but students are encouraged to form their own 2-pair teams in advance. If some students drop the course, any remaining pair or team members may be arbitrarily reassigned to other pairs/teams at the discretion of the instructor (but are strongly encouraged to reform pairs/teams on their own). Students will develop and test their project code together with the other member of their programming pair. 124
Very extreme Programming (VXP) After teams formed, 1/2 week to Project Concept 1/2 week to Revised Project Concept 2 to 3 iterations For each iteration: 1/2 week to plan 1 week to iteration report and demo 125 Very extreme Programming (VXP) (continued) Requirements: Your project focuses on two application services Planning: User stories and work breakdown Doing: Pair programming, write test cases before coding, automate testing Demoing: 5 minute presentation plus 15 minute demo Reporting: What got done, what didn t, what tests show 1 st iteration: Any 2 nd iteration: Use some component model framework 3 rd iteration: Refactoring, do it right this time 126
Revised Project Concept (Tips) 1. Cover page (max 1 page) 2. Basic concept (max 3 pages): Briefly describe the system your team proposes to build. Write this description in the form of either user stories or use cases (your choice). Illustrations do not count towards page limits. 3. Controversies (max 1 page) 127 First Iteration Plan (Tips) Requirements (max 2 pages): Select user stories or use cases to implement in your first iteration, to produce a demo by the last week of class Assign priorities and points to each unit - A point should correspond to the amount of work you expect one pair to be able to accomplish within one week You may optionally include additional medium priority points to do if you have time It is acceptable to include fewer, more or different use cases or user stories than actually appeared in your Revised Project Concept 128
First Iteration Plan (Tips) Work Breakdown (max 3 pages): Refine as engineering tasks and assign to pairs Describe specifically what will need to be coded in order to complete each task Also describe what unit and integration tests will be implemented and performed You may need additional engineering tasks that do not match one-to-one with your user stories/use cases Map out a schedule for the next weeks Be realistic demo has to been shown before the end of the semester 129 2 nd Iteration Plan (Tips): Requirements Max 3 pages Redesign/reengineer your system to use a component framework (e.g., COM+, EJB, CCM,.NET or Web Services) Select the user stories to include in the new system Could be identical to those completed for your 1 st Iteration Could be brand new (but explain how they fit) Aim to maintain project velocity from 1 st iteration Consider what will require new coding vs. major rework vs. minor rework vs. can be reused as is 130
2 nd Iteration Plan (Tips): Breakdown Max 4 pages Define engineering tasks, again try to maintain project velocity Describe new unit and integration testing Describe regression testing Can you reuse tests from 1 st iteration? If not, how will you know you didn t break something that previously worked? 2 nd iteration report and demo to be presented before the end of the semester 131 2 nd Iteration Report (Tips): Requirements Max 2 pages For each engineering task from your 2 nd Iteration Plan, indicate whether it succeeded, partially succeeded (and to what extent), failed (and how so?), or was not attempted Estimate how many user story points were actually completed (these might be fractional) Discuss specifically your success, or lack thereof, in porting to or reengineering for your chosen component model framework(s) 132
2 nd Iteration Report (Tips): Testing Max 3 pages Describe the general strategy you followed for unit testing, integration testing and regression testing Were you able to reuse unit and/or integration tests, with little or no change, from your 1 st Iteration as regression tests? What was most difficult to test? Did using a component model framework help or hinder your testing? 133 Project Presentation and Demo All Iterations Due Presentation slides (optional) 134
Readings Readings Slides and Handouts posted on the course web site Documentation provided with software engineering tools XP Explained (all sections) Agile Software Development Ecosystems (all sections) Extreme Programming Perspectives (ISBN:0201770059) by Giancarlo Succi, Michele Marchesi, James Donovan Wells, and Laurie Williams Project Frameworks Setup (ongoing) As per references provided on the course Web site Individual Assignment See Handouts: Project (Part 4) 135 Next Session: Quantifying Project Specifications Using Formal Methods Other Project Considerations Using Set Theory and Logic Verifying Requirements Mathematically Evaluating Agile Software Engineering Software Engineering Ethics Web Engineering Techniques Measuring User Satisfaction Summary Project (Part 4) ongoing 136