Adaptive Software Engineering G Session 12 - Main Theme Risk Management in Software Engineering Projects. Dr. Jean-Claude Franchitti

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Adaptive Software Engineering G Session 12 - Main Theme Risk Management in Software Engineering Projects. Dr. Jean-Claude Franchitti"

Transcription

1 Adaptive Software Engineering G 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

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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 Part II Cooperative Roles of Software Engineering and Project Management See: (Windows A Software Engineering Odyssey) 41 Projects Launching Guidelines 42

22 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

23 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

24 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

25 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

26 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

27 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: 54

28 Part IV Risk Management in Agile Processes See: (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

29 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

30 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

31 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

32 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

33 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

34 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

35 Bibliography Agile Manifesto (2001) 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 69 Part V Agile Project Planning 70

36 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

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 Release Plan 101 H H M H H M H H 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

47 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

48 Iteration Plan with Cards 101 H H M H H M H H M 2 95 Iteration Plan with Cards (after First Iteration) 101 H H H H M M H H M 2 96

49 Iteration Plan with Cards 101 H H H H M M H H M 2 97 Iteration Plan with Cards 101 H H M H H M H H M 2 98

50 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

51 Relative Timing 101 XP Development 102

52 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

53 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 Requirement gathering 12/5/ /6/2002 2d 2 Analysis 12/9/ /9/2002 1d 3 Design 12/10/ /11/2002 2d 4 Coding 12/12/ /17/2002 4d 5 Testing 12/18/ /31/ d 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/ /6/2002 Requirement gathering Late Start Slack Late Finish 12/9/ /9/2002 Analysis Late Start Slack Late Finish 12/10/ /11/2002 Design Late Start Slack Late Finish 12/12/ /17/02 Coding Late Start Slack Late Finish 12/18/ /31/2002 Testing Duration Late Start Slack Late Finish End time 106

54 More Pert & Gantt 107 Function Points FP is a unit for estimating time and effort A.J. Albrecht of IBM, c 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

55 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 Output files Inquiries Internal files External interfaces

56 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 ) The sum of the 14 factors ranks Adjusted function points (AFP or FP) FP = UFP * ( 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

57 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

58 FP for Making Cappuccino 1. System Complexity 2. I/O Complexity 3. Application Complexity 1.1 Data communication Reliable and transaction-oriented data management 1.2 Distributed data processing 1.3 Relevance of performances Online data management Usability and efficiency of the end user Algorithms and processing ability Need of reuse of the 0 code Installation easiness Configuration of the hardware and the software Online update of the data Startup, shutdown, and operation easiness 3 Partial (1) 16 Partial (2) Requirements to run on multiple sites Readiness to change 2 Partial (3) 13 Total = FP for Making Cappuccino FP = UFP * ( TCF) = 28 * ( (39 * 0.01)) = So what was the time/effort required last time your firm implement 29 FPs? 116

59 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 (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

60 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

61 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

62 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

63 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

64 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

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

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

67 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

68 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: ) 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

Project management. Organising, planning and scheduling software projects. Ian Sommerville 2000 Software Engineering, 6th edition.

Project management. Organising, planning and scheduling software projects. Ian Sommerville 2000 Software Engineering, 6th edition. Project management Organising, planning and scheduling software projects Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 1 Objectives To introduce software project management and

More information

Project management. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 1

Project management. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 1 Project management Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 1 Objectives To explain the main tasks undertaken by project managers To introduce software project management

More information

Project management: an SE Perspective

Project management: an SE Perspective Project management: an SE Perspective Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 5 Slide 1 Objectives To explain the main tasks undertaken by project managers To introduce software

More information

Software Engineering. Project Management. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Project Management. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Project Management Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain the main tasks undertaken by project managers To introduce software project

More information

Project management. Objectives. Topics covered. Organizing, planning and scheduling software projects DISCUSSION

Project management. Objectives. Topics covered. Organizing, planning and scheduling software projects DISCUSSION Project management 1 Objectives 2 Organizing, planning and scheduling software projects DISCUSSION Project Managers? To introduce software project management and to describe its distinctive characteristics

More information

Project management. Organizing, planning and scheduling software projects

Project management. Organizing, planning and scheduling software projects Project management Organizing, planning and scheduling software projects Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 3 Slide 1 Objectives To introduce software project management and

More information

Software Engineering G22.2440-001. Session 12 - Main Theme Risk Management in Software Engineering Projects. Dr. Jean-Claude Franchitti

Software Engineering G22.2440-001. Session 12 - Main Theme Risk Management in Software Engineering Projects. Dr. Jean-Claude Franchitti Software Engineering G22.2440-001 Session 12 - Main Theme Risk Management in Software Engineering Projects Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of

More information

Project management. Organizing, planning and scheduling software projects. Objectives. Chapter 3. Chapter 3 Project Management. Learning Objective

Project management. Organizing, planning and scheduling software projects. Objectives. Chapter 3. Chapter 3 Project Management. Learning Objective Chapter 3 Chapter 3 Project Management Learning Objective...to give an appreciation for and to introduce project management and to place it into context and give some of the fundamentals to project management

More information

Organizing, planning and scheduling software projects

Organizing, planning and scheduling software projects Project management Organizing, planning and scheduling software projects Ian Sommerville 1995 Modified by Spiros Mancoridis 1998 Software Engineering, 5th edition. Chapter 3 Slide 1 Objectives To introduce

More information

Organising, planning and scheduling software projects. Software management distinctions

Organising, planning and scheduling software projects. Software management distinctions Project management Organising, planning and scheduling software projects Software management distinctions The product is intangible The product is uniquely flexible Software engineering is not recognized

More information

Management activities. Risk management

Management activities. Risk management Management activities Proposal writing. Project planning and scheduling. Project costing. Project monitoring and reviews. Personnel selection and evaluation. Report writing and presentations. Ian Sommerville

More information

Chapter 22 Project Management. Chapter Summary. Chapter 22 Project management

Chapter 22 Project Management. Chapter Summary. Chapter 22 Project management Chapter 22 Project Management Chapter Summary 1 Topics covered Risk management Managing people Teamwork 2 Software project management Concerned with activities involved in ensuring that software is delivered

More information

CS/SWE 321 Sections -001 & -003. Software Project Management

CS/SWE 321 Sections -001 & -003. Software Project Management CS/SWE 321 Sections -001 & -003 Software Project Management Copyright 2014 Hassan Gomaa All rights reserved. No part of this document may be reproduced in any form or by any means, without the prior written

More information

Project Management. Massimo Felici Room 1402, JCMB, KB 0131 650 5899 mfelici@inf.ed.ac.uk

Project Management. Massimo Felici Room 1402, JCMB, KB 0131 650 5899 mfelici@inf.ed.ac.uk Project Management Massimo Felici Room 1402, JCMB, KB 0131 650 5899 mfelici@inf.ed.ac.uk Project Management Software project management is an essential part of software engineering Concerned with activities

More information

Project management. Objectives

Project management. Objectives Project management cmsc435-1 Objectives To explain the main tasks undertaken by project managers To introduce software project management and to describe its distinctive characteristics To discuss project

More information

Contents. Today Project Management. Project Management. Last Time - Software Development Processes. What is Project Management?

Contents. Today Project Management. Project Management. Last Time - Software Development Processes. What is Project Management? Contents Introduction Software Development Processes Project Management Requirements Engineering Software Construction Group processes Quality Assurance Software Management and Evolution Last Time - Software

More information

Project Planning. COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe. Software Engineering 2013

Project Planning. COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe. Software Engineering 2013 Project Planning COSC345 Lecture 3 Slides: Andrew Trotman Dramatic presentation: Richard O Keefe Software Engineering 2013 Overview Assignment: The assignment sheet specifies a minimum Think about what

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

Chapter 3 Agile Software Development. Chapter 3 Agile so1ware development

Chapter 3 Agile Software Development. Chapter 3 Agile so1ware development Chapter 3 Agile Software Development 1 Topics covered ² Agile methods ² Plan-driven and agile development ² Extreme programming 2 Rapid software development ² Rapid development and delivery is now often

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is:

In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: In the IEEE Standard Glossary of Software Engineering Terminology the Software Life Cycle is: The period of time that starts when a software product is conceived and ends when the product is no longer

More information

Managing Agile Projects in TestTrack GUIDE

Managing Agile Projects in TestTrack GUIDE Managing Agile Projects in TestTrack GUIDE Table of Contents Introduction...1 Automatic Traceability...2 Setting Up TestTrack for Agile...6 Plan Your Folder Structure... 10 Building Your Product Backlog...

More information

Chap. 4 Project management. Organising, planning and scheduling software projects

Chap. 4 Project management. Organising, planning and scheduling software projects Chap. 4 Project management Organising, planning and scheduling software projects Slide 1 Objectives To introduce software project management and to describe its distinctive characteristics To discuss the

More information

Introduction to Software Engineering. 9. Project Management

Introduction to Software Engineering. 9. Project Management Introduction to Software Engineering 9. Project Management Roadmap > Risk management > Scoping and estimation > Planning and scheduling > Dealing with delays > Staffing, directing, teamwork 2 Literature

More information

Software Engineering. So#ware Processes

Software Engineering. So#ware Processes Software Engineering So#ware Processes 1 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification defining

More information

Agile So)ware Development

