3. System of Interest
3
A system-of-interest is a collective set of all
elements of any system considered by a life
cycle. ( Source : SEBok )
The system whose life cycle is under
consideration. ( Source : ISO/IEC/IEEE 15288 )
The perception and definition of a particular system, its
architecture and its system elements depend on an
observer’s interests and responsibilities. One person’s
system of interest can be viewed as a system element in
another person’s system-of-interest. Conversely, it can be
viewed as being part of the environment of operation
for another person’s system-of-interest.
( Source : ISO/IEC/IEEE 15288 )
4. System Life Cycle
4
A life cycle for a system generally
consists of a series of stages
regulated by a set of
management decisions which
confirm that the system is mature
enough to leave one stage and
enter another
( Source : SEBoK)
( Source:NATO)
6. Perspectives of the same
problem
6
Judgment of how they should be balanced must come from a
deep understanding of how this system works
7. Origins of Systems Engineering
7
1937 British multidisciplinary team to analize the air defence system
1939-45 Bell Labs supports NIKE development ( 1st US operational anti-aircraft missile system )
and Intercontinental Ballistic Missiles (ICBM) Program.
1951-60 SAGE ( Semi-automatic Ground Enviroment ) Air Defense System defined and
managed by MIT/Jay Forrester
1956 Invention of systems analysis by RAND corp.
1960-70 Apollo Program
First SE standards ( e.g. MIL-STD 499, NASA procedures )
1962 Publication of Arthur D. Hall – A Methodology for Systems Engineering
1989 EIA recognizes SE as important part of system development
1990 NCOSE is founded
1990-2000 Release of SE standards IEEE 1220, EIA 632
1994 NCOSE renamed to INCOSE
2002 Release of ISO/IEC/IEEE 15288
2008 App. 6500 INCOSE members worldwide
2009-2012 Systems Engineering Body of Knowledge (SEBoK)
2019 17000+ INCOSE members worldwide (70+ Chapters 35+ Countries )
2023 INCOSE Systems Engineering Handbook version 5
14. What does it mean System Life Cycle
Management ( SLCM)
14
System performing a capability , needs a SoI in a mature organization
Life dynamic development of a system through Stages
Cycle cyclic workflow of Processes in Stages
Management Preparation and execution of decisions through tools
and methods; needs a process-oriented organization and defined
responsibilities.
( Source:NATO)
16. System Life Cycle Management ( SLCM)
in NATO
16
Effective SLCM produces a System and manages that
System through its operational life to fill a capability
gap!
( Source:NATO)
18. NATO SLCM Framework
18
A standardization agreement ( STANAG ) defines processes, procedures,
terms, and conditions for common military or technical procedures or
equipment between the member countries of the alliance.
Each NATO state ratifies a STANAG and implements it within their own
military.
( Source:NATO)
19. STANAG 4728
19
Modified on
16-05-2022
AAP-48 establishes a
common framework and
a set of processes and
terminology to be
applied in the acquisition
of NATO armament
systems.
AAP-20 establishes a
common framework and
a life cycle model to be
applied in the acquisition
of NATO armament
systems.
( Source:NATO)
20. Military Capability vs STANAG 4728
20
Date of ratification by Spain : 08/05/2015
Date of national implementation : 01/01/2018
( Source:NATO)
21. NATO Adoption of
ISO/IEC/IEEE 15288:2015
21
• Provides a common, integrated and broad framework for managing systems
throughout the life cycle ( applicable to any life cycle model )
• Defines a set of processes, concept and terminology
• Focuses on the “what”, not the “how”
NATO use ISO/IEC/IEEE 15288 as the
basis for implementing SLCM (to adopt
it for NATO purposes)
Technical and Technical Management
Processes are the focal point pillars for
NATO Life Cycle Processes
Agreement and Organizational
Project-Enabling processes are still
important, but with few NATO-specific
guidance needed
( Source:NATO)
22. ISO/IEC/IEEE 15288
22
To define the activities necessary to establish
an agreement between two organizations.
To define the requirements for a system, to
transform the requirements into an effective
product, to permit consistent reproduction of the
product where necessary, to use the product to
provide the required services, to sustain the
provision of those services and to dispose of the
product when it is retired from service.
To help ensure the organization’s capability
to acquire and supply products or services
through the initiation, support and control of
projects. They provide resources and
infrastructure necessary to support projects
To establish and evolve plans, to execute the plans, to assess
actual achievement and progress against the plans and to
control execution through to fulfillment. Individual Technical
Management Processes may be invoked at any time in the
life cycle and at any level
The Vee model is implemented within organizations
through the technical processes
V
23. Technical Processes ISO 15288 (i)
23
Business or mission analysis process
To define the business or mission problem or opportunity, characterize the solution space, and determine
the potential solution class(es) that could address a problem or take advantage of an opportunity
Stakeholder needs and requirement definition process
To define the stakeholder requirements for a system that can provide the capabilities needed by users and
other stakeholders in a defined environment
System requirement definition process
To transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution
that meets the operational needs of the user
Architecture definition process
To generate system architecture alternatives, to select one of more alternative(s) that frame stakeholder
concerns and meet system requirements, and to express this in a set of consistent views
Design definition process
To provide sufficient detailed data and information about the system and its elements to enable the
implementation consistent with architectural entities as defined in models and views of the system
architecture
System analysis process
To provide a rigorous basis for data and information for technical understanding to aid decision-making
across the life cycle
( Source: ISO 15288)
24. Technical Processes ISO 15288 (ii)
24
Implementation process
To realize a specified system element
Integration process
To synthesize a set of system elements into a realized system (product or service) that satisfies system
requirements, architecture, and design
Verification process
To provide objective evidence that a system or system element fulfills its specified requirements and
characteristics
Transition process
To establish a capability for a system to provide services specified by stakeholder requirements in the
operational environment
Validation process
To provide objective evidence that the system, when in use, fulfills its business or mission objectives and
stakeholder requirements, achieving its intended use in its intended operational environment
Operation process
To use the system to deliver its services
Maintenance process
To sustain the capability of the system to provide a service
Disposal process
To end the existence of a system element or system for a specified intended use, to appropriately handle
replaced retired elements, and to properly attend to identified critical disposal needs
( Source: ISO 15288)
25. Technical Management Processes ISO 15288
25
Project Planning process
To produce and coordinate effective and workable plans
Project Assessment and Control process
To assess if the plans are aligned and feasible; determine the status of the project, technical
and process performance; and direct execution to ensure that the performance is according to plans and
schedules, within projected budgets, to satisfy technical objectives.
Decision Management process
To provide a structured, analytical framework for objectively identifying, characterizing and evaluating a
set of alternatives for a decision at any point in the life cycle and select the most beneficial course of
action.
Risk Management process
To identify, analyze, treat and monitor the risks continually.
Configuration Management process
to manage and control system elements and configurations over the life cycle. CM also manages
consistency between a product and its associated configuration definition
Information Management process
To generate, obtain, confirm, transform, retain, retrieve, disseminate and dispose of information, to
designated stakeholders.
Measurement process
To collect, analyze, and report objective data and information to support effective management and
demonstrate the quality of the products, services, and processes
Quality Assurance process
To help ensure the effective application of the organization’s Quality Management process to the project
( Source: ISO 15288)
26. Organizational Project‐Enabling
Processes ISO 15288
26
Life Cycle Model Management process
To define, maintain, and assure availability of policies, life cycle processes, life cycle models, and
procedures for use by the organization.
Infrastructure Management process
To provide the infrastructure and services to projects to support organization and project objectives
throughout the life cycle.
Portfolio Management process
To initiate and sustain necessary, sufficient and suitable projects in order to meet the strategic objectives of
the organization.
Human Resource Management process
To provide the organization with necessary human resources and to maintain their competencies,
consistent with business needs
Quality Management process
is to assure that products, services and implementations of the quality management process meet
organizational and project quality objectives and achieve customer satisfaction.
Knowledge Management process
To create the capability and assets that enable the organization to exploit opportunities to re‐apply existing
knowledge.
27. Agreement Processes ISO 15288
27
Acquisition process
To obtain a product or service in accordance with the acquirer’s requirements.
Supply process
To provide an acquirer with a product or service that meets agreed requirements.
( Source: ISO 15288)
29. Alignment of Key Systems and Software
Engineering Standards
29
• In the past, Systems and Software standards have had different:
• Terminology
• Process sets
• Process structures
• Levels of prescription
• Audiences
• The problem has been exacerbated by competing standards, in whole
or part
• The Impact :
• Less effective/efficient processes, not focused on leveraging commonalities
– causes redundancy
• Less effective solutions not focused on a common approach to solve a
problem/need
( Source: INCOSE)
30. 30
ISO/IEC/IEEE 15288 “Systems and Software Engineering
- System Life Cycle Processes”
• A standard developed by the consensus of SE experts from
government, industry, and academia.
• Provides a common, comprehensive & integrated framework for
describing and managing the full life cycle of systems for:
• Small, medium and large organizations
• Internal self-imposed use, as well as providing a basis for contractual
arrangements (i.e., any agreement)
• Applicable to most domains
• Defines a set of processes and associated terminology
• Can be applied at any level in the hierarchy of a system across its life
cycle
• Applies to man-made systems configured with one or more of the
following:
• Hardware, software, humans, or processes
Systems Engineering Authoritative
References (i)
31. Systems Engineering Authoritative
References (ii)
31
The SE Body of Knowledge (SEBoK)
• Reflects the state-of-the-knowledge of Systems Engineering
• Provides a widely accepted, community-based, and regularly
updated baseline of systems engineering (SE) knowledge
• Based on ISO/IEC/IEEE 15288
The INCOSE SE Handbook (SEH)
• Reflects the state-of-the-good-practice of Systems Engineering
• Based on ISO/IEC/IEEE 15288
• Further elaborates the processes and activities to execute the
processes
• Serves as a reference of practices and methods that have
proven beneficial to the SE community at large
33. Benefits of Using ISO/IEC/IEEE 15288
33
Helps focus system management across the life cycle by providing:
• Insight into what should be assessed
• A holistic view of engineering the system (software, hardware, humans,
and processes)
• A process framework that:
• Is easy to tailor to meet project/organization needs
• Reduces risk across the life cycle
• A basis for:
• Stage-based life cycle models
• Communicating with all stakeholders
• Coordinating work
• Managing agreements
( Source: INCOSE)
34. Recommendations and pitfalls for the
introduction of SE
34
• Put SE on the management agenda and show enthusiasm
• Show the added value offered by SE and let someone with experience explain
the advantages
• Be aware and spread the notion that SE affects the entire organization
• Identify the competencies that are required based on project ( right people,
right training and education )
• Give staff room and time for training and development
• View the design as a whole
• Recognize that there are different SE roles
No experience yet ? Start with a pilot project
36. Need to adapt SE approaches
36
Only a successful tailoring of stages, processes and activities will
build the baseline to pass through a successful Project/program
( Source: NATO)
38. Global View of the Applicable Standards
38
ARP 4754 refers to, and complements, ARP 4761 by presenting a systems
engineering process model for airworthiness certification of aircraft, systems
and items. ARP4754 includes safety assessment of software and electronic
hardware, supported by DO-178 for software and DO-254 for electronic
hardware.
39. ARP 4754A Integral Process
39
Although ARP 4754 is focused on safety implications between the life cycle
processes, its weakness is it doesn’t provide enough detailed information for
each development elements like configuration management, requirements
management, system analysis, systems architecting, etc.
40. Systems Engineering Process and Safety
compliant with ARP 4754A
40
Safety assessments should start at the early stage of development. The
requirement definition phase is tightly coupled with the safety assessment
process. Safety requirements at all levels of system development should be
identified, and the implemented system/aircraft must meet those requirements.
ARP 4754A figure above shows how requirements are decomposed from higher
level to lower level and how safety is managed throughout the design life cycle
for airworthiness certification.
41. Airworthiness Certification
41
The aim of airworthiness certification is to argue that the aircraft is safe and in
compliance with the applicable safety requirements
Initial airworthiness assessment is primarily performed in the early stages of the
life cycle of an aircraft, but also revisited whenever an operational aircraft is
modified or needs to undergo a major repair that requires design.
42. ISO 15288 – Processes mention Safety
and link with ARP 4754
42
The use of ISO 15288 to support an EMAR 21 design assurance system has the potential to
increase the quality and efficiency of its airworthiness certification process. In particular,
the implementation of ISO 15288 has the potential to provide better communication,
better methodical and disciplined approach, improved information flow between
stakeholders, and a clearer picture of the responsibilities.
43. Recursion and Iteration of ISO 15288
Processes
43
Recursion occurs when a
process is applied to
successive levels of system
elements within a system
structure.
Iteration occurs when
processes are repeated at
the same system level.
44. Conclusions
44
• The application of Systems Engineering brings benefits to individual systems
performance and whole aircraft design and integration.
• There is a need to apply a Systems Engineering approach to the aircraft systems
as well as the avionics systems deployed by the aircraft and weapons systems in
the performance of its military role.
• The dimensions of cost and elapsed time to develop and build a system,
together with its inherent reliability and safety throughout its life, are also all
critically dependent on effective Systems Engineering from the outset, including
reduction of risks and optimization of the global life cycle cost.
• Projects will succeed or flounder on the basis of how well the Systems
Engineering approach has informed decision making relating to the definition of
responsibilities between, for example, customers and suppliers, industrial partners
or members of an alliance or team.
• Systems Engineering aims at implementing a top-down approach but also
making a provision for reuse in a bottom-up approach.
45. Conclusions
45
• Systems Engineering must embed the system safety effort into its processes from
the outset.
• EMAR 21 compliant military design organization must use Systems Engineering
and recognized system safety standards for civilian aircraft to create an
integrated process framework for efficient and effective airworthiness
certification of military aircraft.
• The ISO/IEC/IEEE 15288 is the most known Systems Engineering standard and
most other standards within the Systems Engineering domain rely on or refer to
this standard.
• Implementing these ISO/IEC/IEEE 15288 processes has the potential to improve
the operational effectiveness in the life cycle of a military air system.