Presentation is loading. Please wait.

Presentation is loading. Please wait.

ISBN 0-13-146913-4 Prentice-Hall, 2006 Chapter 3 Planning and Managing the Project Copyright 2006 Pearson/Prentice Hall. All rights reserved.

Similar presentations


Presentation on theme: "ISBN 0-13-146913-4 Prentice-Hall, 2006 Chapter 3 Planning and Managing the Project Copyright 2006 Pearson/Prentice Hall. All rights reserved."— Presentation transcript:

1 ISBN 0-13-146913-4 Prentice-Hall, 2006 Chapter 3 Planning and Managing the Project Copyright 2006 Pearson/Prentice Hall. All rights reserved.

2 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.2 © 2006 Pearson/Prentice Hall Contents 3.1 Tracking Progress 3.2 Project Personnel 3.3 Effort Estimation 3.4 Risk Management 3.5 The Project Plan 3.6Process Models and Project Management 3.7 Information System Example 3.8 Real Time Example 3.9 What this Chapter Means for You

3 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.3 © 2006 Pearson/Prentice Hall Chapter 3 Objectives Tracking project progress Project personnel and organization Effort and schedule estimation Risk management Using process modeling with project planning

4 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.4 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Do you understand customer’s problems and needs? Can you design a system to solve customer’s problems or satisfy customer’s needs? How long will it take you to develop the system? How much will it cost to develop the system?

5 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.5 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Project Schedule Describes the software-development cycle for a particular project by –enumerating the phases or stages of the project –breaking each phase into discrete tasks or activities to be completed Portrays the interactions among the activities and estimates the times that each task or activity will take

6 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.6 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Project Schedule: Approach Understanding customer’s needs by listing all project deliverables –Documents –Demonstrations of function –Demonstrations of subsystems –Demonstrations of accuracy –Demonstrations of reliability, performance or security Determining milestones and activities to produce the deliverables

7 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.7 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Milestones and activities Activity: takes place over a period of time Milestone: completion of an activity -- a particular point in time Precursor: event or set of events that must occur in order for an activity to start Duration: length of time needed to complete an activity Due date: date by which an activity must be completed

8 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.8 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Project Schedule (continued) Project development can be separated into a succession of phases which are composed of steps, which are composed of activities

9 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.9 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Project Schedule (continued) Table 3.1 shows the phases, steps and activities to build a house –landscaping phase –building the house phase Table 3.2 lists milestones for building the house phase

10 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.10 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Phases, Steps, and Activities in Building a House

11 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.11 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Milestones in Building a House

12 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.12 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Work Breakdown and Activity Graphs Work breakdown structure depicts the project as a set of discrete pieces of work Activity graphs depict the dependencies among activities –Nodes: project milestones –Lines: activities involved

13 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.13 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Work Breakdown and Activity Graphs (continued) Activity graph for building a house

14 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.14 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Estimating Completion Adding estimated time in activity graph of each activity to be completed tells us more about the project's schedule

15 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.15 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Estimating Completion for Building a House

16 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.16 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Critical Path Method (CPM) Minimum amount of time it will take to complete a project –Reveals those activities that are most critical to completing the project on time Real time (actual time): estimated amount of time required for the activity to be completed Available time: amount of time available in the schedule for the activity's completion Slack time: the difference between the available time and the real time for that activity

17 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.17 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Critical Path Method (CPM) (continued) Critical path: the slack at every node is zero –can be more than one in a project schedule Slack time = available time – real time = latest start time – earliest start time

18 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.18 © 2006 Pearson/Prentice Hall Slack Time for Activities of Building a House

19 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.19 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress CPM Bar Chart Including information about the early and late start dates Asterisks indicate the critical path

20 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.20 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Tools to Track Progress Example: to track progress of building a communication software

21 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.21 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Tools to Track Progress: Gantt Chart Activities shown in parallel –helps understand which activities can be performed concurrently

22 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.22 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Tools to Track Progress: Resource Histogram Shows people assigned to the project and those needed for each stage of development

23 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.23 © 2006 Pearson/Prentice Hall 3.1 Tracking Progress Tools to Track Progress: Expenditures Tracking An example of how expenditures can be monitored

