1 Chapter 5 Project management. 2 Project management : Is Organizing, planning and scheduling...
-
Upload
eugenia-beasley -
Category
Documents
-
view
223 -
download
2
Transcript of 1 Chapter 5 Project management. 2 Project management : Is Organizing, planning and scheduling...
4
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.
Software project management
5
The product is intangible (can’t be seen or touched), the managers can’t see the progress of product.
The software development process is not standardized as building engineering, the process varies from organization to another
Many software projects are 'one-off‘: each project is different from previous others, even
the manager who have a long experience may find it difficult to solve the problem in new software project, Because of rapid technological change in computer .
Lessons learned or experienced may not be transfer to new project.
Software engineering distinctions (differences) (which can make the software management difficult)
6
Most managers have these responsibilities: Proposal writing, objectives of project and how it will be carried
out. It include cost and schedule estimates.
Project planning and scheduling, identifying activities, milestone and deliverable produced by project.
Project costing, cost estimation for resources needed to a accomplish the project plan .
Project monitoring and reviews, it is a continuing activities which can predict potential problems, and track the progress of the project. Such as daily discussion with project staff.
Personnel selection and evaluation, select a skilled personal .
Report writing and presentations, write a report with critical information to client and contractor , present this report during progress review.
5.1 Management activities
7
Project staffingMay not be possible to appoint يوظف the ideal
people to work on a project because of:
Project budget may not allow for the use of highly-paid 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.
8
5.2 Project planningProbably the most time-consuming project management
activity
It is the tasks required to define resources, timelines.
The project plan sets out, the resources available to the project, the work breakdown تجزئة, and schedule for the work
9
Continuous activity (planning is iterative process) from initial concept through the system delivery. Plans must be regularly changed as new information becomes available, it evolves as the better information becomes available.
. Various types of plans may be developed to support the main software project plan that is concerned with: schedule plan budget planquality planvalidation planconfiguration planmaintenance planstaff plan
5.2 Project planning, cont…
10
Types of project planPlan Description
Quality plan Describes the quality procedures and standards that will beused in a project. See Chapter 27.
Validation plan Describes the approach, resources and schedule used forsystem validation. See Chapter 22.
Configurationmanagement plan
Describes the configuration management procedures andstructures to be used. See Chapter 29.
Maintenance plan Predicts the maintenance requirements of the system,maintenance costs and effort required. See Chapter 21.
Staff developmentplan.
Describes how the skills and experience of the project teammembers will be developed. See Chapter 25.
11
5.2.1 Project plan structureMost plans should include the following sections: Introduction, describe objectives and set constraints (budget,
time).
Project organization, the way the development team is organized.
Risk analysis, describe possible risks, and the risk reduction strategies.
Hardware and software resource requirements, describe the hardware and the support software required to carry out the development, estimate of the price.
12
Project plan structure, cont..Work breakdown, describe the breakdown of the project
into activities and identifies the milestones and deliverables associated with each activity.
Project schedule, describe the dependencies between activities, estimate time required to reach each milestone and allocation of people to activities.
Monitoring and reporting mechanisms, describe the management reports which should be produced.
13
5.2.2 Activity organization (milestones and deliverables)
Milestones are the end-point of a process activity, the software process must be broken down into basic activities.
At the end of each milestone there should be a formal output such as a report.
Deliverables are project results delivered to customers
deliverables are milestones but milestones need not be deliverables.
Milestones are an internal project result used by manager to check project progress that are not delivered to customer
14
Milestones in the RE(Req. Eng.) process or activties
Evaluationreport
Prototypedevelopment
Requirementsdefinition
Requirementsanalysis
Feasibilityreport
Feasibilitystudy
Architecturaldesign
Designstudy
Requirementsspecification
Requirementsspecification
ACTIVITIES
MILESTONES
15
5.3 Project schedulingSplit project into tasks and estimate time and resources
required to complete each task
Organize tasks concurrently (simultaneously or side by side) 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
schedules must be continually updated as better progress info becomes available.
16
The project scheduling process
Estimate resourcesfor activities
Identify activitydependencies
Identifyactivities
Allocate peopleto activities
Create projectcharts
Softwarerequirements
Activity chartsand bar charts
17
Scheduling
The maximum a mount of time of any activity is from 8-10 weeks.
The minimum at least 1 week
If it is larger than this , it must be divided.
18
5.3.1 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
Network Activity show task dependencies and the the critical path
Bar charts show schedule against calendar time
The minimum time required to finish the project is called the critical path, which it is the longest path in the activity graph.
19
Task duration and dependenciesExample: T3 start after T1 finish.
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)
20
Activity networkfor example, if T8 is delayed 2 weeks, it will not affect the completion date because it does not lie on critical path.The critical path is: T1 T3 T9 T11T12The minimum days required to complete project is : 8+ 15+ 15+7+10 =55 day
Activity network
21
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99
15 days
11/8/99
25 days
10 days
20 days
5 days25/7/99
15 days
25/7/99
18/7/99
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
Activity network
22
Activity timeline4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5T8
M3
M2T6
T5M4
T9
M7T10
M6
T11M8
T12
Start
Finish
23
Staff allocation4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
24
5.4 Risk management
Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.
What are the top ten risks for this project? For each of the risk, what is the chance that risk will become a problem and what is the impact if it does?
25
Risk management continues..
A risk is a probability that some adverse (unfavorable) circumstance will occur, such categories are:
Project risks affect schedule or resources. e.g. Loss of an experienced designer
Product risks affect the quality or performance of the software being developed.
e.g. the failure of a purchased component.
Business risks affect the organization developing a software
e.g. a competitor introducing a new product
26
Risk management continues..
All risk types are overlap : if an experienced programmer leave the project (project risk) replacement with new one with less experience will result in programming errors (product risk)
27
Possible Software risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule.
Requirements change Project and product
There will be a larger number of changes to the requirements than anticipated.
Specification delays Project and product
Specifications of essential interfaces are not available on schedule
Size underestimate Project and product
The size of the system has been underestimated.
CASE tool under-performance
Product CASE tools which support the project do not perform as anticipated
Technology change Business The underlying technology on which the system is built is superseded by new technology.
Product competition Business A competitive product is marketed before the system is completed.
28
The risk management process (iterative process)
Risk identificationIdentify project, product and business risks
Risk analysisAssess the likelihood and consequences of these
risksRisk planning
Draw up plans to avoid or minimize the effects of the risk
Risk monitoringMonitor the risks throughout the project
29
The risk management process
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
30
5.4.1 Risk identification
Six types of risks that can be found:
Technology risks: Risks derived from Hw + SWPeople risksTool risks : Risks derived from CASE toolOrganizational risks : from Organization
environment Requirements risks: from Req. ChangeEstimation risks: from estimate the resources
used to build the system
31
Risks and risk typesRisk type Possible risks
Technology The database used in the system cannot process as many transactions per second as expected. Software components that should be reused contain defects that limit their functionality.
People 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.
Organisational The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient. CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed. Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.
32
5.4.2 Risk analysisAssess probability and affects 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
Organisational financial problems force reductions inthe project budget.
Low Catastrophic
It is impossible to recruit staff with the skills requiredfor the project.
High Catastrophic
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused containdefects which limit their functionality.
Moderate Serious
Changes to requirements that require major designrework are proposed.
Moderate Serious
The organisation is restructured so that differentmanagement are responsible for the project.
High Serious
34
5.4.3 Risk planning
Consider each risk and develop a strategy to manage that risk, these strategies fall into three categories:
Avoidance strategiesThe probability that the risk will arise is reducedE.g. deal with defective component by bought a component.
Minimization strategiesThe impact of the risk on the project or product will be
reduced. E.g. staff illness [ overlap work]Contingency plans
If the risk arises, contingency plans are plans to deal with that risk, if the worse happens, you are prepared for it.
E.g financial problem
35
Risk management strategies
Risk Strategy
Organisationalfinancial problems
Prepare a briefing document for senior managementshowing how the project is making a very importantcontribution to the goals of the business.
Recruitmentproblems
Alert customer of potential difficulties and thepossibility of delays, investigate buying-incomponents.
Staff illness Reorganise team so that there is more overlap of workand people therefore understand each other’s jobs.
Defectivecomponents
Replace potentially defective components with bought-in components of known reliability.
36
5.4.4 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
Key pointsGood project management is essential for project
successThe intangible nature of software causes problems
for managementManagers 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
38
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
Key points