Software Project Management

1. Software
Project
Management
Software Engineering
ITS66404
This Photo by Unknown Author is licensed under CC BY-SA

2. Agenda
+ Project Management
+ Project Planning Process
+ Software Project Scheduling
+ Software Risk Management
+ Software Maintenance and
Reengineering
+ Tools
Sample footer text 3/1/20XX 2

3. Introduction
A Software Project is the
complete procedure of software
development from requirement
gathering to testing and
maintenance, carried out
according to the execution
methodologies, in a specified
period of time to achieve
intended software product.
Sample footer text 3/1/20XX 3
This Photo by Unknown Author is licensed under CC BY-SA

4. What is the differences between a
normal project and a software project?

5. Project
Management

6. Laws of Project Management
+ Projects progress quickly until they are 90% complete. Then they remain at 90%
complete forever.
+ When things are going well, something will go wrong. When things just can’t get
worse, they will. When things appear to be going better, you have overlooked
something.
+ If project content is allowed to change freely, the rate of change will exceed the
rate of progress.
+ Project teams detest progress reporting because it manifests their lack of
progress.

7. Software Project Management
7

8. How it should go vs How it went
Requirements
Analysis
D
E
L
A
Y
Vaporware

9. Software Project Management Plan
+ Software Project:
+ All technical and managerial activities required to deliver the deliverables to the client.
+ A software project has a specific duration, consumes resources and produces work products.
+ Management categories to complete a software project:
+ Tasks, Activities, Functions
+ Software Project Management Plan:
+ The controlling document for a software project.
+ Specifies the technical and managerial approaches to develop the software product.
+ Companion document to requirements analysis document: Changes in either may imply
changes in the other document.
+ SPMP may be part of project agreement.

10. Project Planning
Process

11. Project Agreement
+ Document written for a client that defines:
+ the scope, duration, cost and deliverables for the project.
+ the exact items, quantities, delivery dates, delivery location.
+ Can be a contract, a statement of work, a business plan, or a project charter.
+ Client: Individual or organization that specifies the requirements and accepts the project
deliverables.
+ Deliverables (= Work Products that will be delivered to the client):
+ Documents
+ Demonstrations of function
+ Demonstration of nonfunctional requirements
+ Demonstrations of subsystems

12. Project Management Activities
(continued on next slide)
Initiation
Project kickoff
Team formation Communication
infrastructure setup
Problem statement
definition
Initial milestones
planning
Initial top-level
design

13. Installation
Steady state
Termination
Client acceptance test Postmortem
Project agreement
Project replanning
Status monitoring Risk management
Project kickoff

14. Project: Functions, Activities and Tasks
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity a3:Activity
a2.1:Activity a2.2:Activity a2.3:Activity
t1:Task t2:Task t3:Task t4:Task

15. What do you need for project kick off?
Sample footer text 3/1/20XX 15

16. Functions
 Examples:
 Project management
 Configuration Management
 Documentation
 Quality Control (Verification and validation)
 Training
 Question: Is system integration a project function?
 Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral
processes in the IEEE 1074 standard. We call them cross-development processes

17. Tasks
 Smallest unit of management accountability
 Atomic unit of planning and tracking
 Finite duration, need resources, produce tangible result (documents, code)
 Specification of a task: Work package
 Name, description of work to be done
 Preconditions for starting, duration, required resources
 Work product to be produced, acceptance criteria for it
 Risk involved
 Completion criteria
 Includes the acceptance criteria for the work products (deliverables) produced by the task.

18. Task Sizes
 Finding the appropriate task size is
problematic
 To do lists from previous projects
 During initial planning a task is
necessarily large
 You may not know how to decompose
the problem into tasks at first
 Each software development activity
identifies more tasks and modifies
existing ones
 Tasks must be decomposed into
sizes that allow monitoring
 Work package usually corresponds
to well defined work assignment for
one worker for a week or a month.
 Depends on nature of work and
how well task is understood.

19. Examples of Tasks
 Unit test class “Foo”
 Test subsystem “Bla”
 Write user manual
 Write meeting minutes and post them
 Write a memo on NT vs Unix
 Schedule the code review
 Develop the project plan
 Related tasks are grouped into hierarchical sets of functions and activities.
 Action item

20. Action Item
 Definition: A task assigned to a person that has to be done within a week or less
 Action items
 Appear on the agenda in the Status Section (See lecture on communication)
 Cover: What?, Who?, When?
 Example of action items:
 Florian unit tests class “Foo” by next week
 Marcus develops a project plan before the next meeting
 Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon.
 The VIP team develops the project plan by Sep 18

21. Activities
 Major unit of work
 Culminates in major project
milestone:
 Internal checkpoint should
not be externally visible
 Scheduled event used to
measure progress
 Milestone often produces
baseline:
 formally reviewed work
product
 under change control
(change requires formal
procedures)
 Activities may be
grouped into larger
activities:
 Establishes hierarchical