24 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.24 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Key activities requiring personnel –requirements analysis –system design –program design –program implementation –testing –training –maintenance –quality assurance There is great advantage in assigning different responsibilities to different people

25 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.25 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Choosing Personnel Ability to perform work Interest in work Experience with –similar applications –similar tools, languages, or techniques –similar development environments Training Ability to communicate with others Ability to share responsibility Management skills

26 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.26 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Communication A project's progress is affected by –degree of communication –ability of individuals to communicate their ideas Software failures can result from breakdown in communication and understanding

27 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.27 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Communication (continued) Line of communication can grow quickly If there is n worker in project, then there are n(n-1)/2 pairs of communication

28 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.28 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Sidebar 3.1 Make Meeting Enhance Project Progress Common complaints about meetings –the purpose is unclear –the attendees are unprepared –essential people are late or absent –the conversation veers away from its purpose –participants do not discuss, instead argue –decisions are never enacted afterward Ways to ensure a productive meeting –clearly decide who should be in the meeting –develop an agenda –have someone who tracks the discussion –have someone who ensures follow-up actions

29 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.29 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Work Styles Extroverts: tell their thoughts Introverts: ask for suggestions Intuitives: base decisions on feelings Rationals: base decisions on facts, options

30 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.30 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Work Styles (continued) Horizontal axis: communication styles Vertical axis: decision styles

31 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.31 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Work Styles (continued) Work styles determine communication styles Understanding workstyles –Helps you to be flexible –give information about other's priorities Affect interaction among customers, developers and users

32 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.32 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Project Organization Depends on –backgrounds and work styles of team members –number of people on team –management styles of customers and developers Examples: –Chief programmer team: one person totally responsible for a system's design and development –Egoless approach: hold everyone equally responsible

33 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.33 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Project Organization: Chief Programmer Team Each team member must communicate often with chief, but not necessarily with other team members

34 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.34 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Project Organization (continued) Characteristics of projects and the suggested organizational structure to address them

35 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.35 © 2006 Pearson/Prentice Hall 3.2 Project Personnel Sidebar 3.2 Structure vs. Creativity Experiment by Sally Phillip examining two groups building a hotel –structured team: clearly defined responsibilities –unstructured team: no direction, incredibly creative The results are always the same Good project management means finding a balance between structure and creativity

36 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.36 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Estimating project costs is one of the crucial aspects of project planning and management Estimating cost has to be done as early as possible during the project life cycle Type of costs –facilities: hardware space, furniture, telephone, etc –methods and tools: software, tools for designing software (Computer-Aiede Software Engineering or CASE) –staff (effort): the biggest component of cost

37 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.37 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Estimation Should be Done Repeatedly Uncertainty early in the project can affect the accuracy of cost and size estimations

38 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.38 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Sidebar 3.3 Causes of Inaccurate Estimates Key causes –Frequent request for change by users –Overlooked tasks –User's lack of understanding of the requirements –Insufficient analysis when developing estimate –Lack of coordination of system development, technical services, operations, data administration, and other functions during development –Lack of an adequate method or guidelines for estimating

39 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.39 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Sidebar 3.3 Causes of Inaccurate Estimates (continued) Key influences –Complexity of the proposed application system –Required integration with existing system –Complexity of the program in the system –Size of the system expressed as number of functions or programs –Capabilities of the project team members –Project team's experience with the application, the programming language, and hardware –Capabilities of the project team members –Database management system –Number of project team member –Extent of programming and documentation standards

40 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.40 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Type of Estimation Methods Expert judgment Top-down or bottom-up – Analogy: pessimistic (x), optimistic (y), most likely (z); estimate as (x + 4y + z)/6 – Delphi technique: based on the average of “secret” expert judgments – Wolverton model: old (mid 70’s) Algorithmic methods: E = (a + bS c ) m(X) – Walston and Felix model: E = 5.25S 0.91 – Bailey and Basili model: E = 5.5 + 0.73S 1.16

41 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.41 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Expert Judgement: Wolverton Model Two factors that affect difficulty –whether problem is old (O) or new (N) –whether it is easy (E) or moderate (M)

42 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.42 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Algorithmic Method: Watson and Felix Model A productivity index is inlcuded in the equation There are 29 factors that can affect productivity –1 if increase the productivity –0 if decrease the productivity

