Software Engineering Management

Chapter 9: Software Engineering Management

Acronyms

Acronym	Full Form
MBSE	Model-Based System Engineering
PMBOK Guide	Guide to the Project Management Body of Knowledge
PSM	Practical Software and Systems Measurement
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 (SEM) is the application of management activities—including planning, coordinating, measuring, monitoring, controlling, and reporting—to ensure that software products and services are delivered efficiently, effectively, and to the benefit of stakeholders. While it shares principles with other engineering management disciplines, SEM is distinct due to the unique nature of software.

Software’s primary challenges stem from it being an intangible and malleable logical construct. Unlike physical hardware, software can be modified with relative ease, which allows for a more iterative and interleaved development process. This flexibility, however, also introduces complexities:

Clients often don’t know exactly what they need or what is feasible.
Requirements are likely to change as understanding grows.
Software development must balance creativity and discipline.
The underlying technology changes at a high rate.

Since software is made by and for people, human factors are critical to a project’s success. Poor requirements or communication can cause even a highly skilled developer to produce a low-quality product.

SEM activities occur at three levels: organizational, project, and measurement program management. This knowledge area (KA) focuses on the latter two and is closely related to the Software Requirements, Software Configuration Management, Software Engineering Process, and Software Quality KAs.

Breakdown of Topics for Software Engineering Management

The breakdown of this KA is activity-based, rather than tied to a specific software development life cycle (SDLC) model. The choice of an SDLC—which exists on a continuum from predictive (e.g., Waterfall) to adaptive (e.g., Agile)—impacts how these activities are performed. Predictive models emphasize detailed upfront planning, while adaptive models embrace changing requirements and iterative cycles.

The major topics are:

Initiation and Scope Definition
Software Project Planning
Software Project Execution
Review and Evaluation
Closure
Software Engineering Measurement
Software Engineering Management Tools

1. Initiation and Scope Definition

This phase focuses on deciding whether to start a project by reviewing requirements and determining its need, scope, and feasibility.

1.1 Determination and Negotiation of Requirements

The primary goal is to determine and negotiate project requirements from all stakeholder perspectives through activities like elicitation, analysis, specification, and validation. These requirements form the basis for the project.

1.2 Feasibility Analysis

A feasibility analysis develops a clear description of project objectives and evaluates alternatives to find the best solution given technological, resource, and financial constraints. It produces an initial scope statement, estimates of resources and duration, and often an initial work breakdown structure (WBS).

1.3 Process for the Review and Revision of Requirements

Given that requirements inevitably change, stakeholders must agree on a formal process for how changes will be reviewed, approved, and incorporated. This process uses traceability analysis to understand the impact of any proposed changes on the project.

2. Software Project Planning

Planning involves selecting an appropriate SDLC, estimating effort and cost, allocating resources, and defining processes for managing risk and quality.

2.1 Process Planning

The project manager selects and tailors an SDLC model (e.g., waterfall, incremental, spiral, Agile) that fits the project’s scope, requirements, and risks. Relevant methods and tools for the entire project are also selected during planning.

2.2 Determine Deliverables

All work products for the project (e.g., design documents, test reports, source code) must be identified. This includes evaluating opportunities for software reuse and planning for any procurement of third-party components.

2.3 Effort, Schedule, and Cost Estimation

Estimation is challenging because software development is heavily dependent on human factors and a dynamic environment. Managers should use multiple methods, such as calibrated models based on historical data and bottom-up estimates from the development team, to arrive at a realistic figure. These estimates are used to create schedules (e.g., Gantt charts) and cost baselines, which are iteratively negotiated with stakeholders.

2.4 Resource Allocation

People, equipment, and facilities are assigned to project tasks. This allocation is constrained by resource availability and optimized based on team productivity and dynamics.

2.5 Risk Management

Risk is the effect of uncertainty on project objectives. Risk management is the process of identifying risks, analyzing their probability and impact, prioritizing them, and developing mitigation strategies. This information is often tracked in a risk register and should be revisited periodically throughout the project.

2.6 Quality Management

Quality management includes all activities that determine quality policies and responsibilities to ensure the project satisfies its intended needs. Key software quality attributes like safety, security, reliability, and performance must be identified, and acceptable thresholds for each should be defined.

2.7 Plan Management

The management of the project plan itself should be planned. All plans (for development, configuration management, documentation, etc.) must be systematically monitored, reviewed, and revised as needed to adapt to project realities.