Agile So)ware Development Software Engineering Agile So)ware Development 1 Rapid software development Rapid development and delivery is now often the most important requirement for software systems Businesses operate in a fast

More information

Project Planning and Project Estimation Techniques. Naveen Aggarwal

Project Planning and Project Estimation Techniques. Naveen Aggarwal Project Planning and Project Estimation Techniques Naveen Aggarwal Responsibilities of a software project manager The job responsibility of a project manager ranges from invisible activities like building

More information

Topics. Project plan development. The theme. Planning documents. Sections in a typical project plan. Maciaszek, Liong - PSE Chapter 4

Topics. Project plan development. The theme. Planning documents. Sections in a typical project plan. Maciaszek, Liong - PSE Chapter 4 MACIASZEK, L.A. and LIONG, B.L. (2005): Practical Software Engineering. A Case Study Approach Addison Wesley, Harlow England, 864p. ISBN: 0 321 20465 4 Chapter 4 Software Project Planning and Tracking

More information

Pearson Education Limited 2003

Pearson Education Limited 2003 156 Activities Activity 9.1 (PP. 357 358) [Project planning exercise] You are required to construct a project plan for the following information system development project. Your objective is to schedule

More information

CSE 435 Software Engineering. Sept 16, 2015

CSE 435 Software Engineering. Sept 16, 2015 CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process

