Page 20 -

1 - INTRODUCTION

processes makes software teamwork different in kind from teamwork in other engineering disciplines. As
a result, many of the procedures and techniques used in software project management are designed to
facilitate communication and coordination among team members engaged in closely coordinated, intellect-
intensive work.

Accurate planning and estimation of cost and schedule is difficult for all kinds of projects, but it is particularly
difficult for software projects because: (1) software is developed and modified by the cognitive work activities of
the developers, (2) productivity among individual software developers varies widely (in both quantity and quality
of work), (3) requirements upon which estimates are based are often poorly defined, and (4) continuing evolution of
technology may make historical data inaccurate for new projects. For these reasons, current software development
methods tend to focus on developing an expanding set of product increments so that tradeoffs among schedule,
budget, resources, functionality, and quality attributes can be continually adjusted.

Productivity in software projects includes both quantity and quality of work. The amount of software written
(i.e., number of lines of code) is not a good measure of programmer productivity; a programmer who writes a
small, efficient program is more productive in contributing to a successful outcome than a programmer who
writes a large, inefficient program. Similarly, a programmer who rushes through a task but makes many mistakes
that will require corrective rework is less productive than a programmer who proceeds more slowly but produces
a program that has fewer defects. Productivity of programmers with similar backgrounds and experience, as
measured by quantity and quality of the resulting software, has been repeatedly demonstrated to vary by factors
of 10 and more [8, 9].

With the advent of widespread interconnectivity, software security has become a major consideration when
building or modifying a software product. Like other quality attributes, security attributes need to be planned,
designed, constructed, verified, and validated. Like other quality attributes, software security cannot be “tested in.”
Software projects are also difficult because software is always part of a system. Software as a stand-
alone entity is useless; to be of use, software is executed on digital hardware. In some cases, a software
project is one element of a development program that involves the accompanying development of hardware
components or development of related software by other projects. In other cases, development of software
may be limited to developing application software for a population of known users. In these cases, the
system includes specified computer, operating system, and programming language or languages to provide
the needed capabilities.

1.4 Relationships with Program and Portfolio Management

®
The information in Section 1.4 of the PMBOK Guide is equally applicable to software projects and their
relationships with program and portfolio management.

The relationships among projects, programs, and portfolios are illustrated in Figure 1-1.

8 ©2013 Project Management Institute. Software Extension to the PMBOK Guide Fifth Edition
®