3. Software Project Execution

During execution, the project plans are implemented and enacted. This phase is characterized by the ongoing activities of monitoring, controlling, and reporting progress.

3.1 Implementation of Plans

Project activities are carried out in accordance with the project plan, consuming resources and producing work products.

3.2 Software Acquisition and Supplier Contract Management

This involves managing contracts with both customers and suppliers. Software can be acquired in several ways:

Commercial off-the-shelf (COTS): An existing product bought “as is”.
Custom developed: Software built exclusively for the organization by another party.
Open source: Nominally free software, though it may have license restrictions or support costs.
Software as a service (SaaS): Rented software, such as a cloud-based development environment. Regardless of the method, all acquired components must be verified against requirements and integrated correctly.

3.3 Implementation of Measurement Process

The planned measurement process is put into action to ensure relevant project data is collected and analyzed.

3.4 Monitor Process

Progress is continually assessed against the project plan. This involves tracking effort, schedule, and cost, revisiting the project’s risk profile, and evaluating adherence to quality requirements. Variance analysis is used to compare actual outcomes against planned outcomes and identify deviations.

3.5 Control Process

Based on monitoring, decisions are made to take corrective actions, incorporate new activities, or revise project plans to accommodate unforeseen events. All changes must follow established software configuration control procedures.

3.6 Reporting

Project progress is communicated at agreed-upon intervals to internal and external stakeholders. Reports should be tailored to the information needs of the audience.

4. Software Review and Evaluation

At key points in the project, overall progress toward objectives and stakeholder satisfaction is evaluated. The effectiveness of processes, personnel, and tools is also assessed.

4.1 Determining Satisfaction of Requirements

Progress toward satisfying stakeholder requirements should be assessed periodically, typically at major milestones or at the end of an iterative cycle. Any variances from requirements must be identified and addressed.

4.2 Reviewing and Evaluating Performance

The project team’s performance should be reviewed periodically to identify potential difficulties. The effectiveness of the tools, methods, and processes used on the project should also be evaluated and changed if necessary.

5. Closure

A project, phase, or iteration is closed when all planned activities have been completed and success criteria have been met.

5.1 Determining Closure

Closure occurs when specified tasks are complete and stakeholders confirm that the completion criteria have been met. All stakeholders should formally accept the deliverables, and any known outstanding issues should be documented.

5.2 Closure Activities

After closure, project materials are archived according to agreed-upon procedures. Relevant project data is added to the organization’s measurement database. A retrospective analysis is performed to capture lessons learned, which are then fed back into the organization to improve future projects.

6. Software Engineering Measurement

Effective measurement is a cornerstone of mature software engineering, providing objective information for management decisions. The process described here is aligned with the ISO/IEC/IEEE 15939 standard.

6.1 Establish and Sustain Measurement Commitment

Successful measurement requires organizational commitment, demonstrated by:

Establishing clear measurement requirements tied to business objectives.
Defining the scope of the measurement effort (e.g., a single project or an entire enterprise).
Assigning resources, including funding, tools, training, and personnel, to implement the measurement process.

6.2 Plan the Measurement Process

The measurement plan should:

Characterize the organizational context (processes, domains, technology).
Identify information needs based on goals, risks, and problems.
Select measures that are clearly linked to the information needs.
Define procedures for data collection, storage, analysis, verification, and reporting.
Establish criteria for evaluating the resulting information products.

6.3 Perform the Measurement Process

The planned measurement procedures are integrated into the software processes. Data is collected (sometimes automatically), verified, stored, and analyzed to produce indicators (e.g., graphs, numbers) that are communicated to stakeholders.

6.4 Evaluate Measurement

The measurement process itself and its information products are evaluated to determine strengths and weaknesses. Feedback from users is gathered, lessons learned are recorded, and potential improvements are identified and communicated to stakeholders.

7. Software Engineering Management Tools

SEM tools provide visibility and control over management processes. They can be categorized as:

Project planning and tracking tools: Used to estimate effort and cost, prepare schedules (e.g., Gantt charts), and track milestones.
Risk management tools: Used to track and analyze risks, often with simulation (e.g., Monte Carlo) or decision trees.
Communication tools: Facilitate timely communication through tools like email notifications, meeting minutes, and progress charts.
Measurement tools: Support the data gathering, analysis, and reporting for a software measurement program, often using spreadsheets or more specialized software.