How to Break Mammoth-Sized Projects into Bite-Sized Pieces Esther - - PowerPoint PPT Presentation

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

How to Break Mammoth-Sized Projects into Bite-Sized Pieces

Esther Johnson and Kevin Nguyen

Northrop Grumman

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Overview

• Avoiding typical software development problems
• Accurately design the intended system based on the acquired

requirements

– Capturing customer requirements

• Translating the requirements
• Trace Requirements
• Transition from Systems to Software
• Architecture Development Process
• Experiences
• Customer Comments

2

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Most Common Reasons for Software Project Failure

• Poor communication among stake holders in order to understand a

project requirements

• Poor planning on resources and activities
• Poor quality control
• Poor estimation
• Poor risk identification and management

3

If you don’t understand what the Customer wants, you can’t build it.

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

4

Today’s Systems of Systems Are Too Complex To Play “Bring Me A Rock”

class_5_copy class_3 class_1_copy_copy_0 Externals::AppFramework class_1_copy class_4_copy Externals::UI_SMap Key, T, Compare, Allocator UI_SMap::Key UI_SMap::Allocator 1 1 UI_SMap::Compare 1 1 UI_SMap::T 1 1 1 1 class_1_copy_copy Externals::SocketUDP class_2_copy 1 1 1 1 class_0_copy_1 1 1 1 1 class_0 class_0::class_2 Externals::UI_SVector T, Allocator UI_SVector::Allocator UI_SVector::T class_3_copy class_5_copy_0 class_1_copy_copy_2 1 1 1 1 class_1 1 1 1 1 1 1 class_0_copy_0 1 1 class_0_copy_5 class_0_copy_2 1 1 1 1 1 1 class_0_copy 1 1 1 1 class_4 1 1 1 1 1 1 class_5 Externals::Allocator T Allocator::T class_2 1 1 1 1 class_0_copy_3 1 1 1 1 class_1_copy_1 class_1_copy_0 Externals::OS_Database arg1 OS_Database::arg1 class_0_copy_4 Externals::Index T Index::T 1 1 1 1 class_2_copy_0 class_1_copy_copy_1 1 1 Externals::SocketInterface 1 1 1 1 1 1

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05 5

• Traditional Systems and Software Architecture Processes Are

Stressed To Meet Demands Of Software Intensive Service Oriented Architecture Systems

• Sustainable Architecture Goals:

– Increase “Visual Bandwidth” To Improve SE-SWE Communication from womb to tomb – Work At Higher Level Of Abstraction To Manage Large-scale System Complexity – Demonstrate Correct Functionality/Performance Early In Lifecycle Using Models – Enable Process Automation And Performance Analysis Via Smart, Integrated Toolset – Early Involvement Of Test And Stakeholder Communities

Sustainable Architecture Development–Motivation

Visualization Application Application App App App App App App Common Services Integrated Infrastructure Communication Hardware/OS

Redefine the Way We Design and Build Systems of Systems

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Northrop Grumman’s Architecture in Practice

• Exploits a sustainable Model Driven Architecture

Development Processes

• Provides the framework to support customers,

management, and architects working towards common goals

• Provides tangible steps and example artifacts to allow

architects to clarify requirement understanding with various stakeholders

• Encourages customer input/feedback
• Iterative process helps to catch design deficiency early
• Endows customers, managers, architects, and

developers with the same understanding of the requirements by illustrating the architecture in a concise, common language

6

Project Manager Customer Architect Success

Keys to Success

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Model Driven Architecture Development Highlights

7

Input Document Purpose Collaboration Customer Requirements Understand customer’s requirements

• System Engineers work with customers to understand their

requirements

• Start a concept model to support the effort of breaking the

system requirements to hardware, and software requirements System Hardware/ Software Requirements Initial architecture with CSCIs

• System Engineers work with Senior architects and Test

engineers to convey knowledge as well as clarification of any misunderstanding

• Refine/derive requirements
• Develop test plan

System Software Requirements Expand the model to CSCs

• Software Engineers and Architects work with Subject Matter

Expert to further breaking the architecture down to CSCs

• Generate ICDs and data information
• Refine test plan

ICDs Develop Interfaces

• SMEs support software engineers to design and develop

interfaces for internal/external interfaces Test plan Verify/Validate design

• Software engineers, and test engineers collaborate to verify the

system performs as expected

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Key Ingredients in Model Driven Architecture Development

8

Input Process Artifacts Manage Presentation

• Each of the phase of architecture development

revolves around this circle of activities

• Horizontally, these steps allow architects to

absorb input from both customers and managers which leads to customer satisfaction and align the design with a corporate product line

• Vertically, this process allows technical experts such as system

engineers, architects, software engineers and test engineers to work in lock steps

• The project is built on top of the previous success step
• Collective efforts are deposited in one elaborated system architecture

which is used to generate appropriate documentation each phase

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

9

General Architecture Process Flow

• ement. If mov

Input Rqts Model System Behavior

Model Component Interaction

Milestone Review

Model System Structure

Capture System Requirements Model Domain Information Model System Environment

Allocate functionality, define component interfaces Capture system knowledge Analyze customer requirements, develop derived requirements Define System boundary, external Actors, Interfaces With allocations to components

Validate Model

• bserveTaskingStatus()
• bserveTaskingStatus()

Model External Interaction

Exercise model with cross-use case threads Define external interfaces Define next level architectural components

