GGG1

• Design Synthesis - Process of translating the functional architecture developed in the Functional Analysis and Allocation step into a Physical Architecture, which includes product, system, and software elements that fulfill system required function.
• Physical Architecture

  • Tangible structure or arrangement of physical components in a system or product
  • Forms the basis for design definition documentation, such as, specifications, baselines, & work breakdown structures (WBS)
• Characteristics of Physical Architecture

  1. The correlation with functional analysis requires that each physical or software component meets at least one (or part of one) functional requirement, though any component can meet more than one requirement
  2. The architecture is justified by trade studies and effectiveness analyses
  3. A product WBS is developed from the physical architecture
  4. Metrics are developed to track progress among KPPs
  5. All supporting information is documented in a database
• Modular Design- Involves creating an item out of smaller, interchangeable parts known as modules

• Desirable Characteristics of Modular Units

  • Low Coupling (measures interdependence b/w modules)
  • High Cohesion (reflects similarity of tasks within a module)
  • Minimal Productivity (refers to the relationship between internal elements of different modules)
• Design Loop

  1. Define Problem

  2. Research Analyze

  3. Brainstorm

  4. Design Solution

  5. Build Prototype

  6. Evaluate Solution

  7. Redesign Solution
• Functional/Physical Matrix- Tool used in systems engineering to map functional requirements to physical components within a system architecture

• Modelling

  • Creating simplified representations of system components and behaviors using such tools
  • Models act as virtual prototypes, allowing engineers to test how the system would perform under various conditions
  • Engineers can examine system performance, detect potential issues, and improve design decisions prior to physical implementation
  • Helps teams communicate and collaborate by providing a common framework for understanding system behavior
• Schematic Block Diagram

  • Traditional logical prototyping tool for Design Synthesis
  • A visual representation of a system's components and interconnections, typically displayed as blocks representing functions or subsystems and lines indicating connections
• Verification

  • Confirms that Design Synthesis has resulted in a physical architecture that satisfies the system requirements
  • Throughout a system's life cycle, design solutions at all levels of the physical architecture are verified to meet specifications
• Verification- Quality control process that determines if a system meets its system-level requirements

• Validation- Quality control process that determines if operational requirements are met for the overall system to meet Initial Capabilities Document (ICD) and Capability Development Document (CDD)

• Verification Phases in V-Model

  • Requirement Analysis
  • System Design
  • Architectural Design
  • Module Design
  • Code Implementation
• Verification includes checking documents, design, code, and program, while Validation includes testing and validation of the actual product
• Verification checks whether a component (software) confirms a specification, while Validation checks whether a component (software) meets the requirements and expectations
• Benefits of Verification and Validation

  • Making sure the product works
  • Improving the quality of the product
  • Minimizing costs and risks
  • Meeting rules and standards
  • Improving customer satisfaction
  • Improving performance and efficiency
  • Helping with continuous improvement
  • Improving safety and reliability
• Verification Process Key Objectives

  • Quality Control
  • Meeting Design Requirements and Customer Needs
  • Time Savings
  • Defect Reduction
• Verification Activities

  • Analysis
  • Inspection
  • Demonstration
  • Test
• Performance Verification


  Performance requirements must be objectively verifiable, ensuring measurability, with Technical Performance Measurements (TPM) and management metrics employed to gauge progress towards meeting goals
• Verification Process Steps

  1. Planning (Verification Method and Level Assignments, Verification Task Definition, Verification Configuration Definition, Verification Scheduling)

  2. Execution (performance of a given verification task with supporting resources)

  3. Reporting (reports the compiled results of the executed verification plan and verifies the materials employed in system solutions can be used in a safe and environmentally compliant manner)
• System Architecture - Describes the entire system, including physical architecture and support elements.

  -MIL-HDBK-881 provides reference models for tailored top-level architectures
• Specifications - Document that clearly and accurately outlines the fundamental technical requirements for items, materials, or services, including the procedures for verifying that these requirements have been fulfilled
• Program-Unique Specifications


  Are central to configuration baselines, defined at various phases of the design process and referring to different levels within the system hierarchy

  
• Specification Types


  • System Spec (defines mission/technical performance req, allocates requirements to functional areas & defines interfaces, Baseline: Functional)
  • Item Performance Spec (defines performance characteristics of CIs and CSCIs, details design req & w/ drawings & other documents form the Allocated Baseline, Baseline: Allocated "Design To")
  • Item Detail Spec (defines form, fit, function, performance, and test req for acceptance, Baseline: Product "Build To" or "As Built")
  • Process Spec (defines process performed during fabrication)
  • Material Spec (defines production of raw materials or semi-fabricated material used in fabrication)

  
• Requirements documents explain why development is necessary, specification documents detail what the system must do technically (functionality, performance, interface), and design documents outline how design requirements are met
• 3 Classic Baselines

  • Functional Baseline
  • Allocated Baseline
  • Product Baseline
• Additional documents

  • End Product Baseline (cover system requirements, architecture, technical drawings, and traceability)
  • Enabling Product Baseline (encompass manufacturing plans, supportability, manuals, training, and deployment planning, with a focus on susceptibility to configuration changes)

  
• Acquisition Program Baselines - Embody only the most important cost, schedule, and performance objectives and thresholds
• Configuration Baselines

  • Functional Baseline (describes system level requirements)
  • Allocated Baseline (describes design requirements for items below system level)
  • Product Baseline (describes product physical detail)

  
• Decision Database - Serves as documentation for configuration solution decisions, encompassing various analyses such as: Trade Studies, Cost Effectiveness Evaluations, Quality Function Deployment (QFD) Analysis, Models, Simulations, and Other Relevant Data

  • Aids in understanding requirements, developing alternative solutions, and ultimately selecting the most suitable option
• DoD Basic Classifications of Specifications Material Specifications (dev by DoD components)

  • Program-Unique Specifications
  • Non-DoD specifications

  
• DoD Policy Specification - is to develop performance specifications for procurement and acquisition, give preference to the use of commercial solutions to government requirements, and in the case of re-procurement, where detail specifications and drawings are government owned, standardization or interface requirements may present a need for use of detailed specifications
• Performance Specifications - Define products in terms of functions, performance, and interface requirements
• Detail Specifications - A specification that contains both performance and detail requirement,
• Software Documentation - standard describes the development of software specifications as one aspect of the software development process-
• Standard Practice for Defense Specifications - MIL-STD-961D establishes the format and content of system, configuration item, software, process, and material specifications
• Standards

  -. Establish engineering and technical limitations & applications for items, materials, processes, methods, designs, and engineering practices

  • "Corporate knowledge" documents describing how to do some process or description of a body of knowledge
• DoD Policy (Standards) - applies to the imposition of both Military Specifications and Standards and, in addition, to the imposition of Commercial and Industry Standards, with the preferred approach being to allow contractors to use industry, government, corporate, or company standards they have determined to be appropriate to meet government's needs
• DoD Index of Specificarions and Standards (DoDISS)- Lists all international, adopted industry standardization documents authorized for use by the military departments, federal and military specifications and standards