Difference between revisions of "Chapter 7: Software Engineering Management"

From SWEBOK
Jump to: navigation, search
(Initiation and Scope Definition)
(Software Project Planning)
Line 288: Line 288:
  
 
== Software Project Planning ==
 
== Software Project Planning ==
 +
 +
The first step in software project planning should
 +
be selection of an appropriate software development
 +
life cycle model and perhaps tailoring it
 +
based on project scope, software requirements,
 +
and a risk assessment. Other factors to be considered
 +
include the nature of the application domain,
 +
functional and technical complexity, and software
 +
quality requirements (see Software Quality
 +
Requirements in the Software Quality KA).
 +
 +
In all SDLCs, risk assessment should be an
 +
element of initial project planning, and the “risk
 +
profile” of the project should be discussed and
 +
accepted by all relevant stakeholders. Software
 +
quality management processes (see Software
 +
Quality Management Processes in the Software
 +
Quality KA) should be determined as part of the
 +
planning process and result in procedures and
 +
responsibilities for software quality assurance,
 +
verification and validation, reviews, and audits
 +
(see the Software Quality KA). Processes and
 +
responsibilities for ongoing review and revision
 +
of the project plan and related plans should also
 +
be clearly stated and agreed upon.
  
 
=== Process Planning ===
 
=== Process Planning ===
 +
 +
Software development life cycle (SDLC) models
 +
span a continuum from predictive to adaptive
 +
(see Software Life Cycle Models in the Software
 +
Engineering Process KA). Predictive SDLCs are
 +
characterized by development of detailed software
 +
requirements, detailed project planning, and
 +
minimal planning for iteration among development
 +
phases. Adaptive SDLCs are designed to
 +
accommodate emergent software requirements
 +
and iterative adjustment of plans. A highly predictive
 +
SDLC executes the first five processes
 +
listed in Figure 7.1 in a linear sequence with revisions
 +
to earlier phases only as necessary. Adaptive
 +
SDLCs are characterized by iterative development
 +
cycles. SDLCs in the mid-range of the
 +
SDLC continuum produce increments of functionality
 +
on either a preplanned schedule (on the
 +
predictive side of the continuum) or as the products
 +
of frequently updated development cycles
 +
(on the adaptive side of the continuum).
 +
 +
Well-known SDLCs include the waterfall,
 +
incremental, and spiral models plus various forms
 +
of agile software development [2] [3*, c2].
 +
 +
Relevant methods (see the Software Engineering
 +
Models and Methods KA) and tools should be
 +
selected as part of planning. Automated tools that
 +
will be used throughout the project should also
 +
be planned for and acquired. Tools may include
 +
tools for project scheduling, software requirements,
 +
software design, software construction,
 +
software maintenance, software configuration
 +
management, software engineering process, software
 +
quality, and others. While many of these
 +
tools should be selected based primarily on the
 +
technical considerations discussed in other KAs,
 +
some of them are closely related to the management
 +
considerations discussed in this chapter.
  
 
=== Determine Deliverables ===
 
=== Determine Deliverables ===
 +
 +
The work product(s) of each project activity (for
 +
example, software architecture design documents,
 +
inspection reports, tested software) should
 +
be identified and characterized. Opportunities to
 +
reuse software components from previous projects
 +
or to utilize off-the-shelf software products
 +
should be evaluated. Procurement of software
 +
and use of third parties to develop deliverables
 +
should be planned and suppliers selected (see
 +
section 3.2, Software Acquisition and Supplier
 +
Contract Management).
  
 
=== Effort, Schedule, and Cost Estimation ===
 
=== Effort, Schedule, and Cost Estimation ===
 +
 +
The estimated range of effort required for a project,
 +
or parts of a project, can be determined using
 +
a calibrated estimation model based on historical
 +
size and effort data (when available) and other
 +
relevant methods such as expert judgment and
 +
analogy. Task dependencies can be established
 +
and potential opportunities for completing tasks
 +
concurrently and sequentially can be identified
 +
and documented using a Gantt chart, for example.
 +