More information

Software Quality and Agile Methods

Software Quality and Agile Methods Software Quality and Agile Methods Ming Huo, June Verner, Liming Zhu, Muhammad Ali Babar National ICT Australia Ltd. and University of New South Wales, Australia {mhuo, jverner, limingz, malibaba }@cse.unsw.edu.au

More information

What is software engineering? Software engineering is an engineering discipline which is concerned with all aspects of software production.

What is software engineering? Software engineering is an engineering discipline which is concerned with all aspects of software production. UNIT I - SOFTWARE PROCESS AND PROJECT MANAGEMENT Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models Software Project Management: Estimation LOC and FP Based

More information

A Capability Maturity Model (CMM)

A Capability Maturity Model (CMM) Software Development Life Cycle (SDLC) and Development Methods There are some enterprises in which a careful disorderliness is the true method. Herman Melville Capability Maturity Model (CMM) A Capability

More information

Software Project Management. Software Engineering SW Project Management Slide 1

Software Project Management. Software Engineering SW Project Management Slide 1 Software Project Management Software Engineering SW Project Management Slide 1 Objectives To introduce software project management and to describe its distinctive characteristics Explain the advantages

More information

Project Planning Objectives. Project Estimation. Resources. Software Project Estimation

Project Planning Objectives. Project Estimation. Resources. Software Project Estimation Project Planning Objectives Project Estimation Providing a framework that allows managers to make responsible estimates of the resources and time required to build a software product. Determining the scope

More information

Business Idea Development Product production Services. Development Project. Software project management