43 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.43 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Watson and Felix Model Productivity Factors

44 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.44 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Agorithmic Method: Bailey-Basili technique Minimize standard error estimate to produce an equation such as E = 5.5 + 0.73S 1.16 Adjust initial estimate based on the difference ratio –If R is the ratio between the actual effort, E, and the predicted effort, E’, then the effort adjustment is defined as –ER adj = R – 1 if R > 1 = 1 – 1/R if R < 1 Adjust the initial effort estimate E adj –E adj = (1 + ER adj )E if R > 1 = E/(1 + ER adj ) if R < 1

45 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.45 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Agorithmic Method: Bailey-Basily Modifier

46 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.46 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation COCOMO model Introduced by Boehm COCOMO II –updated version –include models of reuse The basic models –E = bS c m(X) –where bS c is the initial size-based estimate m(X) is the vector of cost driver information

47 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.47 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation COCOMO II: Stages of Development Application composition – prototyping to resolve high-risk user interface issues – size estimates in object points Early design – to explore alternative architectures and concepts – size estimates in function points Postarchitecture – development has begun – size estimates in lines of code

48 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.48 © 2006 Pearson/Prentice Hall Three Stages of COCOMO II

49 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.49 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation COCOMO II: Estimate Application Points To compute application points, first we need to count the number of screens, reports, and programming language used to determine the complexity level 8 +mediumdifficult 4 +mediumdifficult

50 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.50 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation COCOMO II: Estimate Application Point (continued) Determine the relative effort required to implement a report or screen simple, medium, or difficult Calculate the productivity factor based on developer experience and capability Determine the adjustment factors expressed as multipliers based on rating of the project

51 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.51 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Complexity Weights for Application Points Object typeSimpleMediumDifficult Screen 123 Report 258 3GL component -- 10

52 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.52 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Productivity Estimate Calculation

53 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.53 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Tool Use Categories

54 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.54 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Machine Learning Techniques Example: case-based reasoning (CBR) –user identifies new problem as a case –system retrieves similar cases from repository –system reuses knowledge from previous cases –system suggests solution for new case Example: neural network –cause-effect network “trained” with data from past history

55 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.55 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Machine Learning Techniques: Neural Network Neural network used by Shepperd to produce effort estimation

56 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.56 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Machine Learning Techniques: CBR Involves four steps –the user identifies a new problem as a case –the system retrieves similar case from a respository of historical information –the system reuses knowledge from previous case –the system suggests a solution for the new case Two big hurdles in creating successful CBR system –characterizing cases –determining similarity

57 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.57 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Finding the Model for Your Situation Mean magnitude of relative error (MMRE) – absolute value of mean of [(actual - estimate)/actual] – goal: should be.25 or less Pred(x/100): percentage of projects for which estimate is within x% of the actual – goal: should be.75 or greater for x =.25

58 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.58 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Evaluating Models (continued) No model appears to have captured the essential characteristics and their relationships for all types of development

59 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.59 © 2006 Pearson/Prentice Hall 3.3 Effort Estimation Evaluating Models (continued) It is important to understand which types of effort are needed during development even when we have reasonably accurate estimate Two different reports of effort distribution from different researchers

60 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.60 © 2006 Pearson/Prentice Hall 3.4 Risk Management What is a Risk? Risk is an unwanted event that has negative consequences Distinguish risks from other project events –Risk impact: the loss associated with the event –Risk probability: the likelihood that the event will occur –Risk control: the degree to which we can change the outcome Quantify the effect of risks –Risk exposure = (risk probability) x (risk impact) Risk sources: generic and project-specific

61 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.61 © 2006 Pearson/Prentice Hall 3.4 Risk Management Risk Management Activities

62 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.62 © 2006 Pearson/Prentice Hall 3.4 Risk Management Risk Management Activities (continued) Example of risk exposure calculation