For predictive SDLC projects, the expected
 +
schedule of tasks with projected start times, durations,
 +
and end times is typically produced during
 +
planning. For adaptive SDLC projects, an overall
 +
estimate of effort and schedule is typically
 +
developed from the initial understanding of the
 +
requirements, or, alternatively, constraints on
 +
overall effort and schedule may be specified and
 +
used to determine an initial estimate of the number
 +
of iterative cycles and estimates of effort and
 +
other resources allocated to each cycle.
 +
 +
Resource requirements (for example, people
 +
and tools) can be translated into cost estimates.
 +
Initial estimation of effort, schedule, and cost is
 +
an iterative activity that should be negotiated and
 +
revised among affected stakeholders until consensus
 +
is reached on resources and time available
 +
for project completion.
  
 
=== Resource Allocation ===
 
=== Resource Allocation ===
 +
 +
Equipment, facilities, and people should be allocated
 +
to the identified tasks, including the allocation
 +
of responsibilities for completion of various
 +
elements of a project and the overall project.
 +
A matrix that shows who is responsible for,
 +
accountable for, consulted about, and informed
 +
about each of the tasks can be used. Resource
 +
allocation is based on, and constrained by, the
 +
availability of resources and their optimal use, as
 +
well as by issues relating to personnel (for example,
 +
productivity of individuals and teams, team
 +
dynamics, and team structures).
  
 
=== Risk Management ===
 
=== Risk Management ===
 +
 +
Risk and uncertainty are related but distinct concepts.
 +
Uncertainty results from lack of information.
 +
Risk is characterized by the probability of an
 +
event that will result in a negative impact plus a
 +
characterization of the negative impact on a project.
 +
Risk is often the result of uncertainty. The
 +
converse of risk is opportunity, which is characterized
 +
by the probability that an event having a
 +
positive outcome might occur.
 +
 +
Risk management entails identification of risk
 +
factors and analysis of the probability and potential
 +
impact of each risk factor, prioritization of
 +
risk factors, and development of risk mitigation
 +
strategies to reduce the probability and minimize
 +
the negative impact if a risk factor becomes a
 +
problem. Risk assessment methods (for example,
 +
expert judgment, historical data, decision trees,
 +
and process simulations) can sometimes be used
 +
in order to identify and evaluate risk factors.
 +
 +
Project abandonment conditions can also be
 +
determined at this point in discussion with all
 +
relevant stakeholders. Software-unique aspects
 +
of risk, such as software engineers’ tendency to
 +
add unneeded features, or the risks related to software’s
 +
intangible nature, can influence risk management
 +
of a software project. Particular attention
 +
should be paid to the management of risks
 +
related to software quality requirements such as
 +
safety or security (see the Software Quality KA).
 +
Risk management should be done not only at the
 +
beginning of a project, but also at periodic intervals
 +
throughout the project life cycle.
  
 
=== Quality Management ===
 
=== Quality Management ===
 +
 +
Software quality requirements should be identified,
 +
perhaps in both quantitative and qualitative
 +
terms, for a software project and the associated
 +
work products. Thresholds for acceptable quality
 +
measurements should be set for each software
 +
quality requirement based on stakeholder needs
 +
and expectations. Procedures concerned with
 +
ongoing Software Quality Assurance (SQA) and
 +
quality improvement throughout the development
 +
process, and for verification and validation of
 +
the deliverable software product, should also be
 +
specified during quality planning (for example,
 +
technical reviews and inspections or demonstrations
 +
of completed functionality; see the Software
 +
Quality KA).
  
 
=== Plan Management ===
 
=== Plan Management ===
 +
 +
For software projects, where change is an expectation,
 +
plans should be managed. Managing the
 +
project plan should thus be planned. Plans and
 +
processes selected for software development
 +
should be systematically monitored, reviewed,
 +
reported, and, when appropriate, revised. Plans
 +
associated with supporting processes (for example,
 +
documentation, software configuration management,
 +
and problem resolution) also should be
 +