Business Idea Development Product production Services. Development Project. Software project management Page 1, 1/20/2003 Ivica Crnkovic Mälardalen University Department of Computer Engineering ivica.crnkovic@mdh.se Development Project Product Lifecycle Business Idea Development Product production Services

More information

AGILE - QUICK GUIDE AGILE - PRIMER

AGILE - QUICK GUIDE AGILE - PRIMER AGILE - QUICK GUIDE http://www.tutorialspoint.com/agile/agile_quick_guide.htm Copyright tutorialspoint.com AGILE - PRIMER Agile is a software development methodology to build a software incrementally using

More information

Introduction to Systems Analysis and Design

Introduction to Systems Analysis and Design Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.

More information

Agile with XP and Scrum

Agile with XP and Scrum Agile with XP and Scrum Amit Goel National Agile Software Workshop @ Indore Agile India Conference Agile Software Community of India Disclaimer and Credits Most of material in this presentation has been

More information

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management?

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management? 11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 11: Managing the Software Process Project management encompasses all the

More information

Effort and Cost Allocation in Medium to Large Software Development Projects

Effort and Cost Allocation in Medium to Large Software Development Projects Effort and Cost Allocation in Medium to Large Software Development Projects KASSEM SALEH Department of Information Sciences Kuwait University KUWAIT saleh.kassem@yahoo.com Abstract: - The proper allocation

More information

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53 Preface xvi Part I Introduction and System Engineering 1 Chapter 1 Introduction 2 1.1 What Is Software Engineering? 2 1.2 Why Software Engineering? 3 1.3 Software Life-Cycle Activities 4 1.3.1 Software

More information

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca Using Simulation to teach project management skills Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca Agenda of the workshop 1 The software project management theory overview (40 minutes) 2 Why use SDLC

More information

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name

More information

PRINCE2:2009 Glossary of Terms (English)

PRINCE2:2009 Glossary of Terms (English) accept (risk response) acceptance acceptance criteria activity agile methods approval approver assumption assurance A risk response to a threat where a conscious and deliberate decision is taken to retain