PDIS-ESM7107 Model Driven System Engineering (MDSE) System Architecture Development (SAD) Technical Manual for Object Oriented Systems Engineering (OOSE)

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

10

Design the intended system based on the acquired requirements

• Develop Architecture Models based on acquired requirements and develop new

requirements from what you learn

• Embrace an incremental analysis philosophy

– The process steps are repeated at each level of abstraction from System to Segment/Subsystem to Components – May also be thought of as agile analysis & design spirals

• Number of iterations/spirals dependent on project size/scope

Sustainable Architecture Development

System Level Analysis Sub-System Level Analysis Component Level Analysis Implementation

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Keys to Successfully Translating Stakeholder Requirements into System Requirements

• Focus on the needs of stakeholders

– Each project phase needs to assess the requirements from the previous phase to gain an understanding and maintain project momentum

• Primarily accomplished through the formulation of a system solution

defined by its system architecture

• Approach is structured around the development of a model
• System engineers build models to better understand problems, develop

candidate solutions, and validate their decisions.

• Use a common language – SysML, UML, DoDAF… Pick a language your

interdisciplinary team already knows, or can pick-up fast

• Pick a tool set early, and put products under Configuration Management

11

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Capturing Customer Requirements

• Rule #1: Construct a good Map of your Architecture

– Base Architecture Map on Stakeholder Requirements – Refine details as you learn to move from high-level National Map (Operational Views) to your lowest street level map (Computer System Components and Units)

• Different Views for Different Purposes and Stakeholders

– Don’t put in too much detail all at once, make sure the detail is appropriate for the stakeholder your focusing on

• Rule #2: Document Architecture In-Depth

– Document design decisions in the working architecture model

• Keep every one on same page
• Make sure a new team members can use your architecture to

come up to speed on the project

• Rule #3: Validate Design Decisions

– Use Model-based design validation throughout a project's life cycle to help reduce downstream errors and non-compliance.

• Rule #4: Manage Scope of Stakeholder Reviews

– Meet at major decision points to agree on requirement interpretations – Make sure review is appropriate to audience

• Review of in-depth software class detail with the end-user is not

appropriate

12

Refine based on Stake Holder Needs Refine based on Stake Holder Needs

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Requirements Linked to Model for Coverage Analysis

• Document pedigree of requirements as they are developed
• Individual requirement traceability to software components
• Software component traceability back to its requirements

Womb to Tomb Requirements Trace

13

Use Modeling Tool set to generate requirement specifications from Model

• Description
• Operations
• Allocated requirements
• Interfaces & data objects
• Diagrams

SRS SRS

Requirement Specifications

Integrated Tool Suite Generates Specifications and Maintains Traceability

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Transitions in Architecture Team Members

• Changing Key Engineers is Typically Major Customer concern

– No one paying for a product that hasn’t been built wants to spend time talking about what they want with the Systems Engineers just to have the work thrown away when its thrown over the wall to Software

• Combat the Transition issues

– From project start, build an interdisciplinary team to prevent the need for a painful transition between project phases

• Architects
• Systems Engineers
• Software Engineers
• Test Engineers
• Modeling&Sim Engineers
• Trainers

14

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Experiences/Benefits

• Step-by-step process activities provide a roadmap for specifying the requirements,

architecture and design – Both process & tools were relevant to entire engineering team… conduit for system-to-software engineering communication

• Visual based UML artifacts proved to be understandable by operational and

programmatic customer communities – Executable thread activity and sequence diagrams used to review system design with operators

• Provided common design reference for large, geographically distributed and diverse

team

• Forced frequent check-points and quality reviews
• Emphasis on early behavioral/performance modeling improved customer design

confidence, aligned stakeholder expectations, and lowered downstream risk – Executable Model used to “simulate” system behavior through production of animated Sequence Diagrams – Early performance analysis performed using UML timing profile on same sequence diagrams

15

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Summary

• Large-scale systems require new engineering paradigms

– Sequential and document-centric development doesn’t deliver a solid sustainable Architecture – UML based Model Driven Architecture Development provides visual bandwidth and abstraction to design software intensive architectures for net-centric warfare

• perations
• Process/tools successfully employed on multiple Northrop Grumman

Aerospace Systems programs

– Contribute design consistency and depth…extensive design detail for Major Design Reviews – Model validated architecture design

• Exercised system function and performance characteristics
• Improved customer understanding of design and behavior

16

Visualization Application Application App App App App App App Common Services Integrated Infrastructure Communication Hardware/OS

SEI Architecture Technology User Network Conference, Wednesday, 18 May2011, Architecture is Not Just for Architects Approved for Public Release, Control No. 11-0359 , dtd. 11-04-05

Architecture in Practice Customer Comments

• “ MDE requires a commitment to robust systems engineering. The MDE technology

is evolving and improving, but the benefits are clear. It's a great vehicle for projects that need to be able to reason about large scale problems and to collaborate across multiple organizations.” Tom Wheeler, MITRE senior principal engineer who served as Deputy Chief Engineer of the former 851st, Electronic Systems Group, Hanscom Air Force Base, Mass

• “Based on my 40 years of software development, this just feels right to me.” Dr.

Robert Miller, B-2 Inc1 USAF Lead Software Engineer.

• “In my 15 years of DoD work, I’ve never seen a better roadmap for the success of

SW related Reviews.” Shaun Power, B-2 Increment 2 Deputy Manager.

17

18