managed. Reporting, monitoring, and controlling
 +
a project should fit within the selected SDLC and
 +
the realities of the project; plans should account
 +
for the various artifacts that will be used to manage
 +
the project.
  
 
== Software Project Enactment ==
 
== Software Project Enactment ==

Revision as of 15:42, 25 August 2015

Acronyms
PMBOK® Guide
Guide to the Project Management Body of Knowledge
SDLC
Software Development Life Cycle
SEM
Software Engineering Management
SQA
Software Quality Assurance
SWX
Software Extension to the PMBOK® Guide
WBS
Work Breakdown Structure
Introduction

Software engineering management can be defined as the application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting1—to ensure that software products and software engineering services are delivered efficiently, effectively, and to the benefit of stakeholders. The related discipline of management is an important element of all the knowledge areas (KAs), but it is of course more relevant to this KA than to other KAs. Measurement is also an important aspect of all KAs; the topic of measurement programs is presented in this KA.

In one sense, it should be possible to manage a software engineering project in the same way other complex endeavors are managed. However, there are aspects specific to software projects and software life cycle processes that complicate effective management, including these:

  • Clients often don’t know what is needed or what is feasible.
  • Clients often lack appreciation for the complexities inherent in software engineering, particularly regarding the impact of changing requirements.
  • It is likely that increased understanding and changing conditions will generate new or changed software requirements.
  • As a result of changing requirements, software is often built using an iterative process rather than as a sequence of closed tasks.
  • Software engineering necessarily incorporates creativity and discipline. Maintaining an appropriate balance between the two is sometimes difficult.
  • The degree of novelty and complexity is often high.
  • There is often a rapid rate of change in the underlying technology.

Software engineering management activities occur at three levels: organizational and infrastructure management, project management, and management of the measurement program. The last two are covered in detail in this KA description. However, this is not to diminish the importance of organizational and infrastructure management issues. It is generally agreed that software organizational engineering managers should be conversant with the project management and software measurement knowledge described in this KA. They should also possess some target domain knowledge. Likewise, it is also helpful if managers of complex projects and programs in which software is a component of the system architecture are aware of the differences that software processes introduce into project management and project measurement.

Other aspects of organizational management exert an impact on software engineering (for example, organizational policies and procedures that provide the framework in which software engineering projects are undertaken). These policies and procedures may need to be adjusted by the requirements for effective software development and maintenance. In addition, a number of policies specific to software engineering may need to be in place or established for effective management of software engineering at the organizational level. For example, policies are usually necessary to establish specific organization-wide processes or procedures for software engineering tasks such as software design, software construction, estimating, monitoring, and reporting. Such policies are important for effective long-term management of software engineering projects across an organization (for example, establishing a consistent basis by which to analyze past project performance and implement improvements).

Another important aspect of organizational management is personnel management policies and procedures for hiring, training, and mentoring personnel for career development, not only at the project level, but also to the longer-term success of an organization. Software engineering personnel may present unique training or personnel management challenges (for example, maintaining currency in a context where the underlying technology undergoes rapid and continuous change).

Communication management is also often mentioned as an overlooked but important aspect of the performance of individuals in a field where precise understanding of user needs, software requirements, and software designs is necessary. Furthermore, portfolio management, which provides an overall view, not only of software currently under development in various projects and programs (integrated projects), but also of software planned and currently in use in an organization, is desirable. Also, software reuse is a key factor in maintaining and improving productivity and competitiveness. Effective reuse requires a strategic vision that reflects the advantages and disadvantages of reuse.

In addition to understanding the aspects of management that are uniquely influenced by software projects, software engineers should have some knowledge of the more general aspects of management that are discussed in this KA (even in the first few years after graduation).

Attributes of organizational culture and behavior, plus management of other functional areas of the enterprise, have an influence, albeit indirectly, on an organization’s software engineering processes.

