Chapter 9
Project Management
Introduction

Effective project management requires a
well-structured project and diligent
oversight
 A well-structured project consists of a
series of finite, effective, well-defined
tasks
 The phases of a software development
methodology define the tasks to be
managed to some extent
Project Management
Responsibilities

Establish project schedule

Establish project budget

Structure the project into units of work

Assemble the project team

Assign units of work to individuals

Determine necessary resources

Carry out risk assessment

Monitor progress of project

Ensure resulting system meets requirements
Software Metrics

Reasons to measure software:
– To facilitate estimation of development time
– To assess the productivity of developers
– To assess the quality of the project
 Current schools of thought:
– Size-oriented
– Function-oriented
– Object-oriented
Size-oriented Metrics

Attempt to quantify software projects by
using the size of the project to normalize
other quality measures
 Possible data to collect:
–
–
–
–
–
–
number of lines of code
number of person-months to complete
cost of the project
number of pages of documentation
number of errors corrected before release
number of bugs found post release
Problems with using Lines
of Code (LOC) as Metric

Lines of source code comprising a project
are not always good gages to the size and
complexity of a project:
– LOC to complete a task is language dependent
– Code reuse reduces LOC but requires more effort,
thus well-design system are penalized
– Using a LOC based metric encourages
programmers to create more LOC, which is
ultimately less efficient to maintain
Function-Oriented Metrics

Attempt to measure the functionality of a
software system
 Use a unit of measure called function
point
 Some possible function points:
–
–
–
–
–
–
Internal data structures
External data structures
User inputs
User outputs
Transformations
Transitions
Issues with Using FunctionOriented Metrics

Requires that analysis and design of a
project are completed before workload
estimation can occur
 Validity of the workload estimation is
limited to the accuracy of the analysis and
design
 Complexity determination of function
points is subjective
Object-Oriented Metrics

Suggested measurements for objectoriented systems:
– Number of scenario scripts
– Number of key classes
– Number of subsystems
 Disadvantages:
– Excludes a history-base of non-objectoriented projects
Quality Control Metrics

Correctness
– Defects per thousand LOC
 Maintainability
– Mean time to change
 Integrity
– Likelihood of thwarting an attack
 Usability
– Skill required of users
– Time required to become proficient
– Net increase in productivity
– Users’ attitude toward system
Other Project Management
Concepts
Mythical staff-month
 Configuration management
 Change control
 Configuration Audit
 Configuration status reporting

Project Planning

Project planning requires:
– Defining the iterations of the project
– Specifying subtasks
– Determining the project schedule and allocating
time for each subtask
– Associating deliverables with each subtask to
verify progress
– Dividing the subtasks among the developers
– Scheduling any interdependent tasks to minimize
delays - use task network or PERT chart
Monitoring Project Progress

Develop project milestones with
associated deliverables to gage progress
 Milestones should be created so that the
project manager receives sufficient
feedback at regular intervals
 The feedback should take the form of a
natural artifact of the development
process
 See figure 9.9 for a list of deliverables
Four Stages of Team
Development
Forming
 Storming
 Norming
 Performing

Conflict Resolution
Strategies







Arbitration
Rules and regulations
Confrontation
Negotiation
Separation
Neglect
Coordination device
Risk Management

Risk management provides a structured
evaluation of a development project to draw
attention to sources of risk
 The need for risk management is
demonstrated by the high failure rate for
large-scale software development initiatives
 Successful project management relies on
the additional time that is built into the
development schedule to accommodate
some level of delay due to risk factors
What is Risk?

A risk is any unanticipated condition or
event that causes one or more tasks to be
delayed, lengthened, or fail

Risks can delay or prevent the completion
of a task or project as a whole

Two very general categories of risk will be
identified here, technical and human risk
Sources of Technical Risk









Project complexity
Project size
Use of state-of-the-art technology
Network vulnerability
Disgruntled employees
Potential for white-collar crime
Data attainability
Accuracy of data source
Need for high-quality graphics
Sources of Human Risk


Development team
– Productivity
– Experience
– Knowledge
– Dedication
End users
– Technical knowledge
– Support for project
– Agreement on
system

Administration
– Budgetary
constraints
– Project priority
– Realistic
expectations
Consequences of Risk
Delay project
 Compromise the quality of the
project
 Cause the project to fail
 Cause the project to be too
expensive to implement or run

Reducing Risk
Early project evaluation
 Early implementation of risky system
aspects
 Early use of new technology
 Early resolution of class interaction
problems
