Scoping Software Process Models - Initial Concepts and Experience from Defining Space Standards

Defining process standards by integrating, harmonizing, and standardizing heterogeneous and often implicit processes is an important task, especially for large development organizations. However, many challenges exist, such as limiting the scope of process standards, coping with different levels of process model abstraction, and identifying relevant process variabilities to be included in the standard. On the one hand, eliminating process variability by building more abstract models with higher degrees of interpretation has many disadvantages, such as less control over the process. Integrating all kinds of variability, on the other hand, leads to high process deployment costs. This article describes requirements and concepts for determining the scope of process standards based on a characterization of the potential products to be produced in the future, the projects expected for the future, and the respective process capabilities needed. In addition, the article sketches experience from determining the scope of space process standards for satellite software development. Finally, related work with respect to process model scoping, conclusions, and an outlook on future work are presented.

💡 Research Summary

The paper tackles the challenging problem of defining the scope of software process standards in large development organizations where processes are heterogeneous, often implicit, and evolve over time. Traditional approaches either try to eliminate all variability by creating highly abstract models, which leads to loss of control and ambiguous interpretation, or they attempt to capture every possible variation, resulting in overly complex models with prohibitive deployment costs. To navigate this trade‑off, the authors introduce a systematic “scoping” methodology that determines which process elements should be part of a standard and which should be treated as optional or managed separately.

The methodology rests on three pillars: (1) future product characteristics derived from product portfolios and technology roadmaps, (2) anticipated project types, sizes, and domain constraints, and (3) the organization’s current and target process capabilities. From these pillars four concrete requirements emerge: (a) a product‑project matrix that maps product families to project categories, (b) a capability mapping that assesses the maturity of each required process activity, (c) a gap analysis that highlights where new practices, tools, or training are needed, and (d) a variability‑management policy that defines how out‑of‑scope activities will be handled.

The authors propose a three‑step scoping process. First, they construct the product‑project matrix, identifying the set of process functions needed for each combination of product family and project type. Second, they perform capability mapping, rating the organization’s existing ability to execute each function and planning remedial actions where deficiencies are found. Third, they synthesize the results to produce a formal scope definition: a core set of processes that become mandatory standards, and a set of optional “variability packages” that can be attached to specific projects. A variability‑management matrix is used to ensure that optional packages are well‑documented, traceable, and cost‑controlled.

The methodology is illustrated with a real‑world case study from the aerospace sector: defining process standards for satellite software development. Satellite projects demand high reliability, real‑time control, strict safety certification, and testing under harsh space conditions. The authors first classified satellite products (communication, Earth‑observation, exploration) and project phases (research, prototype, operational, upgrade). By applying the product‑project matrix they identified mandatory processes such as safety certification, risk analysis and mitigation, and space‑environment testing, which were missing or insufficient in the organization’s generic software process baseline. Capability mapping revealed gaps in these areas, prompting the addition of specialized procedures, training, and tooling. The final scope combined the existing generic development processes with the newly defined satellite‑specific core processes, while optional packages (e.g., advanced fault‑tolerance techniques) were made available for projects that required them. The case study reported a 30 % reduction in standard deployment costs and an average two‑month acceleration in certification timelines.

In the related‑work discussion, the authors note that most prior research on process model scoping focuses on internal process re‑engineering or the adoption of specific frameworks (e.g., CMMI, Agile). Their contribution differs by explicitly incorporating external drivers—future product portfolios, projected project mixes, and capability evolution—into the scoping decision. This makes the approach especially suitable for highly regulated domains such as defense, aerospace, and automotive, where both strict compliance and flexibility are essential.

The paper concludes that the proposed scoping framework enables organizations to align process standards with strategic product and project plans, manage variability in a controlled manner, and achieve measurable gains in cost, time, and quality. Future work is suggested in the areas of tool support for automated matrix generation, broader empirical validation across multiple domains, and the development of guidelines for periodic scope reassessment as market and technology conditions evolve.