Extensive information concerning software project management can be found in the Guide to the Project Management Body of Knowledge (PMBOK® Guide) and the Software Extension to the PMBOK® Guide (SWX) [1] [2]. Each of these guides includes ten project management KAs: project integration management, project scope management, project time management, project cost management, project quality management, project human resource management, project communications management, project risk management, project procurement management, and project stakeholder management. Each KA has direct relevance to this Software Engineering Management KA.

Additional information is also provided in the other references and further readings for this KA.

This Software Engineering Management KA consists of the software project management processes in the first five topics in Figure 7.1 (Initiation and Scope Definition, Software Project Planning, Software Project Enactment, Review and Evaluation, Closure), plus Software Engineering Measurement in the sixth topic and Software Engineering Management Tools in the seventh topic. While project management and measurement management are often regarded as being separate, and indeed each does possess many unique attributes, the close relationship has led to combined treatment in this KA.

Unfortunately, a common perception of the software industry is that software products are delivered late, over budget, of poor quality, and with incomplete functionality. Measurement-informed management—a basic principle of any true engineering discipline (see Measurement in the Engineering Foundations KA)—can help improve the perception and the reality. In essence, management without measurement (qualitative and quantitative) suggests a lack of discipline, and measurement without management suggests a lack of purpose or context. Effective management requires a combination of both measurement and experience.

The following working definitions are adopted here:

  • Management is a system of processes and controls required to achieve the strategic objectives set by the organization.
  • Measurement refers to the assignment of values and labels to software engineering work products, processes, and resources plus the models that are derived from them, whether these models are developed using statistical

or other techniques [3* , c7, c8].

The software engineering project management sections in this KA make extensive use of the software engineering measurement section.

This KA is closely related to others in the SWEBOK Guide, and reading the following KA descriptions in conjunction with this one will be particularly helpful:

  • The Engineering Foundations KA describes some general concepts of measurement that are directly applicable to the Software Engineering

Measurement section of this KA. In addition, the concepts and techniques presented in the Statistical Analysis section of the Engineering Foundations KA apply directly to many topics in this KA.

  • The Software Requirements KA describes some of the activities that should be performed during the Initiation and Scope definition phase of the project.
  • The Software Configuration Management KA deals with identification, control, status accounting, and auditing of software configurations

along with software release management and delivery and software configuration management tools.

  • The Software Engineering Process KA describes software life cycle models and the relationships between processes and work products.
  • The Software Quality KA emphasizes quality as a goal of management and as an aim of many software engineering activities.
  • The Software Engineering Economics KA discusses how to make software-related decisions in a business context.
Breakdown of Topics for Software Engineering Management

Because most software development life cycle models require similar activities that may be executed in different ways, the breakdown of topics is activity-based. That breakdown is shown in Figure 7.1. The elements of the top-level breakdown shown in that figure are the activities that are usually performed when a software development project is being managed, independent of the software development life cycle model (see Software Life Cycle Models in the Software Engineering Process KA) that has been chosen for a specific project. There is no intent in this breakdown to recommend a specific life cycle model. The breakdown implies only what happens and does not imply when, how, or how many times each activity occurs. The seven topics are:

  • Initiation and Scope Definition, which deal with the decision to embark on a software engineering project;
  • Software Project Planning, which addresses the activities undertaken to prepare for a successful software engineering project from the management perspective;
  • Software Project Enactment, which deals with generally accepted software engineering management activities that occur during the execution of a software engineering project;
  • Review and Evaluation, which deal with ensuring that technical, schedule, cost, and quality engineering activities are satisfactory;
  • Closure, which addresses the activities accomplished to complete a project;
  • Software Engineering Measurement, which deals with the effective development and implementation of measurement programs insoftware engineering organizations;
  • Software Engineering Management Tools, which describes the selection and use of tools for managing a software engineering project.

1 Initiation and Scope Definition

The focus of these activities is on effective determination of software requirements using various elicitation methods and the assessment of project feasibility from a variety of standpoints. Once project feasibility has been established, the remaining tasks within this section are the specification of requirements and selection of the processes for revision and review of requirements.

1.1 Determination and Negotiation of Requirements

