Functional Analysis Methods - PowerPoint PPT Presentation

About This Presentation
Title:

Functional Analysis Methods

Description:

Title: Functional Analysis Methods Author: Mason Myers Last modified by: m198899 Created Date: 5/10/2000 2:37:30 PM Document presentation format: On-screen Show – PowerPoint PPT presentation

Number of Views:120
Avg rating:3.0/5.0
Slides: 39
Provided by: Maso62
Learn more at: https://www.incose.org
Category:

less

Transcript and Presenter's Notes

Title: Functional Analysis Methods


1
Systems Architecting
An introduction
2
Agenda
  • Evolution of Systems
  • Relating Systems Engineering Architectures
  • Representing an Architecture
  • Using Architectures
  • Summary

3
Evolution of Systems
4
Evolution of Systems
5
Evolution of Systems
6
Evolution of Systems
Systems are becoming increasingly large and
complex
7
No Easy Answer
  • Modern Systems
  • Ill-Structured
  • Involve New Untested Ideas
  • Complex

8
Overcoming these Problems
Maybe he doesnt want to be in charge of the next
customer review
  • How will we
  • Manage uncertainty
  • Manage complexity
  • Manage technological change

9
Systems Engineering the Process
  • A process that transforms an operational need or
    market opportunity into a system description to
    support detail design.
  • Requirements Analysis
  • Functional Analysis
  • Synthesis
  • Systems Analysis / Management

10
Systems Architecture a Product
The design teams interpretation /
implementation of customer requirements
communicated thru
  • System Usage Scenarios (i.e., Use Cases)
  • Functional Components Interrelationships
  • Physical Subsystems Interfaces
  • Etc

11
Systems Architecting a Methodology
A Segment of the Systems Engineering Process
Which Facilitates the Identification of
  • System Elements
  • Relationships
  • Design Principles

That Collectively Satisfy Customer Requirements
and Meet User Needs.
12
Architecting in the Systems Engineering Process
  • System Analysis
  • Modeling Simulation
  • Trade Studies
  • Effectiveness Analysis
  • Process
  • Inputs
  • Stakeholder Inputs
  • Operational
  • Requirements
  • MOEs
  • Environments
  • Constraints
  • Capability-Based
  • Acquisition
  • Quality Attributes
  • Interoperability
  • COTS/GOTS/BOTS
  • Re-Use and Legacy
  • Technology Base
  • Prior Phase Results
  • Applied Standards

Goal/Mission Analysis/Validation
  • Requirements Analysis
  • Analyze Missions and Environments
  • Identify Functional Requirements
  • Define/Refine Performance and Design Constraints
  • Identify Quality Attributes
  • Validate Requirements

Functional Architecture Analysis
  • System
  • Management
  • Risk Management
  • Data Management
  • Configuration Management
  • Progress Measurement
  • IMP/IMS TPMs
  • Technical Reviews

Requirements Loop
  • Functional Analysis Allocation
  • Decompose to Next-Lower Level Functions
  • Define/Refine Functional Interfaces
    (Internal/External)
  • Define/Refine/Integrate Functional Architecture
  • Allocate Performance Other Requirements

Physical Architecture Analysis
Design Loop
  • Synthesis
  • Transform Each Levels Architecture from
    Functional to Physical
  • Define Alternative System Concepts
    Configuration Items
  • Define/Refine Physical Interfaces
    (Internal/External)
  • Identify Candidate Architecture Styles
  • Select Best Value Design

Verification Loop
Iteration Loop (Derived Requirements for the
Next Level of Decomposition)
  • Process
  • Outputs
  • Best Value System Architecture
  • System Architecture Models and Specifications

13
The Two Primary Methods of Architecting
  • Structured Analysis and Design Technique (SADT)
  • Graphical Representation of System Requirements
  • Boxes and Arrows
  • Logical Flows
  • Object-Oriented Analysis (OOA) and the Unified
    Modeling Language (UML)
  • Structure Diagrams
  • Behavior Diagrams
  • Interaction Diagrams

14
Goals of Systems Architecting
  • Take into account the whole picture
  • Life cycle phases, boundaries, external elements
  • Users, builders, benefactors, supporters,
    environments
  • Affordability, safety, availability,
    survivability, security, etc.
  • Communicate clearly the components and their
    inter-relationships from user and engineering
    perspectives
  • for customer validation
  • for use in analysis and design by all engineering
    disciplines

