CHAP:10 – software project management
Software
project management begins with a set of activities that are collectively called
project planning.
THE MANAGEMENT SPECTRUM
Effective software project management
focuses on the four P’s: people,
product, process, and project.
The People:
· The
cultivation of motivated, highly skilled software people has been discussed
since the 1960s (e.g., [COU80], [WIT94], [DEM98]).
· The
people management maturity model defines the following key practice areas for
software people: recruiting, selection, performance management, training,
compensation, career development, organization and work design, and
team/culture development
The Product:
· Before
a project can be planned, product1 objectives and scope should be established,
alternative solutions should be considered, and technical and management
constraints should be identified.
· Without this information, it is impossible to
define reasonable (and accurate) estimates of the cost, an effective assessment
of risk, a realisticbreakdown of project tasks, or a manageable project
schedule that provides a meaningfulindication of progress.
· The
software developer and customer must meet to define product objectives
andscope.
· Scope
identifies the primary data, functions and behaviors that characterizethe
product, and more important, attempts to bound these
characteristics in a quantitative manner.
· Once
the product objectives and scope are understood, alternative solutions
areconsidered.
The Process:
· A
software process provides the framework from which a comprehensive plan for
software development can be established.
· A small number of framework activities are
applicable to all software projects, regardless of their size or complexity.
· A
number of different task sets—tasks, milestones, work products, and quality
assurance points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project
team.
· Finally,umbrella
activities—such as software quality assurance, software configuration
management, and measurement—overlay the process model.
· Umbrella
activities are independent of any one framework activity and occur throughout
the process.
The Project:
· We
conduct planned and controlled software projects for one primary reason—it is the
only known way to manage complexity. And yet, we still struggle.
· In 1998, industry data indicated that 26 percent
of software projects failed outright and 46 percent experienced cost and
schedule overruns [REE99].
· Although
the success rate for software projects has improved somewhat, our project
failure rate remains higher than it should be.2
· In
order to avoid project failure, a software project manager and the software
engineers who build the product must avoid a set of common warning signs,
understand the critical success factors that lead to good project management,
and develop a commonsense
· approach
for planning, monitoring and controlling the project.
THE W5HH PRINCIPLE:
· In
an excellent paper on software process and projects, Barry Boehm [BOE96]
states:
· “you
need an organizing principle that scales down to provide simple [project] plans
for simple projects.” Boehm suggests an approach that addresses project
objectives, milestones and schedules, responsibilities, management and
technical approaches, and required resources.
· He
calls it the WWWWWHH principle, after a series of questions that lead to a
definition of key project characteristics and the resultant project plan:
· Why
is the system being developed?
The
answer to this question enables all parties to assess the validity of business
reasons for the software work. Stated in another way, does the business purpose
justify the expenditure of people, time, and money?
· What
will be done, by when?
The answers to these questions help the team to establish a
project schedule by identifying key project tasks and the milestones that are
required by the customer.
· Who
is responsible for a function?
we noted that the role and responsibility of each member of the
software team must be defined.
· Where
are they organizationally located?
Not all roles and responsibilities reside within the software
team itself. The customer, users, and other stakeholders
also have responsibilities.
· How
will the job be done technically and managerially? Once
product scope is established, a management and technical strategy for the
project must be defined.
· How
much of each resource is needed?
The answer to this question is derived by developing
estimates based on answers
to earlier questions.
No comments:
Post a Comment