Determining and negotiating requirements set the visible boundaries for the set of tasks being undertaken (see the Software Requirements KA). Activities include requirements elicitation, analysis, specification, and validation. Methods and techniques should be selected and applied, taking into account the various stakeholder perspectives. This leads to the determination of project scope in order to meet objectives and satisfy constraints.

1.2 Feasibility Analysis

The purpose of feasibility analysis is to develop a clear description of project objectives and evaluate alternative approaches in order to determine whether the proposed project is the best alternative given the constraints of technology, resources, finances, and social/political considerations. An initial project and product scope statement, project deliverables, project duration constraints, and an estimate of resources needed should be prepared.

Resources include a sufficient number of people who have the needed skills, facilities, infrastructure, and support (either internally or externally). Feasibility analysis often requires approximate estimations of effort and cost based on appropriate methods (see section 2.3, Effort, Schedule, and Cost Estimation).

1.3 Process for the Review and Revision of Requirements

Given the inevitability of change, stakeholders should agree on the means by which requirements and scope are to be reviewed and revised (for example, change management procedures, iterative cycle retrospectives). This clearly implies that scope and requirements will not be “set in stone” but can and should be revisited at predetermined points as the project unfolds (for example, at the time when backlog priorities are created or at milestone reviews). If changes are accepted, then some form of traceability analysis and risk analysis should be used to ascertain the impact of those changes (see section 2.5, Risk Management, and Software Configuration Control in the Software Configuration Management KA).

A managed-change approach can also form the basis for evaluation of success during closure of an incremental cycle or an entire project, based on changes that have occurred along the way (see topic 5, Closure).

2 Software Project Planning

The first step in software project planning should be selection of an appropriate software development life cycle model and perhaps tailoring it based on project scope, software requirements, and a risk assessment. Other factors to be considered include the nature of the application domain, functional and technical complexity, and software quality requirements (see Software Quality Requirements in the Software Quality KA).

In all SDLCs, risk assessment should be an element of initial project planning, and the “risk profile” of the project should be discussed and accepted by all relevant stakeholders. Software quality management processes (see Software Quality Management Processes in the Software Quality KA) should be determined as part of the planning process and result in procedures and responsibilities for software quality assurance, verification and validation, reviews, and audits (see the Software Quality KA). Processes and responsibilities for ongoing review and revision of the project plan and related plans should also be clearly stated and agreed upon.

2.1 Process Planning

Software development life cycle (SDLC) models span a continuum from predictive to adaptive (see Software Life Cycle Models in the Software Engineering Process KA). Predictive SDLCs are characterized by development of detailed software requirements, detailed project planning, and minimal planning for iteration among development phases. Adaptive SDLCs are designed to accommodate emergent software requirements and iterative adjustment of plans. A highly predictive SDLC executes the first five processes listed in Figure 7.1 in a linear sequence with revisions to earlier phases only as necessary. Adaptive SDLCs are characterized by iterative development cycles. SDLCs in the mid-range of the SDLC continuum produce increments of functionality on either a preplanned schedule (on the predictive side of the continuum) or as the products of frequently updated development cycles (on the adaptive side of the continuum).

Well-known SDLCs include the waterfall, incremental, and spiral models plus various forms of agile software development [2] [3*, c2].

Relevant methods (see the Software Engineering Models and Methods KA) and tools should be selected as part of planning. Automated tools that will be used throughout the project should also be planned for and acquired. Tools may include tools for project scheduling, software requirements, software design, software construction, software maintenance, software configuration management, software engineering process, software quality, and others. While many of these tools should be selected based primarily on the technical considerations discussed in other KAs, some of them are closely related to the management considerations discussed in this chapter.

2.2 Determine Deliverables

The work product(s) of each project activity (for example, software architecture design documents, inspection reports, tested software) should be identified and characterized. Opportunities to reuse software components from previous projects or to utilize off-the-shelf software products should be evaluated. Procurement of software and use of third parties to develop deliverables should be planned and suppliers selected (see section 3.2, Software Acquisition and Supplier Contract Management).

2.3 Effort, Schedule, and Cost Estimation