structure for project
(phase, step, ...)
 Allows separation of
concerns
 Precedence relations
often exist among
activities (PERT Chart)

22. Examples of Activities
+ Major Activities:
+ Planning
+ Requirements Elicitation
+ Requirements Analysis
+ System Design
+ Object Design
+ Implementation
+ System Testing
+ Delivery
+ Activities during requirements
analysis:
+ Refine scenarios
+ Define Use Case model
+ Define object model
+ Define dynamic model
+ Design User Interface

23. Software Project
Scheduling

24. 24
Importance of Project Schedules
+ Managers often cite delivering projects on time as one of their biggest
challenges
+ Average time overrun from 1995 CHAOS report was 222%; improved to
163% in 2001 study
+ Time has the least amount of flexibility; it passes no matter what
+ Schedule issues are the main reason for conflicts on projects, especially
during the second half of projects

25. Software Project Scheduling
+ Project-task scheduling is a significant project planning activity. It comprises deciding
which functions would be taken up when. To schedule the project plan, a software
project manager wants to do the following:
1. Identify all the functions required to complete the project.
2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the
duration of the project.
25

26. 26
Project Time Management Processes
+ Project time management involves the processes required to
ensure timely completion of a project. Processes include:
+ Activity definition
+ Activity sequencing
+ Activity duration estimating
+ Schedule development
+ Schedule control

27. 27
Activity Definition
+ Project schedules grow out of the basic document that initiate a project
+ Project charter includes start and end dates and budget information
+ Scope statement and WBS help define what will be done
+ Activity definition involves developing a more detailed WBS and supporting
explanations to understand all the work to be done so you can develop realistic
duration estimates

28. 28
Activity Sequencing
+ Involves reviewing activities and determining dependencies
+ Mandatory dependencies: inherent in the nature of the work; hard logic
+ Discretionary dependencies: defined by the project team; soft logic
+ External dependencies: involve relationships between project and non-project activities
+ You must determine dependencies in order to use critical path analysis

29. 29
Project Network Diagrams
 Project network diagrams are the preferred technique for showing activity sequencing
 A project network diagram is a schematic display of the logical relationships among,
or sequencing of, project activities

30. 30
Figure 6-2. Sample Activity-on-
Arrow (AOA) Network Diagram for
Project X

31. 31
Precedence Diagramming Method (PDM)
 Activities are represented by boxes
 Arrows show relationships between activities
 More popular than ADM method and used by project management software
 Better at showing different types of dependencies

32. 32
Figure 6-3. Task Dependency Types

33. 33
Sample PDM Network
Diagram

34. 34
Activity Duration Estimating
+ After defining activities and determining their sequence, the next step in time
management is duration estimating
+ Duration includes the actual amount of time worked on an activity plus elapsed time
+ Effort is the number of workdays or work hours required to complete a task. Effort
does not equal duration
+ People doing the work should help create estimates, and an expert should review
them

35. 35
Schedule Development
 Schedule development uses results of the other time management processes to
determine the start and end date of the project and its activities
 Ultimate goal is to create a realistic project schedule that provides a basis for
monitoring project progress for the time dimension of the project
 Important tools and techniques include Gantt charts, PERT analysis, critical path
analysis, and critical chain scheduling

36. 36
Gantt Charts
+ Gantt charts provide a standard format for displaying project schedule information by
listing project activities and their corresponding start and finish dates in a calendar
format
+ Symbols include:
 A black diamond: milestones or significant events on a project with zero duration
 Thick black bars: summary tasks
 Lighter horizontal bars: tasks
 Arrows: dependencies between tasks

37. 37
Gantt Chart for
Software Launch
Project

38. 38
Milestones
 Milestones are significant events on a project that normally
have zero duration
 You can follow the SMART criteria in developing milestones
that are:
 Specific
 Measurable
 Assignable
 Realistic
 Time-framed

39. 39
Sample Tracking Gantt Chart

40. Project Risk
Management