More information

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.) The Software Process Xiaojun Qi 1 The Unified Process Until recently, three of the most successful object-oriented methodologies were Booch smethod Jacobson s Objectory Rumbaugh s OMT (Object Modeling

More information

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

LECTURE 1. SYSTEMS DEVELOPMENT

LECTURE 1. SYSTEMS DEVELOPMENT LECTURE 1. SYSTEMS DEVELOPMENT 1.1 INFORMATION SYSTEMS System A system is an interrelated set of business procedures used within one business unit working together for a purpose A system has nine characteristics

More information

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY How to Write a Software Process for YOUR COMPANY 1. Introduction MicroTools is proposing to assist YOUR COMPANY in improving the existing software process. The purpose of this project is to both improve

More information

Prepared By: Director, IT Project Owner VP, Manufacturing Project Sponsor. Version Control

Prepared By: Director, IT Project Owner VP, Manufacturing Project Sponsor. Version Control Company: XYZ Manufacturing Company Ltd. Division: Computer Systems Department: Information Technology Process or Product: Servers and Displays manufacturing Prepared By: Document Owners Ken Owttrim John

More information

Fundamentals of Measurements

Fundamentals of Measurements Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role

More information

Managing IT Projects. Chapter 3 Software Project Life cycle

Managing IT Projects. Chapter 3 Software Project Life cycle Managing IT Projects Chapter 3 Software Project Life cycle The Systems Development Life Cycle (SDLC) The SDLC is composed of four fundamental phases: -Planning Analysis Design Implementation The Systems

More information

Project Management. Lecture 3. Software Engineering CUGS. Spring 2012 (slides made by David Broman) Kristian Sandahl

Project Management. Lecture 3. Software Engineering CUGS. Spring 2012 (slides made by David Broman) Kristian Sandahl Project Lecture 3 Software Engineering CUGS Spring 2012 (slides made by David Broman) Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden A Software Life-cycle

More information

Software Development: Tools and Processes. Lecture - 16: Estimation

Software Development: Tools and Processes. Lecture - 16: Estimation Software Development: Tools and Processes Lecture - 16: Estimation Estimating methods analogy method direct estimating method Delphi technique PERT-type rolling window Constructivist Cost Model (CoCoMo)

More information

Project Management. Lecture 3. Software Engineering CUGS. Spring 2011 (slides made by David Broman)

Project Management. Lecture 3. Software Engineering CUGS. Spring 2011 (slides made by David Broman) Lecture 3 Software Engineering CUGS Spring 2011 (slides made by David Broman) Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden A Software Life-cycle Model Which

More information

BEDIFFERENT ACE G E R M A N Y. aras.com. Copyright 2012 Aras. All Rights Reserved.

BEDIFFERENT ACE G E R M A N Y. aras.com. Copyright 2012 Aras. All Rights Reserved. BEDIFFERENT ACE G E R M A N Y ACE Germany Implementation Best Practices Scrum Methodology Patrick Willemsen Senior Consultant ARAS Software AG Slide 3 Dilbert says Slide 4 Agenda Agile Methodology An Overview

More information

Software cost estimation

Software cost estimation Software cost estimation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 1 Objectives To introduce the fundamentals of software costing and pricing To describe three metrics for

More information

An Introduction to. Metrics. used during. Software Development

An Introduction to. Metrics. used during. Software Development An Introduction to Metrics used during Software Development Life Cycle www.softwaretestinggenius.com Page 1 of 10 Define the Metric Objectives You can t control what you can t measure. This is a quote

More information

Work Breakdown Structures. Configuration & Build Management. Object-Oriented Software Engineering. Using UML, Patterns, and Java

Work Breakdown Structures. Configuration & Build Management. Object-Oriented Software Engineering. Using UML, Patterns, and Java Object-Oriented Software Engineering Using UML, Patterns, and Java Configuration & Build Management Work Breakdown Structures Outline of today s class Determining Work and Tasks Sizes Work Breakdown Structure

More information

PROJECT PLAN TEMPLATE

PROJECT PLAN TEMPLATE Treasury Board of Canada Secretariat Secrétariat du Conseil du Trésor du Canada Enhanced Management Framework for Information Management/Information Technology PROJECT PLAN TEMPLATE Document Revision Draft

More information

Best-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler

Best-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler Best-Practice Software Engineering: Software Processes to Support Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems Dietmar.Winkler@qse.ifs.tuwien.ac.at

More information

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or

More information

Roles: Scrum Master & Project Manager

Roles: Scrum Master & Project Manager Roles: Scrum Master & Project Manager Scrum Master: Facilitate collaborative meetings Track team performance Remove impediments (Risk, Issue) Validate team alignment to Agile framework and scope Drive

More information

SWEBOK Certification Program. Software Engineering Management

SWEBOK Certification Program. Software Engineering Management SWEBOK Certification Program Software Engineering Management Copyright Statement Copyright 2011. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted

More information

COMP 354 Introduction to Software Engineering

COMP 354 Introduction to Software Engineering COMP 354 Introduction to Software Engineering Greg Butler Office: EV 3.219 Computer Science and Software Engineering Concordia University, Montreal, Canada Email: gregb@cs.concordia.ca Winter 2015 Course

More information

ABHELSINKI UNIVERSITY OF TECHNOLOGY

ABHELSINKI UNIVERSITY OF TECHNOLOGY T 76.3601 Introduction to Software Engineering Software Project Management http://www.soberit.hut.fi/t-76.3601/ Maria Paasivaara Maria.Paasivaara@tkk.fi Agenda Software projects Project planning Effort

More information

SE351a: Software Project & Process Management

SE351a: Software Project & Process Management SE351a: Software Project & Process Management W8: Software Project Planning 22 Nov., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa SE351 Roadmap Introduction to Software Project Management Project Management

More information

Introduction to the ITS Project Management Methodology

Introduction to the ITS Project Management Methodology Introduction to the ITS Project Management Methodology In September 1999 the Joint Legislative Committee on Performance Evaluation and Expenditure Review (PEER) produced a report entitled Major Computer

More information

Basic Trends of Modern Software Development

Basic Trends of Modern Software Development DITF LDI Lietišķo datorsistēmu programmatūras profesora grupa e-business Solutions Basic Trends of Modern Software Development 2 3 Software Engineering FAQ What is software engineering? An engineering

More information

ICS 121 Lecture Notes Spring Quarter 96

ICS 121 Lecture Notes Spring Quarter 96 Software Management Cost Estimation Managing People Management Poor managment is the downfall of many software projects Ð Delivered software was late, unreliable, cost several times the original estimates

More information

Process Models and Metrics

Process Models and Metrics Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers

More information

Another Way to Burn. The rise of the burndown chart

Another Way to Burn. The rise of the burndown chart This article describes a burndown chart based upon test cases rather than effort and describes its advantages. It is intended for readers already familiar with the concept of a burndown chart. The rise

More information

Software Metrics. Lord Kelvin, a physicist. George Miller, a psychologist

Software Metrics. Lord Kelvin, a physicist. George Miller, a psychologist Software Metrics 1. Lord Kelvin, a physicist 2. George Miller, a psychologist Software Metrics Product vs. process Most metrics are indirect: No way to measure property directly or Final product does not

More information

Rapid Software Development

Rapid Software Development Software Engineering Rapid Software Development Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain how an iterative, incremental development process leads to faster delivery

More information

Extreme Programming, an agile software development process

Extreme Programming, an agile software development process Extreme Programming, an agile software development process Paul Jackson School of Informatics University of Edinburgh Recall: Waterfall and Spiral Models Waterfall: Spiral: Split project into controlled

More information

Total Quality Management (TQM) Quality, Success and Failure. Total Quality Management (TQM) vs. Process Reengineering (BPR)

Total Quality Management (TQM) Quality, Success and Failure. Total Quality Management (TQM) vs. Process Reengineering (BPR) Total Quality Management (TQM) Quality, Success and Failure Total Quality Management (TQM) is a concept that makes quality control a responsibility to be shared by all people in an organization. M7011

More information

SOFTWARE PROJECT MANAGEMENT

SOFTWARE PROJECT MANAGEMENT SOFTWARE PROJECT MANAGEMENT http://www.tutorialspoint.com/software_engineering/software_project_management.htm Copyright tutorialspoint.com The job pattern of an IT company engaged in software development

More information

MNLARS Project Audit Checklist

MNLARS Project Audit Checklist Audit Checklist The following provides a detailed checklist to assist the audit team in reviewing the health of a project. Relevance (at this time) How relevant is this attribute to this project or audit?

More information

Chapter 23 Software Cost Estimation

Chapter 23 Software Cost Estimation Chapter 23 Software Cost Estimation Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Software cost estimation Predicting the resources required for a software development process

More information

Software Engineering

Software Engineering 1 Software Engineering Lecture 2: Software Life Cycles Stefan Hallerstede Århus School of Engineering 25 August 2011 2 Contents Naive Software Development Code & Fix Towards A Software Process Software

More information

Software Requirements Metrics

Software Requirements Metrics Software Requirements Metrics Fairly primitive and predictive power limited. Function Points Count number of inputs and output, user interactions, external interfaces, files used. Assess each for complexity

More information

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34.

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34. Higher National Unit specification General information Unit code: HA4C 34 Superclass: CB Publication date: January 2016 Source: Scottish Qualifications Authority Version: 02 Unit purpose The purpose of

More information

Software Process for QA

Software Process for QA Software Process for QA Basic approaches & alternatives CIS 610, W98 / M Young 1/7/98 1 This introduction and overview is intended to provide some basic background on software process (sometimes called

More information

Génie Logiciel et Gestion de Projets. Project Management

Génie Logiciel et Gestion de Projets. Project Management Génie Logiciel et Gestion de Projets Project Management 1 Roadmap Project Management: Why and what? Risk management Scoping and estimation, planning and scheduling Dealing with delays Staffing, directing,

More information

Agile processes. Extreme Programming, an agile software development process

Agile processes. Extreme Programming, an agile software development process Agile processes Extreme Programming, an agile software development process Nigel Goddard School of Informatics University of Edinburgh What the spiral models were reaching towards was that software development

More information

Life-Cycle Model. Software Life-Cycle Models. Software Development in Theory. Software Development in Practice

Life-Cycle Model. Software Life-Cycle Models. Software Development in Theory. Software Development in Practice Life-Cycle Model Software Life-Cycle Models Xiaojun Qi It specifies the various phases/workflows of the software process, such as the requirements, analysis (specification), design, implementation, and

More information

PROJECT MANAGEMENT PLAN CHECKLIST

PROJECT MANAGEMENT PLAN CHECKLIST PROJECT MANAGEMENT PLAN CHECKLIST The project management plan is a comprehensive document that defines each area of your project. The final document will contain all the required plans you need to manage,

More information

Topic 1 Introduction. to the Fundamentals of Project Management INTRODUCTION LEARNING OUTCOMES

Topic 1 Introduction. to the Fundamentals of Project Management INTRODUCTION LEARNING OUTCOMES Topic 1 Introduction to the Fundamentals of Project Management LEARNING OUTCOMES By the end of this topic, you should be able to: 1. Describe the nature of projects; 2. Identify the project life cycle;

More information

Introduction to Agile Software Development

Introduction to Agile Software Development Introduction to Agile Software Development Word Association Write down the first word or phrase that pops in your head when you hear: Extreme Programming (XP) Team (or Personal) Software Process (TSP/PSP)

More information

Karunya University Dept. of Information Technology

Karunya University Dept. of Information Technology PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main

More information

Software cost estimation. Predicting the resources required for a software development process

Software cost estimation. Predicting the resources required for a software development process Software cost estimation Predicting the resources required for a software development process Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Objectives To introduce the fundamentals

More information

Computer Science and Software Engineering University of Wisconsin - Platteville Note 1: Agile Development

Computer Science and Software Engineering University of Wisconsin - Platteville Note 1: Agile Development Computer Science and Software Engineering University of Wisconsin - Platteville Note 1: Agile Development Yan Shi Lecture Notes for SE 3330 UW-Platteville Issues With Traditional Processes How long do

More information

Selecting a Drug Testing Supplier for Alcoa s US Operations

Selecting a Drug Testing Supplier for Alcoa s US Operations Selecting a Drug Testing Supplier for Alcoa s US Operations Jennifer S. Murray and Mark R. Sobota DNSC 224 Executive Decision Making Professor Ernest Forman April 2007 I. Abstract...13 II. The Problem...3

More information

Topics covered. Agile methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods

Topics covered. Agile methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods Topics covered Chapter 3 Agile Software Development Agile methods Plan-driven and agile Extreme programming Agile project management Scaling agile methods 1 2 Need for rapid software Rapid software Changing

More information

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur Module 11 Software Project Planning Lesson 29 Staffing Level Estimation and Scheduling Specific Instructional Objectives At the end of this lesson the student would be able to: Identify why careful planning

More information

Sample Exam ISTQB Expert Level Test Automation - Engineering 2014

Sample Exam ISTQB Expert Level Test Automation - Engineering 2014 Sample Exam ISTQB Expert Level Test Automation - Engineering 2014 Version 1.0 Copyright Notice This document may be copied in its entirety, or extracts made, if the source is acknowledged. Table of Contents

More information

Selecting a Software Development Methodology based on. Organizational Characteristics. Adrienne Farrell

Selecting a Software Development Methodology based on. Organizational Characteristics. Adrienne Farrell ATHABASCA UNIVERSITY Selecting a Software Development Methodology based on Organizational Characteristics BY Adrienne Farrell An essay submitted in partial fulfillment Of the requirements for the degree

More information

EPL603 Topics in Software Engineering

EPL603 Topics in Software Engineering Lecture 3 Agile Software Development EPL603 Topics in Software Engineering Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740 Topics covered Agile methods

More information

STBE. The Test Planning Process. Objectives

STBE. The Test Planning Process. Objectives STBE The Test Planning Process Objectives Learn the test planning process from start to finish Understand how the test planning components fit together Learn how to write a test script Synopsis This module

More information