View
7
Download
0
Category
Tags:
Preview:
DESCRIPTION
Introduction to software engineering
Citation preview
1
SWE 205 - Introduction to Software Engineering
Lecture 7 - Software Project Management
2
Lecture Objectives To discuss project planning and
planning process. To show how graphical schedule
representations are used by project management
To discuss the notion of risks and the risk management process
3
Project Management process
Project Schedule
Start activities according to schedule
Review Project progress
Update the project schedule
Negotiatedeliverables
4
The Project Plan The project plan sets out:
The resources available to the project; The work breakdown; A schedule for the work.
5
The Project Plan
Quality Plan
Validation Plan
Configuration Plan
Maintenance Plan
Staff Development Plan
Quality Procedures and Standards
Approach, Resources, Schedule
Configuration Management Process
Maintenance Process, cost, required effort
How skills and experience of the Project team will be developed
6
Project Plan Structure Introduction. Project organisation. Risk analysis. Hardware and software resource
requirements. Work breakdown. Project schedule. Monitoring and reporting mechanisms.
7
Milestones & Deliverables Activities in a project should be
organised 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.
8
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.
9
Scheduling Challenges 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.
10
Bar charts & Activity Networks Graphical notations used to illustrate the
project schedule. Show project breakdown into tasks.
Tasks should not be too small. For example, they should take about a week or two.
Activity charts show task dependencies and the the critical path.
Bar charts show schedule against calendar time.
11
Task Durations & Dependencies
Task Duration (days) Dependencies
T1 8
T2 15
T3 10 T1
Component-A Design
Component-A Implementation
12
Progress from one Milestone to another.
Activity Network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
13
Activity Network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
Minimum time required to finishthe project. (critical path)
14
Activity Network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
Less chances of causing delayin project schedule.
15
Grantt Charts4/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
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11M8
T12
Start
Finish
Flexibility in completionDate
16
Staff Allocation 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
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
Specialists e.g Security Analyst
17
Risk Management Risk management is concerned with
identifying risks and drawing up plans to minimise 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 organisation developing
or procuring the software.
18
Risk Management - Example An experience Programmer leaves a
project. Project risk - possible delay in system
delivery. Product risk - Replacement may be less
experienced and more chances of errors. Business risk - Programmer’s experience is
not available for future products.
19
Risk Management Process
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
20
Risk Indicators
Risk type Potential indicators
Technology Late delivery of hardware or support software, many reportedtechnology problems
People Poor staff morale, poor relationships amongst team member,job availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints aboutCASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reporteddefects
21
Key Points Planning and estimating are iterative
processes which continue through out the course of a project.
Project scheduling involves preparing various graphical representations showing project activities, their durations and staffing.
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.
Recommended