41. Risk Management
 A risk is a problem that might occur (but hasn't yet)
 A risk changes to a problem at transition
 Mitigation is work done before transition to reduce the effect of
problem

42. Ways to handle risk
+ Risk discovery Brainstorming ( come up with lots of ways in which things can
go wrong)
+ , Scenario Building, Root Cause Analysis
+ Exposure analysis – How much it will cost if problem occurs?
Determine the loss associated with an event, likelihood of the event
Risk control - how much we can control the risk
+ Contingency planning
Determine how to contain a problem
+ Mitigation - Steps before transition to reduce the impact of a problem if it occurs
+ Transition monitoring - watch for the signals that a problem has occurred.
Q. Could you do mitigation before exposure analysis?
A. No, you need to know how much each risk will cost you before you can decide how
much effort you put into mitigation

43. Risk Mitigation

44. Risk Mitigation
+ How can you mitigate the following risks?
+ Car accident
+ Software Engineering module - Failure to submit assignment on due
date
+ Software Engineering module - Team member resigning/falling ill
+ Workplace - Team member resigning/falling ill

45. Risk Exposure

46. Risk Exposure
+ Expectation of containment cost
+ Risk exposure = Risk probability x Risk impact
+ 20% risk probability on $100,000 impact = $20,000 exposure
+ You can self insure against this exposure
+ Over a long period it should work out neutral

47. Risk reduction

48. 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

49. 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

50. Software
Maintenance &
Reengineering

51. Software Evolution Approaches
 There are a number of different strategies
for software change.
 Software maintenance
 Architectural transformation
 Software re-engineering.
 Software maintenance
 Changes to the software are made in
response to changed requirements but the
fundamental structure of the software
remains stable. This is most common
approach used to system change.
 Architectural transformation
 This is a more radical approach to software
change then maintenance as it involves
making significant change to the
architecture of the system.
 Software re-engineering
 This is different from other strategies in that
no new functionality is added to the system.
 System re-engineering may involve some
structural modifications but does not usually
involves major architectural change.

52. Software Maintenance
+ Software maintenance is the general process of changing a system after it
has been diverted.
+ The change may be simple changes to correct coding errors, more extensive
changes to correct design errors or significant enhancement to correct
specification error or accommodate new requirements.

53. Maintenance Characteristics
 We need to look at maintenance from three different
viewpoints:
 the activities required to accomplish the maintenance phase and the
impact of a software engineering approach (or lack thereof) on the
usefulness of such activities
 the costs associated with the maintenance phase
 the problems that are frequently encountered when software
maintenance is undertaken

54.  Maintenance to repair software faults
 Changing a system to correct deficiencies in the way meets its requirements
 Maintenance to adapt software to a different operating environment
 Changing a system so that it operates in a different environment (computer,
OS, etc.) from its initial implementation
 Maintenance to add to or modify the system’s functionality
 Modifying the system to satisfy new requirements
Types of Maintenance

55. Maintenance effort distribution .[SOM2004]
Fault repair
(17%)
software
adaption
(18%)
functionality
addition or
modification
(65%)

56. Maintenance Examples
 Y2K
 many, many systems had to be updated
 language analyzers (find where changes
need to be made)
 Anti-Virus Software
 don't usually have to update software, but
must send virus definitions
 Operating System Patching
 Microsoft, Apple, Linux/Unix
 OS is core to use of computer, so it
must be constantly maintained
 Commercial Software in General
 customers need to be informed of
updates
 updates have to be easily available -
web is good tool

57.  Re-structuring or re-writing part or all of a
legacy system without changing its
functionality
 Applicable where some but not all sub-systems
of a larger system require frequent
maintenance
 Re-engineering involves adding effort to make
them easier to maintain. The system may be re-structured and re-
documented
System Re-engineering

58.  When system changes are mostly confined to
part of the system then re-engineer that part
 When hardware or software support becomes
obsolete
 When tools to support re-structuring are
available
When to Re-engineer

59. Re-engineering Advantages
 Reduced risk
 There is a high risk in new software development. There may be
development problems, staffing problems and specification problems
 Reduced cost
 The cost of re-engineering is often significantly less than the costs of
developing new software

60. Forward Engineering and Re-engineering
Understanding and
transformation
Existing
software system
Re-engineered
system
Design and
implementation
System
specification
New
system
Software re-engineering
Forward engineering

61. The Re-engineering Process
Reverse
engineering
Program
documentation
Data
reengineering
Original data
Program
structure
improvement
Program
modularisation
Structured
program
Reengineered
data
Modularised
program
Original
program
Source code
translation

62. Re-Engineering Cost Factors
 The quality of the software to be re-engineered
 The tool support available for re-engineering
 The extent of the data conversion which is required
 The availability of expert staff for re-engineering

63. Tools
3/1/20XX
Sample footer text 63

64. Thank you
3/1/20XX 64

65. S.No Feature Software Project Ordinary Project
1 Tangible Not Tangible It is tangible
2 End Product Not clearly defined Very clearly defined
3 Production No fixed production plan, difficult to
monitor and track
Fixed production plan which can be
tracked
4 Productivity Productivity varies greatly with change
in technology or worker
Productivity does not vary much
5 Project Methodology Varies widely based on project Typically standard
6 Management methodology Managing a software project is more
managing interpersonal
communication and less
administration.
It is more about maintaining schedule
and good administration
7 Transfer of Ownership The transfer of software is tricky as the
organisation doesn’t own the hardware
which runs the software
Transfer is easy as the company own
the project till it hands over
8 Multitasking Difficult to multitask the resources Production resources can be used for
multiple projects
9 Personalisation It is very easy to change product as
per customer requirement at any time.
Can be personalized to a certain extent,
but difficult in the middle of the project
10 Leadership Software Projects need leaders and
managers, not just administrators.
A capable administrator is enough to
run an ordinary project.
Sample footer text 3/1/20XX 65