2003, northrop grumman corporation fundamentals of se objectives after completing this module, you...
TRANSCRIPT
2003, Northrop Grumman Corporation
Fundamentals of SE Objectives
After completing this module, you will be able to:
Define key Systems Engineering concepts and terms
Explain the role of a Systems Engineer
Explain how Systems Engineering is enabled at TASC
Explain what a life cycle is and approaches to selecting life cycles
Explain the importance and use of tailored processes
2003, Northrop Grumman Corporation
What is a System?
System: Integrated set of interrelated components that interact in an organized fashion toward a common objective
Systems Thinking: Taking a “big picture” or holistic view of large-scale and complex problems and their proposed solutions
Systems can be classified by their purpose:
Product-oriented Service-oriented Process-oriented
Can you identify some other examples?
2003, Northrop Grumman Corporation
Every System has Subsystems
Because systems are inherently complex, systems can be better understood by organizing their parts into hierarchies and groups based on function
Virtually every system can be broken down into segments, subsystems, components,…
Relationships among the components are what give systems their added value
Since components are related, if one changes it may change other components of the system
Adapted from: INCOSE SE Handbook, pg. 10
System
Segment n
Subsystem nSubsystem 1
Assembly nAssembly 1
Component nComponent
1
Part n
Part 1“The whole is more than the sum of its
parts, the part is more than a fraction of the
whole.” -- Aristotle
Segment 1
Subsystem nSubsystem 1
Assembly nAssembly 1
Component nComponent
1
Part n
Part 1
System Hierarchy
2003, Northrop Grumman Corporation
Typical System Composition
System
Hardware Software Personnel Facilities
Data Materials ServicesTechnique
s
2003, Northrop Grumman Corporation
System of Systems…The Big Picture Every system is part of a larger system and has boundaries and elements external to
it. The system boundary depends on one’s perspective. System of Systems: Interoperable group of systems sharing a common architecture
Components: The operating parts of the system
Relationships: the links between components, such as the communications and flow between components
Interface: The place at which systems meet and act on or communicate with each other
Subsystem
Subsystem
Subsystem
System A
Subsystem
System B
Subsystem
System of Systems
Environment
Component
Relationship
Interface
Boundary
2003, Northrop Grumman Corporation
Every System has Stakeholders
Stakeholder: Individuals, groups, or organizations having: – A vested interest in the system being developed
– Resources (money, people, political clout, etc.) to influence the outcome or end result of the system
Stakeholder influence can be real or perceived
Stakeholder needs can be categorized as current and future “must haves”, “nice to haves”, and “pie in the sky”
Some Examples:
Stakeholders are the primary and most important source of requirements.
Customers OthersUsersDevelopers
2003, Northrop Grumman Corporation
Manage Stakeholder Expectations
Stakeholder Attributes include:
Position
Status
Control
Influence
Responsi-bilities
ActionsDislikes/Fears
StakeholdersName and Title
TheirPriorities
LikesAttributes
Stakeholder management must be done throughout the project/program
and reassessed over time
Access to resources
Autonomy
Comfort
Future prospects
Income
Challenges
Opportunity to succeed
Working relationships
2003, Northrop Grumman Corporation
Every System has a Life Cycle
Life Cycle: Categorization of systems development activities into distinct, controllable phases
All systems follow a general life cycle from concept definition through development and testing to deployment, operations, and deactivation
You need to have knowledge in the overall approach no matter where you work in the life cycle since you are impacted by previous phases and have impact on following phases. In addition, feedback and iterations between
phases is common.
Adapted from: Systems Engineering, Coping with Complexity, pg. 8
Operations & Maintenance,Deactivation
User’s Needs, Requirementsand Approval
System Requirements
Architectural Design
Component Development
Integration and Verification
Installation and Validation
Change & Feedback
Change & Feedback
Change & Feedback
Change & Feedback
Change & Feedback
ReviewComponent
DeliveryReview ReviewAcceptance
TestSystems
Test
Concept Concept DefinitionDefinition
Development/AcquisitionDevelopment/Acquisition DeploymentDeployment OperationsOperations
Change & Feedback
CAUTIONCAUTION
2003, Northrop Grumman Corporation
Constructing Your View of the System
What is in your system? (Hint: look at products, people, decisions, deliverables, etc.)
What are the internal processes? (Hint: What do you and the people you work with do during the day?)
What are the products? (Hint: What do you produce that ends up part of the system?)
Who is the customer for the system? (Hint: who controls the money or wants your product?)
Who are the stakeholders of the system? (Hint: who is also effected by or can affect the system)
What is the environment in which your system is developed and used? (Hint: you are influenced by it but may not have control over it)
How does your system fit into the system of systems? (Hint: what systems are related to or interface with your system, what larger system is your system a part of)
2003, Northrop Grumman Corporation
Industry Definitions of Systems Engineering
“An interdisciplinary approach and means to enable the realization of successful systems.” – INCOSE
“The interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a product solution and support that solution throughout the product’s life cycle.” – CMMI
“Creating effective solutions to problems and managing the technical complexity of the resulting developments.” – Coping with Complexity
“An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced system solution that satisfies customer expectations and meets public acceptability” – IEEE 1220
2003, Northrop Grumman Corporation
Systems Engineering Focus
Defining customer needs and required functionality early in the development cycle
Developing and managing requirements and interfaces
Synthesizing designs and validating system
Considering the complete problem to be solved, including:
– Acquisition Approach and Management
– External environment/influences
– Stakeholders
– Requirements
– Performance
– Cost and Schedule
Considering both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs
– Technology
– Manufacturing
– Test
– Training and Support
– Operations and Maintenance
– Disposal
SE is an overarching discipline, to achieve the best overall product and/or service that meets requirements and does so within budget
and schedule constraints.
2003, Northrop Grumman Corporation
Systems Engineering Processes
Systems Engineering Processes: Logical, systematic, comprehensive, iterative problem solving activities tailored and used to accomplish systems engineering tasks and generate work products
Risk Management
Scheduling
Decision Analysis
System Architecture
Quality
Configuration Management
Information Management
Cost Estimation
Requirements Development & Management
Integrated System Security
Measurement & Analysis
Integration, Verification, Validation, & Transition
2003, Northrop Grumman Corporation
What is a Systems Engineer?
Systems Engineer: Defines, develops, and deploys solutions using systems engineering processes
Role of the Systems Engineer:
– Is involved in developing the system from day one on
– The level of systems engineering effort applied depends on our role with the customer and contract
• If the developing contractor, we employ systems engineering techniques
• If in a role supporting a customer organization (SETA), we provide SE oversight and SE management
– In either role we drive decision making through quantitative and qualitative formulation, analysis, and interpretation of the impacts of alternatives
Systems engineering is not just a role for a specialist group of people, but a part of the work of every individual working in the system
development.
2003, Northrop Grumman Corporation
Systems Engineer Responsibilities
Serve as Chief Communicator and
Honest BrokerLead Proactively
Guarantor of Success of the Entire System and Maintainer
of System Perspective
Provide factual Provide factual recommendations recommendations
that support that support decision makingdecision making
Provide factual Provide factual recommendations recommendations
that support that support decision makingdecision making
Enforce Enforce the Program the Program
Decision Making Decision Making DisciplineDiscipline
Enforce Enforce the Program the Program
Decision Making Decision Making DisciplineDiscipline
2003, Northrop Grumman Corporation
Class Discussion: How do you know a good Systems Engineer when you see them?
People skills– Communicator
– Team player
– Perceptive
– Diplomat
– Referee
Technical Domain skills– Big picture and long term thinker
– Analyst/Technologist
– Commercial standards and trends
Environmental knowledge skills– Program Office environment factors
– Stakeholders
Management skills– Objective decision maker
– Risk management
– Configuration management
The job is challenging.
P
T E
M
– Intellectually curious– Sales person– Listener– Negotiator– Customer focused
– Requirements management
– Integrated schedule management
2003, Northrop Grumman Corporation
When SE Processes are NOT Effectively Managed…
Only 16% of all Information Technology (computer and software) projects complete on time and on budget
31% are cancelled before completion
The remaining 53% are late and over budget, with the typical cost growth exceeding the original budget by more the 89%
– Average overrun of project budgets was 189%
– The average schedule overrun for projects that were in difficulty was 222%
Of the IT projects that are completed, the final product contains only 61% of the originally specified features
If no formal systems engineering effort is included, projects run the risk of 50% to 100% development cost overruns
“Charting the Seas of Technology: The CHAOS Study”
Report of the Defense Science Board Task Force on Defense Software, November 2000, INCOSE Systems Engineering Handbook
2003, Northrop Grumman Corporation
As you recall, every System has a Life Cycle
Life Cycle: Categorization of systems development activities into distinct, controllable phases
All systems follow a general life cycle from concept definition through development and testing to deployment, operation, and deactivation
Adapted from Systems Engineering, Coping with Complexity, p. 8
Operations & Maintenance,Deactivation
User’s Needs, Requirementsand Approval
System Requirements
Architectural Design
Component Development
Integration and Verification
Installation and Validation
Change & Feedback
Change & Feedback
Change & Feedback
Change & Feedback
Change & Feedback
ReviewComponent
DeliveryReview ReviewAcceptance
TestSystems
Test
Concept Concept DefinitionDefinition Development/AcquisitionDevelopment/Acquisition DeploymentDeployment OperationsOperations
Change & Feedback
Simple Life Cycle
2003, Northrop Grumman Corporation
Selecting a Life Cycle Model
Basic models can be enhanced or combined to accommodate different situations and needs
Selection considerations include:
– Solution development approach
– Timeline for deployment
– Status of requirements
Some common life cycle models in use are:
– V-diagram
– Sequential/Waterfall
– Incremental
Different models offer advantages and disadvantages
– Risk sensitivity
– Complexity of the system
– Stability of environment
– Evolutionary
– Spiral
Life Cycle Models are used to define different frameworks for phasing systems development or project activities.
2003, Northrop Grumman Corporation
V-diagram form of Simple Life Cycle
The Simple Life Cycle can be reorganized as a V-diagram to emphasize:– Verification between phases, checking what has been built against its
requirements
– Validation as end-to-end verification ensuring that the complete system meets the users needs
– Decomposition and definition of what is to be built
– Integrating and verifying what has been built
Integrated ComponentsIntegrated
ComponentsComponent
DevelopmentComponent
Development
Integrated Subsystems Integrated
Subsystems
Verification
Validation
Verification
User’s Needs, Requirementsand Approval
User’s Needs, Requirementsand Approval
Operational Capability
Operational Capability
System Requirements
System Requirements
Integrated System
Integrated System
Architectural Design
Architectural Design
Verification
Adapted from Systems Engineering, Coping with Complexity, pp. 8, 160
Inte
grat
ion
&
Ver
ifica
tion
Inst
alla
tion
& V
alid
atio
n
Defining what is to be built
Integrating, verifying, & validating what has been built
Verification
Verification
VerificationSystems Engineering
Development and Fabrication
2003, Northrop Grumman Corporation
Sequential/Waterfall Model
Project activity flows from top to bottom in discrete, sequential, linear phases
Original model did not allow for feedback loops; once the requirements are written, changes would be an unplanned activity
Later modifications incorporated feedback loops
Best used when:• Simple system with small number of alternatives
and low risks• Requirements are known and well defined at the
beginning• Cost, technical, and schedule baselines are stable • Delivery is of one single product at one time
Component DevelopmentComponent
Development
User’s Needs, Requirementsand Approval
User’s Needs, Requirementsand Approval
System Requirements
System Requirements
Architectural Design
Architectural Design
Change & Feedback
Change & Feedback
Change & Feedback
Operations & Maintenance,Deactivation
Operations & Maintenance,Deactivation
Integration & Verification
Integration & Verification
Installation & Validation
Installation & Validation
Change & Feedback
Change & Feedback
Change & Feedback
Adapted from Systems Engineering, Coping with Complexity, p. 194
2003, Northrop Grumman Corporation
Incremental Model
Architecture and requirements of system are well defined and remain fixed throughout
Design is implemented in increments
Each increment provides useful operational capability with successive increments contributing ever greater functionality
Partial solution might cover:
– Part of the functionality
– All functionality with limited performance
– Implementation at a limited number of operational locations
Best used when:• System is well defined from the beginning• Full finance is not immediately available and time to market is important• There is a smaller initial demand• System has multiple deliveries where each adds incrementally more functionality
Adapted from Systems Engineering, Coping with Complexity, p. 178
Component Development
Part 1
Component Development
Part 1
User’s Needs, Requirementsand Approval
User’s Needs, Requirementsand Approval
System Requirements
System Requirements
Operations
1
Operations
1
Integration & Verification
Part 1
Integration & Verification
Part 1
Installation & Validation
Part 1
Installation & Validation
Part 1
Operational System
Time
Component Development
Part 2
Component Development
Part 2Operations
2
Operations
2
Integration & Verification
Part 2
Integration & Verification
Part 2
Installation & Validation
Part 2
Installation & Validation
Part 2
Component Development
Part 3
Component Development
Part 3Operations
3
Operations
3
Integration & Verification
Part 3
Integration & Verification
Part 3
Installation & Validation
Part 3
Installation & Validation
Part 3
Architectural Design
Architectural Design
2003, Northrop Grumman Corporation
Evolutionary Model
Best used when:• Requirements are not completely known or defined at the beginning• Users need to see some early version of system to better understand requirements• System is first of a kind, has complex interfaces, or is part of a rapidly changing environment• Successive product deliveries with increasing capability over time
The final design is not necessarily well-defined early in the process
Basic life cycle is repeated to deliver successive versions and ever-increasing functionality of the product with an operational period to review them and gain feedback
First versions are small and get product into use
System is gradually evolved to a final design
Allows for evolution in technology, requirements, and environment
Adapted from Systems Engineering, Coping with Complexity, p. 181
Component DevelopmentComponent
Development
System Reqs
System Reqs
Integration & Verification
Integration & Verification Installation
& ValidationInstallation & Validation
Operational System
Time
Arch DesignArch
DesignOperations
3
Operations
3
User Reqs
User Reqs
Component DevelopmentComponent
Development
System Reqs
System Reqs
Integration & Verification
Integration & Verification Installation
& ValidationInstallation & Validation
Arch DesignArch
Design
Operations
2
Operations
2
User Reqs
User Reqs
Feedback from system 2
Component DevelopmentComponent
Development
System Reqs
System Reqs
Integration & Verification
Integration & Verification Installation
& ValidationInstallation & Validation
Arch DesignArch
Design
User Reqs
User Reqs
Operations
1
Operations
1
Feedback from system 1
2003, Northrop Grumman Corporation
Spiral Model Combines the evolutionary model with
risk assessment
Philosophy is “system development is risky, know the risks”
Incorporates prototyping as a risk reduction strategy
The spiral repeats a basic 5 step iterative sequence:
1. Identify the objectives, alternative, constraints and requirements
2. Evaluate and assessment alternatives, identify and resolve risks
3. Design, develop and verify the product
4. Plan the next cycle
5. Review the results of the current cycle
Plan next phases
Review
Boehm, Barry, “Spiral Development: Experience, Principles, and Refinements” Special Report, CMU/SEI-2000-SR-008, 2000, p. 2, http://www.sei.cmu.edu/cbs/spiral2000/february2000/SR08.pdf
Best used when:• Program or product contains high risks• Incremental capability levels are specified• Multiple product deliveries over time
Develop, verify next
level product
Evaluate alternatives;
identify, resolve risk
Determine objectives,
alternatives, constraints
Focus on Risk Management
2003, Northrop Grumman Corporation
Life Cycle Model Pros & Cons
Models Pros Cons
Sequential/
Waterfall
Good visibility and control; fully documented; structured process
Serial activities; inter-step dependency increases risk; risk management is minimal; requires large amounts of documentation; problems identified late are expensive to fix
Incremental
When requirements are well known allows early delivery of partial capability; mitigates risk through incremental development; allows some “fine tuning” of requirements
Requires architecture and requirements to be well defined from the beginning; requires efficient CM to control multiple deliveries.
Evolutionary
When requirements are not well know allows early delivery of partial capability; early realistic feedback; early error detection at lower cost; allows for evolution and incorporation of changes in technology, requirements, and environment
Downstream changes can be expensive to retrofit to earlier products; relies on high levels of stakeholder feedback; limited planning horizon; requires efficient CM to control multiple deliveries
Spiral
Handles volatile baselines; employs continuous risk management
Less visibility and control; Need skillful practitioners; the many steps involved can cause cost and schedule problems; hard to tell when finished
2003, Northrop Grumman Corporation
Nesting and Combination of Life Cycles
For large systems, multiple models can be used for different components, or during different phases, or combined into hybrid models
Project A Project B
Project C
System Life CycleSystem Life Cycle
Project D
Component Development
Component Development
User’s Needs, Requirementsand Approval
User’s Needs, Requirementsand Approval
System Requirements
System Requirements
Architectural Design
Architectural Design
Change & Feedback
Change & Feedback
Change & Feedback
Operations & Maintenance,Deactivation
Operations & Maintenance,Deactivation
Integration & Verification
Integration & Verification
Installation & Validation
Installation & Validation
Change & Feedback
Change & Feedback
Change & Feedback
Component Development
Part 1
Component Development
Part 1
User’s Needs, Requirementsand Approval
User’s Needs, Requirementsand Approval
System Requirements
System Requirements
Operations
1
Operations
1
Integration & Verification
Part 1
Integration & Verification
Part 1Installation &
Validation
Part 1
Installation & Validation
Part 1
Operational System
Component Development
Part 2
Component Development
Part 2Operations
2
Operations
2
Integration & Verification
Part 2
Integration & Verification
Part 2Installation &
Validation
Part 2
Installation & Validation
Part 2
Component Development
Part 3
Component Development
Part 3Operations
3
Operations
3
Integration & Verification
Part 3
Integration & Verification
Part 3Installation &
Validation
Part 3
Installation & Validation
Part 3
Architectural Design
Architectural Design
Component Development
Component Development
System Reqs
System Reqs
Integration & Verification
Integration & Verification Installation
& Validation
Installation & Validation
Operational System
Arch Design
Arch Design
Operations
3
Operations
3
User Reqs
User Reqs
Component Development
Component Development
System Reqs
System Reqs
Integration & Verification
Integration & Verification Installation &
Validation
Installation & Validation
Arch Design
Arch Design
Operations
2
Operations
2
User Reqs
User Reqs
Feedback from system 2
Component Development
Component Development
System Reqs
System Reqs
Integration & Verification
Integration & Verification Installation
& Validation
Installation & Validation
Arch Design
Arch Design
User Reqs
User Reqs
Operations
1
Operations
1
Feedback from system 1
2003, Northrop Grumman Corporation
Exercise:
Life Cycle Models
2003, Northrop Grumman Corporation
Life Cycles, Reviews, and Control Gates
System development progresses from an abstract need to a product with form and function
A life cycle model identifies phases and activities
Each phase ends with a review and/or control gate
Reviews and control gates are the checks and balances
– Reviews: examine the deliverable work products and determines if program ready to move to the next phase
– Control gates: provide a go/no go decision point based on transition criteria
Provides management a decision point to proceed to the next phase or return to the previous one to resolve issues
2003, Northrop Grumman Corporation
Example Life Cycle Reviews and Control Gates
Operations & Maintenance,Deactivation
User’s Needs, Requirementsand Approval
Systems Requirements
Architectural Design
Component Development
Integration and Verification
Installation and Validation
System Requirements
Review(SRR)
Contract Implementation
Review(CIR)
Operations Transition
Review(OTR)
Segment Requirements
Review(SRR)
Test Readiness
Review(TRR)
Critical Design Review(CDR)
Preliminary Design Review
(PDR)
Pre-Ship Review(PSR)
Operational Readiness Review
(ORR)
Formal Qualification
Review(FQR)
Installation Status Review
(ISR)
Test Readiness
Review(TRR)
Tailoring of the life cycle reviews and control gates depends on program size, complexity and scope
Concept Concept DefinitionDefinition Development/AcquisitionDevelopment/Acquisition DeploymentDeployment OperationsOperations
2003, Northrop Grumman Corporation
2003, Northrop Grumman Corporation
References
TASC ISM Web Page
– http://www.corp.tasc.com/processes/ism/index.shtml
TASC Life Cycle Readiness Process Resource Package
– http://www.corp.tasc.com/processes/ism/lcr/index.shtml
TASC INCOSE Links
– http://myweb.corp.tasc.com/INCOSE/
International Council on Systems Engineering (INCOSE) Web Page
– http://www.incose.org/
Capability Maturity Model-- Software Engineering Institute
– www.sei.cmu.edu
NGIT OWD
– http://inside.it.northgrum.com/owd/
Life Cycle Models
– http://www.cs.ualberta.ca/~sorenson/cmput401/lectures/SWLifeCycle/
– http://www.cs.qub.ac.uk/~J.Campbell/myweb/misd/node3.html
– http://www.levela.com/software_life_cycles_swdoc.htm
– http://www.sei.cmu.edu/cbs/spiral2000/