15
Describing the Architecture
Physical Descriptions
Operational Expectations
Behavioral Descriptions
Many perspectives physical, functional,
operational, technical
16
Physical View to an Architecture
17
Functional View to an Architecture(Example Based
on Unified Modeling Language)
18
Product Diagrams of the Systems Architecture
Use Case Diagrams
Class Diagrams
Activity State Diagrams
Sequence Diagrams
19
DoDAF DoD Architecture FrameworkCustomer
Defined Views of the Model
20
Operational View (OV)What needs to be done Who
does it
High Level Operational Concept Graphic (OV-1)
Operational Exchange Matrix (OV-3)
Operational Node Connectivity Diagram (OV-2)
Organizational Relationships Chart (OV-4)
21
System View (SV)Relates Systems and
Characteristics to Operational Needs
System Interface Description (SV-1)
System Systems Matrix (SV-3)
System Functionality Description (SV-4) UML
Version
System Functionality Description (SV-4)
22
Technical View (TV)Prescribes Standards and
Conventions
System Products Associated With Standards (TV 1)
Template for Time Records (TV-1)
Technical Standards Profile Template (TV-1)
23
25 Views Integrated Together
AV 1 Overview Summary Information AV 2
Integrated Dictionary OV 1 High Level
Operational Concept OV 2 Op. Node Connectivity
Description OV 3 Op. Informational Exchange
Matrix OV 4 Org. Relationships Chart OV 5
Activity Model OV 6a Operational Rules OV
6b Operational State Transition OV 6c Op.
Event Trace Description OV 7 Logical Data
Mode SV 1 Systems Interface Description SV
2 Systems Communication Description SV 3
Systems Matrix SV 4 System Functionality
Description SV 5 Op. Activity to Systems
Function Traceability Matrix SV 6 System Data
Exchange Matrix SV 7 System Performance
Parameters SV 8 System Evolution
Description SV 9 System Technology Forecast SV
10a System Rules Model SV 10b System State
Transition Description SV 11 Physical Data
Model TV 1 Technical Architecture Profile TV
2 Standards Technology Forecast
24
DoDAF Summary
  • DoDAF is a way of describing a system.
  • DoDAF represents a number of different views of
    the architecture.
  • DoDAF is a required output to our customers.
  • DoDAF is NOT a methodology or process.
  • DoDAF is NOT a UML based set of views.

25
Benefits of Architecting
  • Identifies All System Elements Earlier vs. Later
  • Matches Function to Requirements
  • Capture Communicate Key concepts
  • Results in ONE design
  • Manages Increasing Complexity
  • Allows Modular Design

26
Users of the Architecture
  • Systems Architect Translate Client Needs into
    Builder Requirements
  • System Designers Design Guidance
  • Program Managers Program Performance Measurement
    and Guidance
  • Customers Validation of Requirements and Design
  • Other Stakeholders Various Views of the System
  • Manufacturers - Trainers
  • Testers - Users
  • Purchasers - Logistics Personnel
  • Handlers - Maintainers

Adapted from Agile Systems Engineering
Architecting Methods, Processes, and
Practices Stevens Institute of Technology, March
15, 2004
27
Architecture Used In
  • Analysis of Alternatives (AoA)
  • Business and Technical Planning
  • Communications among Organizations
  • Internal to Internal
  • Internal to External
  • Input to Subsequent System Design and Development
  • Criteria for Certifying Conformance of
    Implementations
  • Development, Maintenance, and Reuse Repositories
  • Review, analysis, and evaluation of the system
    across the life cycle
  • Basis for incremental/spiral development

28
Characteristics of a Systems Architect
  • Analytical
  • Attention to Detail
  • Visionary
  • Generalist
  • Common Sense
  • Know-How
  • Drive
  • Critical Attitude
  • Multi-tasking
  • Teamwork
  • Communicator/Documenter
  • Flexible
  • Process Insight
  • Political Insight/Negotiation

29
The Risks of Architecting
  • Early Identification of Problems
  • Perception of Program Delay
  • Inconsistent Application of Methodologies
  • Limited Numbers of Skilled Creators/ Reviewers

30
Risks of Not Architecting
  • Late Identification of Problems
  • Lack of Unified Design
  • Issues of Complexity Management

31
Example Architecture Issues
Audi 2006 A8, A8 L, and A8 L W12 Passenger
Vehicles On certain passenger vehicles, a wiring
harness condition exists that may deactivate the
passenger side frontal air bag even under
circumstances when it should remain activated.
Starbucks Coffee Company Recall of Ceramic
Teapots The teapots are labeled safe for
microwave use, but the handles can become hot in
the microwave oven. This poses a possible burn
hazard to consumers. Microsoft Xbox 360 Class
Action Lawsuit There may be a design flaw which
causes the console's power supply and CPU to
overheat, causing the whole system to seize up.
Complaints of similar freezing problems began to
surface almost as soon as the Xbox 360 went on
sale November 22.
32
Summary
  • Increasingly complex systems drive a need for
    better, clearer design descriptions
  • Architectures convey the system designers
    interpretation of the requirements
  • Architectures may be presented by a variety of
    views which collectively describe the system
  • As part of the systems engineering process,
    systems architecting defines and manages
    development of a system

33
(No Transcript)
34
References
  • Boeing Systems Architecture Development Guidebook
  • The Art of Systems Architecting, Eberhardt
    Rechtin, Mark W. Maier
  • DoD Architecture Framework (DoDAF)

35
Recommended Use of DoDAF Products
36
DoDAF View Extraction
37
Evolving Architectures Impact of Spiral
Development
38
Model-Based Architecture
  • Why Model-Based Architectures?
  • Help to Explain How Things Work
  • Broaden Our Perspective
  • Provide a Common Conceptual Frame of Reference
  • Express Rules More Simply
  • Clarify Relationships, Identify Key Elements, and
    Consciously Eliminate Confusion Factors

From Forsbert, Kevin Visualizing Project
Management, Pg. 14
Write a Comment
User Comments (0)
About PowerShow.com