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 Function-Oriented 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 object-oriented systems:– Number of scenario scripts– Number of key classes– Number of subsystems

Disadvantages:– Excludes a history-base of non-object-

oriented 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-monthConfiguration managementChange controlConfiguration AuditConfiguration 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

FormingStormingNormingPerforming

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 projectCompromise the quality of the

projectCause the project to failCause the project to be too

expensive to implement or run

Reducing Risk

Early project evaluation Early implementation of risky system

aspectsEarly use of new technologyEarly resolution of class interaction

problems