63 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.63 © 2006 Pearson/Prentice Hall 3.4 Risk Management Risk Management Activities (continued) Three strategies for risk reduction –Avoiding the risk: change requirements for performance or functionality –Transferring the risk: transfer to other system, or buy insurance –Assuming the risk: accept and control it Cost of reducing risk –Risk leverage = (risk exposure before reduction – (risk exposure after reduction) / (cost of risk reduction)

64 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.64 © 2006 Pearson/Prentice Hall 3.4 Risk Management Sidebar 3.4 Boehm’s Top Ten Risk Items Personnel shortfalls Unrealistic schedules and budgets Developing the wrong functions Developing the wrong user interfaces Gold-plating Continuing stream of requirements changes Shortfalls in externally-performed tasks Shortfalls in externally-furnished components Real-time performance shortfalls Straining computer science capabilities

65 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.65 © 2006 Pearson/Prentice Hall 3.5 Project Plan Project Plan Contents Project scope Project schedule Project team organization Technical description of system Project standards and procedures Quality assurance plan Configuration management plan Documentation plan Data management plan Resource management plan Test plan Training plan Security plan Risk management plan Maintenance plan

66 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.66 © 2006 Pearson/Prentice Hall 3.5 Project Plan Project Plan Lists List of the people in development team List of hardware and software Standards and methods, such as –algorithms –tools –review or inspection techniques –design language or representaions –coding languages –testing techniques

67 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.67 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Enrollment Management Model: Digital Alpha AXP Establish an appropriately large shared vision Delegate completely and elicit specific commitments from participants Inspect vigorously and provide supportive feedback Acknowledge every advance and learn as the program progresses

68 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.68 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Digital Alpha AXP (continued) Vision: to “enroll” the related programs, so they all shared common goals

69 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.69 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Digital Alpha AXP (continued) An organization that allowed technical focus and project focus to contribute to the overall program

70 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.70 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Accountability Modeling: Lockheed Martin Matrix organization – Each engineer belongs to a functional unit based on type of skill Integrated product development team – Combines people from different functional units into interdisciplinary work unit Each activity tracked using cost estimation, critical path analysis, schedule tracking – Earned value a common measure for progress

71 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.71 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Accountability modeling:Lockheed Martin (continued) Accountability model used in F-16 Project

72 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.72 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Accountability Modeling: Lockheed Martin (continued) Teams had multiple, overlapping activities An activity map used to illustrate progress on each activity

73 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.73 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Accountability Modeling: Lockheed Martin (continued) Each activitiy's progress was tracked using earned value chart

74 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.74 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Anchoring (Common) Milestones Life cycle objectives Objectives: Why is the system being developed? Milestones and schedules: What will be done by when? Responsibilities: Who is responsible for a function? Approach: How will the job be done, technically and managerially? Resources: How much of each resource is needed? Feasibility: Can this be done, and is there a good business reason for doing it? Life-cycle architecture: define the system and software architectures and address architectural choices and risks Initial operational capability: readiness of software, deployment site, user training

75 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.75 © 2006 Pearson/Prentice Hall 3.6 Process Models and Project Management Anchoring Milestones (continued) The Win-Win spiral model suggested by Boehm is used as supplement to the milestones

76 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.76 © 2006 Pearson/Prentice Hall 3.7 Information System Example Piccadilly System Using COCOMO II Three screens and one report –Booking screen: complexity simple, weight 1 –Ratecard screen: complexity simple, weigth 1 –Availability screen: complexity medium, weight 2 –Sales report: complexity medium, weight 5 Estimated effort = 182 person-month

77 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.77 © 2006 Pearson/Prentice Hall 3.8 Real Time Example Ariane-5 System The Ariane-5 destruction might have been prevented had the project managers developed a risk management plan –Risk identification: possible problem with reuse of the Ariane-4) –Risk exposure: prioritization would have identified if the inertial reference system (SRI) did not work as planned –Risk control: assesment of the risk using reuse software –Risk avoidance: using SRI with two different designs

78 Pfleeger and Atlee, Software Engineering: Theory and PracticePage 3.78 © 2006 Pearson/Prentice Hall 3.9 What this Chapter Means for You Key concepts in project management –Project planning –Cost and schedule estimation –Risk management –Team Organization Project planning involves input from all team members Communication path grows as the size of the team increases and need to be taken into account when planning and estimating schedule


Download ppt "ISBN 0-13-146913-4 Prentice-Hall, 2006 Chapter 3 Planning and Managing the Project Copyright 2006 Pearson/Prentice Hall. All rights reserved."

Similar presentations


Ads by Google