Skip to content

Software Project Management

Definition and Overview

Software Project Management involves the planning, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to full operational deployment. It is essential for avoiding project failure, as seen in various high-profile case studies.

The Management Spectrum (The 4 P’s)

Effective project management focuses on four critical factors:

  • People: This includes stakeholders such as senior managers, project managers, practitioners, customers, and end-users. Success depends on team factors like the difficulty of the problem, team lifetime, and the degree to which a project can be modularisation.
  • Product: Before planning, managers must establish the product scope (context, information objectives, and performance) and decompose the problem into manageable pieces.
  • Process: This involves a set of framework activities—communication, planning, modelling, construction, and deployment—supported by milestones and quality assurance points.

  • Project: This is the overall approach to maintaining momentum, tracking progress, and making smart decisions throughout the life cycle.

  • Start on the right foot

  • Maintain momentum
  • Track progress
  • Make smart decisions
  • Conduct a postmortem analysis

Organisational Paradigms

  • Closed Paradigm
  • Open Paradigm
  • Random Paradigm
  • Synchronous Paradigm

Case Studies of Project Failure

Analysing past failures helps identify common project management pitfalls:

  • FBI Virtual Case File System (2005): Abandoned after $170 million due to constant requirement changes, lack of clear planning, and poor communication.
  • Denver International Airport Baggage System: Failed during testing because requirements kept changing, features were added late, and there was a lack of incremental development.
  • Healthcare.gov Launch: Experienced frequent crashes because too many contractors worked independently, there was no end-to-end testing, and team coordination was poor.

The W5HH Principle for Project Planning

Barry Boehm proposed seven questions that serve as a foundation for project planning:

  1. Why is the system being developed?.
  2. What will be done?.
  3. When will it be done?.
  4. Who is responsible for a function?.
  5. Where are they located organizationally?.
  6. How will the job be done technically and managerially?.
  7. How much of each resource is needed?.

Software Measurement and Metrics

Metrics are used to provide insight into the software process and the project.

Types of Measures

  • Direct Measures: Include costs and human effort.
  • Indirect Measures: Include functionality, quality, complexity, efficiency, and maintainability.

Hierarchy of Metrics

  • Product Metrics: Private to individual practitioners; these are often combined to create project metrics.
  • Project Metrics: Used by a software team to assess quality on an ongoing basis and minimize development schedules by avoiding delays.
  • Process Metrics: Consolidated from project metrics to provide long-term improvement for the software organization as a whole.

Specific Metrics Categories

  • Function-Based Metrics (Function Points): Basically predicting the size of resultant product. A means for measuring the functionality delivered by a system. These are calculated by counting external inputs, outputs, inquiries, internal logical files, and external interface files.
  • Number of external inputs - Originates from a user or another application to your application
  • Number of external outputs - Each external output is derived data within the application that provides information to the user - reports, screens, error messages etc.
  • Number of external inquiries - An online input that results in generation of some immediate software response in form of output
  • Number of internal logical files - Each internal logical file is a logical grouping of data that resides in application
  • Number of external interface files - Each external interface file is a logical grouping of data that results external to the application but provides information that may be of use to the application.

Step 1: Unadjusted Function Points (UFP)

Sum of (Number of elements $\times$ Complexity Weight) for the 5 categories: - External Inputs (I) - External Outputs (O) - External Inquiries (E) - Internal Logical Files (F) - External Interface Files (N)

$$UFP = (I \cdot w_I) + (O \cdot w_O) + (E \cdot w_E) + (F \cdot w_F) + (N \cdot w_N)$$

Step 2: Complexity Adjustment Factor (CAF)

Based on the sum of 14 influence factors ($\sum F_i$): $$CAF = 0.65 + 0.01 \left( \sum_{i=1}^{14} F_i \right)$$

Step 3: Final Function Point

$$FP = UFP \times CAF$$ https://www.geeksforgeeks.org/software-engineering/software-engineering-functional-point-fp-analysis/

  • Metrics for Specification Quality

$$n_r = n_f + n_{nf}$$

$$Q_1 = n_{UI} / n_n$$ $$Q_2 = n_u / (n_i * n_s)$$ - Metrics for the Design Model: These evaluate structural complexity, data complexity, and overall system complexity.

Structural Complexity ($S_i$): Relates to the square of the Fan-out. $$S_i = f_{out}^2(i)$$

Data Complexity ($D_i$): Relates to the number of variables $v(i)$ per interface. $$D_i = \frac{v(i)}{f_{out}(i) + 1}$$

Total System Complexity ($C_i$): The combined metric for the design model. $$C(i) = S(i) + D(i)$$ - Metrics for Source Code (Halstead’s Theory): These use the number of distinct operators and operands to measure program length, volume, level, and effort.

Vocabulary: $n = n_1 + n_2$ Total Size: $N = N_1 + N_2$

Calculated Length ($N$): $$N = n_1 \log_2 n_1 + n_2 \log_2 n_2$$

Volume ($V$): $$V = N \log_2 (n_1 + n_2)$$

Difficulty ($D$): $$D = \frac{n_1}{2} \times \frac{N_2}{n_2}$$

Effort ($E$): $$E = V \times D$$ - Metrics for Maintenance (Software Maturity Index): The SMI provides an indication of product stability by tracking the number of modules added, changed, or deleted in a release.

$$SMI = M_t + (F_c + F_a + F_d) \space / \space M_t$$