The estimated range of effort required for a project, or parts of a project, can be determined using a calibrated estimation model based on historical size and effort data (when available) and other relevant methods such as expert judgment and analogy. Task dependencies can be established and potential opportunities for completing tasks concurrently and sequentially can be identified and documented using a Gantt chart, for example. For predictive SDLC projects, the expected schedule of tasks with projected start times, durations, and end times is typically produced during planning. For adaptive SDLC projects, an overall estimate of effort and schedule is typically developed from the initial understanding of the requirements, or, alternatively, constraints on overall effort and schedule may be specified and used to determine an initial estimate of the number of iterative cycles and estimates of effort and other resources allocated to each cycle.

Resource requirements (for example, people and tools) can be translated into cost estimates. Initial estimation of effort, schedule, and cost is an iterative activity that should be negotiated and revised among affected stakeholders until consensus is reached on resources and time available for project completion.

2.4 Resource Allocation

Equipment, facilities, and people should be allocated to the identified tasks, including the allocation of responsibilities for completion of various elements of a project and the overall project. A matrix that shows who is responsible for, accountable for, consulted about, and informed about each of the tasks can be used. Resource allocation is based on, and constrained by, the availability of resources and their optimal use, as well as by issues relating to personnel (for example, productivity of individuals and teams, team dynamics, and team structures).

2.5 Risk Management

Risk and uncertainty are related but distinct concepts. Uncertainty results from lack of information. Risk is characterized by the probability of an event that will result in a negative impact plus a characterization of the negative impact on a project. Risk is often the result of uncertainty. The converse of risk is opportunity, which is characterized by the probability that an event having a positive outcome might occur.

Risk management entails identification of risk factors and analysis of the probability and potential impact of each risk factor, prioritization of risk factors, and development of risk mitigation strategies to reduce the probability and minimize the negative impact if a risk factor becomes a problem. Risk assessment methods (for example, expert judgment, historical data, decision trees, and process simulations) can sometimes be used in order to identify and evaluate risk factors.

Project abandonment conditions can also be determined at this point in discussion with all relevant stakeholders. Software-unique aspects of risk, such as software engineers’ tendency to add unneeded features, or the risks related to software’s intangible nature, can influence risk management of a software project. Particular attention should be paid to the management of risks related to software quality requirements such as safety or security (see the Software Quality KA). Risk management should be done not only at the beginning of a project, but also at periodic intervals throughout the project life cycle.

2.6 Quality Management

Software quality requirements should be identified, perhaps in both quantitative and qualitative terms, for a software project and the associated work products. Thresholds for acceptable quality measurements should be set for each software quality requirement based on stakeholder needs and expectations. Procedures concerned with ongoing Software Quality Assurance (SQA) and quality improvement throughout the development process, and for verification and validation of the deliverable software product, should also be specified during quality planning (for example, technical reviews and inspections or demonstrations of completed functionality; see the Software Quality KA).

2.7 Plan Management

For software projects, where change is an expectation, plans should be managed. Managing the project plan should thus be planned. Plans and processes selected for software development should be systematically monitored, reviewed, reported, and, when appropriate, revised. Plans associated with supporting processes (for example, documentation, software configuration management, and problem resolution) also should be managed. Reporting, monitoring, and controlling a project should fit within the selected SDLC and the realities of the project; plans should account for the various artifacts that will be used to manage the project.

3 Software Project Enactment

3.1 Implementation of Plans

3.2 Software Acquisition and Supplier Contract Management

3.3 Implementation of Measurement Process

3.4 Monitor Process

3.5 Control Process

3.6 Reporting

4 Review and Evaluation

4.1 Determining Satisfaction of Requirements

4.2 Reviewing and Evaluating Performance

5 Closure

5.1 Determining Closure

5.2 Closure Activities

6 Software Engineering Measurement

6.1 Establish and Sustain Measurement Commitment

6.2 Plan the Measurement Process

6.3 Perform the Measurement Process

6.4 Evaluate Measurement

7 Software Engineering Management Tools