Guidelines for the Selection and Tailoring of Processes
Selecting suitable life cycle processes is strategic, requiring flexibility, compliance, and alignment with standards like ISO/IEC/IEEE 24748-2. Key principles include risk-based rigor, tailoring, traceability, tool integration, and governance. Success depends on human factors, learning, reuse, and management support. Effective frameworks balance rigor with agility, using feedback, training, and pilot projects to ensure continuous improvement.
Fundamental Concepts
Selecting appropriate processes for use throughout the life cycle of systems is a strategic challenge for organizations. In many cases, ISO/IEC/IEEE 24748-2 is a useful resource for this challenge. The goal is to create a flexible, adaptable framework that ensures compliance, quality, and efficiency while allowing innovation and agility. This requires aligning with consensus standards, learning from past experience, and tailoring processes to project-specific needs.
Core Principles
When selecting system life cycle processes, consider the following principles:
- Risk and context: Process rigor should match system complexity, criticality, and regulatory environment. For example, a safety-critical avionics system requires more rigorous analysis and stringent verification than a home TV screen.
- Tailoring: Consider tailoring upfront, it will happen. In almost every project, the process framework needs to be tailored to the project-specific context, life cycle model and approach, with documented rationale. A process framework with tailoring guidelines is far more effective than a single, uniform process.
- Traceability: Most systems demand end-to-end traceability between requirements, design, implementation, verification results, and other artifacts.
- Tool and data integration: Processes can connect with product lifecycle management / application lifecycle management / configuration management (PLM/ALM/CM) tools to enable automation, audit trails, and reporting.
- Governance and accountability: Clear process ownership, change control boards, and role definitions prevent fragmentation and ensure accountability.
Additional topics of high relevance include:
- Human Factors and Organizational Aspects
- Competence Management: Processes are only as good as the people executing them. Skills matrices, role training, and certification of staff should be part of the process framework.
- Culture & Change Management: Process adoption depends strongly on company culture. Introducing new methods requires structured change management.
- Communication Interfaces: Most systems often involve multiple disciplines. Defined communication rules and cross-disciplinary forums are essential.
- Knowledge and Lessons Learned
- Organizational Learning: Processes should include structured mechanisms for capturing lessons learned, good practices, and failure analyses.
- Reuse & Reference Architectures: Reusable components, design patterns, and product and process reference architectures can dramatically reduce risk and cost, but only if processes explicitly encourage and govern reuse.
Good Practices
Implementing effective and efficient processes for most systems goes beyond compliance; practical approaches that teams can consistently follow are required. The following good practices provide some guidance, however, tailoring to different project types, technologies, and organizational contexts should be considered.
- Lightweight Process Frameworks: Identify and build around core processes (e.g., requirements, architecture, integration, verification, validation, configuration, risk management). Overly detailed process definitions are often ignored. Focus first on essential practices. Note that the optimal process “weight” depends on mission criticality and risk.
- Tailoring: Define decision criteria (e.g., size, safety level, novelty, mission criticality, certification needs) to select mandatory vs. optional activities and level of rigor. Ensure tailoring is documented; clear decision trees and real-world examples improve adoption and compliance.
- Risk-based Verification: Scale test rigor and independence according to risk and criticality.
- Supplier governance: Require suppliers to demonstrate compliance and maturity.
- Training & coaching: Adoption requires skilled practitioners and process champions.
- Measurement and feedback loops: Collect data on defects, requirements churn, and lead times to refine processes.
- Management support: When process compliance is supported and demanded by management, lengthy debates about necessity are avoided. All levels of the project should be able to see the benefit of performing the processes.
- Pilot projects: Test process changes in representative projects before full rollout.
- Effectiveness vs efficiency: Processes must be effective before they can be made efficient. Getting the wrong answer faster or cheaper doesn’t count.
- Process assurance: Life cycle processes form a basis for execution that avoids unintended omission, unnecessary activities and lack of discipline. For example, the project assessment and control process and decision management process provide for iterative incremental development that is at once responsive and disciplined.
Challenges
While a unified process framework offers consistency, in practice, no single process can perfectly fit every project or technology context. Differences in project size, complexity, regulatory requirements, and technology maturity can create conflicts that a single process cannot address. Typical challenges include:
- Scaling: Large programs can need more structure in their governance; small projects can leverage lean, flexible processes.
- Technology maturity: New technology requires experimentation; legacy products require strict control.
- Regulatory heterogeneity: Some domains demand exhaustive documentation, others allow leaner approaches.
- Organizational maturity: Processes that exceed a team’s capability can lead to noncompliance.
- Culture Change, Change Management: Noncompliance also results from not having a common vision regarding the necessity, not getting adequate training, not providing for effective transition from previous process approaches, etc.
- Contractual constraints: OEMs, regulators, or funding bodies may impose specific processes.
- Myths about processes: ISO/IEC/IEEE 15288 “does not prescribe a specific system life cycle model, development methodology, method, modelling approach or technique” (ISO/IEC/IEEE 15288:2023, Clause 1). The processes, activities and tasks in ISO/IEC/IEEE 15288 can be used with agile and other techniques with or without tailoring.
References
Works Cited
ISO/IEC/IEEE. 2023. Systems and software engineering — System life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2023.
ISO/IEC/IEEE. 2024. Systems and software engineering — Part 2: Guidelines for the application of ISO/IEC/IEEE 15288 (system life cycle processes). Geneva, Switzerland: International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 24748-2:2024.
Primary References
None
Additional References
None