Work Breakdown Structure WBS in Systems Engineering Management

Work Breakdown Structure (WBS) in Systems Engineering Management

Work Breakdown Structure v Foundation for all program activities, including: Ø Ø Ø Program and technical planning event scheduling Event schedule definition Configuration management Risk management, data management Specification preparation SOW preparation Status reporting and problem analysis Cost estimates and budget formulation Objective’s Analysis Functional Analysis Etc.

Work Breakdown Structure — Purpose v v v v Identify all of the work that needs to be done to complete the project. Structure the work into logical components and subcomponents. Define the work to a level of detail so individual responsibilities can be assigned. Summarize and report project data. Means of organizing system development activities based on system and product decompositions Used to define total system in relation to functional breakdown Provides framework for program and technical planning, cost estimating, resource allocation, performance measurements, and status reporting Directly implemented in Project Software

WBS Development v Physical and system architectures used to prepare the WBS; Ø Review architectures to ensure all necessary products and services identified Ø Ensure top-down structure provides a continuity of flow for all tasks Ø Provide enough levels to identify work packages for cost/schedule control purposes

Representative Work Breakdown Structure Level I (Noun) Level III (Action Verbs) Level IV (Action Verbs)

WBS — Outlining Approach 3 -4 -10 I. Main Project Deliverable A. Major Element 1. Activity 2. Activity a. task b. task c. task 3. Activity B. Major Element 1. Activity 2. Activity Level 1 Level 2 Level 3 Level 4 Level 3 Level 2 Level 3 The outline approach is used by Microsoft® Project®

System hierarchies TISYSE 8

System Layering TISYSE An Introduction to System Engineering 9

An Example of System Components TISYSE 10

Contractor/Sub-contractor model

Defining some terms used v v v Scope - Defines boundaries of project Context - Defines setting or environment Context Diagram - Defines interactions of application with external world Structured Decomposition - Divide and conquer Balancing - Checking entities, data flows, and processes across the levels of diagram set v A Service is: – a feature of a system – what system users consume – something that can be measured and be subject to a service level agreement v Requirements Engineering 6: The process taken to discovering the purpose of the system v Traceability 10: Traditional definition revolves around the bi-directional tracing of a written requirement. v Definition extends to the traceability of key pieces of information of a system’s design. v Systems Engineering 4: The process and activities associated with developing a system. v Stakeholder 1: a vested party in the system (i. e. customer, developer, users) v This includes all the engineering disciplines needed to build a system: hardware, mechanical, firmware, electrical, and yes – software