Difference between revisions of "Agile Systems Engineering"
(New content) Tag: visualeditor |
(Continue adding new content.) Tag: visualeditor |
||
| Line 1: | Line 1: | ||
---- | ---- | ||
| − | '''''Lead Author:''''' '' | + | '''''Lead Author:''''' ''Phyllis Marbach'' |
---- | ---- | ||
| − | For a system, a | + | For a system, a [[Life Cycle (glossary)|life cycle]] usually starts at the concept definition phase, moves through stages until completion of this system, as defined in the concept definition stage. A [[Model (glossary)|model]] of the life cycle may be a physical, data or graphic representation of that life cycle. The [[Process (glossary)|process]] describes the steps to accomplish each stage of the life cycle including input to and output from this stage. Today’s complex and increasingly highly connected systems face rapid obsolescence under the stress of technological change, environmental change, and rapidly evolving mission needs. For these systems to remain robust against disruption they must be architected to agilely adapt. To meet these needs, the system must be assessed to apply the process that best serves the system, subsystem or component of the [[System-of-Interest (glossary)|system of interest]] (SOI). |
| − | == | + | It is important to determine the best life cycle to use for the SOI early in the concept definition phase. On a program that is going to operate agilely, especially if it will be a hybrid model with agile, and other life cycle models it is important to define and harmonize them at key integration points based on hardware or other long-lead item maturity. |
| + | |||
| + | In the Agile SE process, the systems engineer works in an iterative, incremental manner, continually modeling, analyzing, developing, and trading options to bring the definition of the system solution into focus. An example of this work will be analyzing and maintaining not only the requirements but also the architectural model of the higher-level requirements and the linkage from those high-level requirements to the analyzed lower-level requirements. In addition to the requirements and architecture representations, maintaining and verifying the interfaces are defined and followed as the development progresses are some of the systems engineers’ tasks. These responsibilities of systems engineers are the same regardless of the life cycle, although sequencing and organization may be different. Program leadership, systems engineering, and all team members work in a culture that represents an Agile Mindset. The Agile Mindset is a combination of beliefs and actions from agile values that include focusing on delivering working capabilities often, trusting the knowledge workers to find the best solution, improving the product and process through regular demonstrations and retrospections, planning often to implement lessons learned. | ||
| + | |||
| + | ==Principles for Agile Development== | ||
| + | Principles for Agile Development [Marbach, et al] provide a foundation for the working relationship across cross-functional teams that include Systems and Software Engineers working on customer projects that include both hardware development and software development. These principles, in Table 1, are a modified version that originated from the Agile Manifesto (Beck, et. al.) and were expanded to apply to systems engineering. Adopting these principles will enable teams of teams to produce high-value capabilities incrementally. | ||
| + | {| class="wikitable" | ||
| + | |+ | ||
| + | !'''Principles for Agile Development (Marbach, et. al.)''' | ||
| + | !'''SEBoK Traditional SE Principles''' | ||
| + | |- | ||
| + | |First, satisfy the customer through early and continuous delivery of valuable capabilities. | ||
| + | |1. SE in application is specific to stakeholder needs, solution space, resulting system solution(s), and context throughout the system life cycle. | ||
| + | |||
| + | |||
| + | 8. SE addresses stakeholder needs, taking into consideration budget, schedule, and technical needs, along with other expectations and constraints. | ||
| + | |- | ||
| + | |2. Plan for evolving requirements, and retain as much flexibility as is valuable throughout development; agile processes harness change for the customer, especially when change leads to a competitive advantage. | ||
| + | |7. Stakeholder needs can change and must be accounted for over the system life cycle. | ||
| + | |||
| + | |||
| + | 9. SE decisions are made under uncertainty accounting for risk. | ||
| + | |- | ||
| + | | | ||
| + | | | ||
| + | |} | ||
==References== | ==References== | ||
Revision as of 22:37, 27 April 2022
Lead Author: Phyllis Marbach
For a system, a life cycle usually starts at the concept definition phase, moves through stages until completion of this system, as defined in the concept definition stage. A model of the life cycle may be a physical, data or graphic representation of that life cycle. The process describes the steps to accomplish each stage of the life cycle including input to and output from this stage. Today’s complex and increasingly highly connected systems face rapid obsolescence under the stress of technological change, environmental change, and rapidly evolving mission needs. For these systems to remain robust against disruption they must be architected to agilely adapt. To meet these needs, the system must be assessed to apply the process that best serves the system, subsystem or component of the system of interest (SOI).
It is important to determine the best life cycle to use for the SOI early in the concept definition phase. On a program that is going to operate agilely, especially if it will be a hybrid model with agile, and other life cycle models it is important to define and harmonize them at key integration points based on hardware or other long-lead item maturity.
In the Agile SE process, the systems engineer works in an iterative, incremental manner, continually modeling, analyzing, developing, and trading options to bring the definition of the system solution into focus. An example of this work will be analyzing and maintaining not only the requirements but also the architectural model of the higher-level requirements and the linkage from those high-level requirements to the analyzed lower-level requirements. In addition to the requirements and architecture representations, maintaining and verifying the interfaces are defined and followed as the development progresses are some of the systems engineers’ tasks. These responsibilities of systems engineers are the same regardless of the life cycle, although sequencing and organization may be different. Program leadership, systems engineering, and all team members work in a culture that represents an Agile Mindset. The Agile Mindset is a combination of beliefs and actions from agile values that include focusing on delivering working capabilities often, trusting the knowledge workers to find the best solution, improving the product and process through regular demonstrations and retrospections, planning often to implement lessons learned.
Principles for Agile Development
Principles for Agile Development [Marbach, et al] provide a foundation for the working relationship across cross-functional teams that include Systems and Software Engineers working on customer projects that include both hardware development and software development. These principles, in Table 1, are a modified version that originated from the Agile Manifesto (Beck, et. al.) and were expanded to apply to systems engineering. Adopting these principles will enable teams of teams to produce high-value capabilities incrementally.
| Principles for Agile Development (Marbach, et. al.) | SEBoK Traditional SE Principles |
|---|---|
| First, satisfy the customer through early and continuous delivery of valuable capabilities. | 1. SE in application is specific to stakeholder needs, solution space, resulting system solution(s), and context throughout the system life cycle.
|
| 2. Plan for evolving requirements, and retain as much flexibility as is valuable throughout development; agile processes harness change for the customer, especially when change leads to a competitive advantage. | 7. Stakeholder needs can change and must be accounted for over the system life cycle.
|
References
Works Cited
None.
Primary References
None.
Additional References
None.