1 ISA 201 Intermediate Information Systems Acquisition
2 Lesson 6 Systems & Software Engineering
3 Today you will learn to:Explain the DoD Systems Engineering Process in the context of Information Technology (IT) / Software (SW) Development. Describe the role of the Software Engineer (SwE) in supporting the Systems Engineer (SE). Identify DoD SE technical reviews, technical processes, and technical management processes. Identify SE Lessons Learned & Best Practices when dealing with software. Distinguish the different activities that comprise the SE technical and technical management processes. Given a scenario, recognize aspects of these engineering management principles of Requirements Management, Risk Management, Configuration Management and Interface Management to a development effort. Systems & SW Engineering
4 Overview Systems Engineering Process Work Breakdown Structure (WBS)WBS Exercise Technical Reviews Systems & Software Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
5 SE & SWE in DoD The Office of the Deputy Assistant Secretary of Defense for Systems Engineering (ODASD(SE)) is the focal point for all policy, practice, and procedural matters relating to Department of Defense Systems Engineering and its key elements to include technical risk management, software engineering, manufacturing and production, quality, standardization, and related disciplines. Systems & SW Engineering
6 DASD(SE)'s Priorities Support the current fight; manage risk with discipline Grow engineering capabilities to address emerging challenges Support realistic program formulation through the application of development planning and early systems engineering Increased focus on security, reliability, and affordability Champion systems engineering as a tool to improve acquisition quality Develop future technical leaders across the acquisition enterprise Systems & SW Engineering
7 Systems Engineering in IT AcquisitionIT Systems Engineering: Translates operational needs and capabilities into operationally suitable hardware and software increments of a system. Permeates design, coding/production, test & evaluation, and system support. Is implemented through multi-disciplinary teams (IPTs) of subject matter experts (SMEs). Takes a total life cycle, total systems approach to IT system planning, development, implementation and disposition/disposal. Systems & SW Engineering
8 Software Engineering in IT AcquisitionAccording to the Institute of Electrical and Electronics Engineers (IEEE), software engineering means applying the principles of engineering to the software development field. Software engineering differs from other branches of engineering in that professionals are building an intangible structure and not a tangible one. Since software is embedded in the machines used in various industries, though, malfunctioning software can actually have tangible effects. With software used in everything from medical equipment to airplanes, the end result of faulty software can indeed be loss of life. Software engineering often does involve writing code, but this is only one stage in the process. True software engineering has a well-articulated acquisition life cycle. urbanpro.com Systems & SW Engineering
9 Lesson Plan Status Overview Systems Engineering ProcessWork Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems & Software Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
10 Systems Engineering PlanIntroduction—Purpose and Update Plan Program Technical Requirements Architectures and Interface Control Technical Certifications Engineering Resources and Management Technical Schedule and Schedule Risk Assessment Engineering Resources and Cost/Schedule Reporting Engineering and Integration Risk Management Technical Organization Relationships with External Technical Organizations Technical Performance Measures and Metrics Technical Activities and Products Results of Previous Phase SE Activities Planned SE Activities for the Next Phase Requirements Development and Change Process Technical Reviews Configuration and Change Management Process Design Considerations Engineering Tools Annex A— Acronyms Systems & SW Engineering
11 Software Development PlanDescribes a developer’s plans for conducting a software development effort in accordance with contractual software requirements. Provides the acquirer insight and a tool for monitoring the processes to be followed for software development. Details methods to be used and approach to be followed for each activity, organization, and resources. Documents all processes applicable to the system to be acquired, at a level of detail sufficient to allow the use of the SDP as the full guidance for the developers. References specific standards, methods, tools, actions, reuse strategy, and responsibility associated with the development and qualification of all requirements, including safety and security. DID DI-IPSC-81427 Source: USAF Weapon Systems Software Management Guidebook – Appendix I Systems & SW Engineering
12 Software Life Cycle ProcessesIEEE 12207, "Systems and software engineering -- Software life cycle processes", is an international standard that establishes a common framework for software life cycle process, with well-defined terminology. Systems & Software Organizational processes Management process Improvement process Training process Primary life cycle processes Acquisition process Supply process Development process Operation process Maintenance process Supporting life cycle processes Audit process Configuration Management Joint review process Documentation process Quality assurance process Problem solving process Verification process Validation process Systems & SW Engineering
13 Comparison of Software to HardwareLike Hardware Can be broken down into manageable parts or pieces Has personal accountability by task Has reportable progress events Is traceable to requirements Relies on a defined set of operating principles and constraints Unlike Hardware Lacks physical appearance and has no “manufacturing” phase Has greater logical complexity Has higher volatility Tends to propagate change effects Is data as well as logic Has limited standardization of design methods, designs, or components Systems & SW Engineering
14 Systems Engineering ProcessLesson Plan Status Overview Systems Engineering Process Work Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems & Software Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
15 DoD Systems Engineering ProcessSystems & SW Engineering
16 Software Development ProcessIEEE 12207, Software Life Cycle Processes Systems & SW Engineering
17 Work Breakdown Structure (WBS)Lesson Plan Status Overview Systems Engineering Process Work Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems and Software Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
18 WBS Definition and OverviewA product-oriented family tree composed of hardware, software, services, data, and facilities. Represents the entire program from the Government Program Manager’s responsibility. Each WBS element provides logical summary levels for: 1) assessing technical accomplishments, 2) supporting the required event-based technical reviews, and 3) measuring cost and schedule performance. Organizes risk management analysis and tracking. Enables configuration and data management. Develops work packages for work orders and material/part ordering. Sources: PMBOK 5, MIL-STD-881C Systems & SW Engineering
19 Software Components in WBSAs part of the Systems Engineering Process, complex systems are decomposed into smaller subsystems and discrete products The software requirements are broken down into Software Items (SI) and further into Software Units (SU) Systems & SW Engineering
20 IT System DecompositionBaselines: Functional Allocated Product Note: “Components” is term for aggregation of SW units; not required on WBS. Systems & SW Engineering
21 WBS Exercise Lesson Plan Status Overview Systems Engineering ProcessWork Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems and Software Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
22 WBS Exercise BackgroundTraining and Help System (THS): THS provides operator and maintainer training to operate and maintain the components of the JTAMS systems to include Unmanned Aerial Vehicles and Unmanned Ground Vehicles. Training is automated and uses screen shots to walk the user through each lesson. Training includes how to use the Parts and Maintenance System (PAMS) to manage parts and supplies, how to load mission packages, how to maneuver their vehicles, how to respond to enemy attacks, how to execute mission packages, how to use the systems navigation systems (and backup systems GPS to Inertial Nav) how to bring the robot home (land or drive back to base), and how to use the Mission Rehearsal System (MRES). The Help system includes calling up the appropriate training modules when specific help is needed. The TAMS Help messages are updated based on the new features as appropriate JTAMS. Trouble-shooting modules are available to handle the unique situations with FUAV, JUGV and JCCS. THS interfaces with the Joint Command and Control System (JCCS) in a read-write mode. Systems & SW Engineering
23 WBS Exercise Develop the Software Components in the WBS for the Training and Help System given the diagram below. Develop 2 Software Items Develop two Software Units per Software item Systems & SW Engineering
24 Technical Reviews Lesson Plan Status Overview Exercise 1Systems Engineering Process Work Breakdown Structure (WBS) WBS Exercise Technical Reviews IT Systems Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
25 SE Technical Reviews Systems & SW Engineering SSRAlternative Systems Review (ASR) Production Readiness Review (PRR) Operational Assessment (OA) Systems Requirements Review (SRR) Operational Test Readiness Review (OTRR) Initial Operational Test & Evaluation (IOT&E) Software Specification Review System Functional Review (SFR) Physical Configuration Audit (PCA) Follow on Operational Test and Evaluation (FOT&E) Preliminary Design Review (PDR) Technology Readiness Assessment (TRA) Critical Design Review (CDR) In-Service Review (ISR) Test Readiness Review (TRR) Developmental Testing (DT) System Verification Review (SVR) Functional Configuration Audit (FCA) Early Operational Assessment (EOA) Systems & SW Engineering
26 Sample System Reviews Systems & SW Engineering
27 Systems & SW Engineering ChallengesLesson Plan Status Overview Systems Engineering Process Work Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems & SW Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
28 SW/SwE Challenges and Best PracticesGeneral increase in system complexity in software reliant systems, due to over-allocation of functionality to software. Customer requirements are often not translated down to the appropriate sub-system, item, component, unit. New design approaches, such as modular open systems approach, are extending the lives of systems now in use. Software failures often occur at the external interfaces. Airlie Council 16 SW Development Best Practices should be considered when engineering software into your system (www.spmn.com). Systems & SW Engineering
29 System/Software Development RequirementsLesson Plan Status Overview Exercise 1 Systems Engineering Process Work Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems and Software Engineering Challenges System/Software Development Requirements Configuration Management Tower Exercise Systems & SW Engineering
30 IT Requirements HierarchiesSystem performance attributes from the CDD (key performance parameters, key system attributes, and other attributes) are translated into system requirements. These requirements are translated into engineering terminology in a system specification, subsequently flowed down to HW/SW subsystems and components. User Specs System Systems & SW Engineering
31 Individual IT Requirement AttributesEvery requirement has one interpretation the interpretation of each requirement is clear. No unnecessary information is included in the requirement. Each requirement is traced to some document or statement of the stakeholders. Each derived requirement must be traceable to an originating requirement via some unique name or number. Each requirement is exclusive of a particular solution. A finite, cost-effective process has been defined to check that the requirement has been attained. Systems & SW Engineering
32 Qualities of Software Requirements Sets (1 of 2)Correct Is a true statement of something the system must do. Complete Describes all significant requirements of concern to the user. Consistent Does not conflict with other requirements. Unambiguous Is subject to one and only one interpretation. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994 Systems & SW Engineering
33 Qualities of Software Requirements Sets (2 of 2)Briefly review this list that is continued from the previous slide. This list of qualities for a good Software Requirements Specification is completed on the next slide. This information comes from Leffingwell and Widrig, 1999, pages Use the questions in the student notes to illustrate the kinds of issues that people should think about when writing good requirements specifications. Verifiable Can be tested cost effectively. Ranked for importance and stability Can be sorted based on customer importance and stability of the requirement itself. Modifiable Changes do not affect the structure and style of the set. Traceable The origin of each requirement can be found. Understandable Comprehended by users and developers. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994 Systems & SW Engineering
34 Requirements and Contractual ArrangementsThe most important requirements are stated as “shall,” to identify mandatory requirements. The second most important requirements are stated as “shall, where practical.” The third most important level of requirements are stated as “preferred” or “should.” The least important requirements are stated as “may.” Systems & SW Engineering
35 Sample Requirements Statements … Valid?The contractor shall allocate the X-Star Satellite System (XSS) requirements identified in the performance specification and shall identify the methods and procedures necessary for verifying compliance with these requirements. The XSS shall provide the capability to support a processing rate of at least 50% above the average aggregate throughput rate for non real-time data. The XSS ground system (XGS) software shall have a Software Reliability (Rsw) of with a Mean Time Software Reboot (MTSWR) of 10 minutes. Systems & SW Engineering
36 Configuration ManagementLesson Plan Status Overview Exercise 1 Systems Engineering Systems Engineering Processes Work Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems and Software Engineering Challenges System/Software Development Requirements Metrics and Technical Performance Measures Modeling and Simulation Configuration Management Tower Exercise Systems & SW Engineering
37 CM Definition Configuration Management is a process of applying administrative and technical procedures throughout the software life cycle to: identify and define software items in a system; control modifications and releases of the items; record and report the status of the items and modification requests; ensure the completeness, consistency, and correctness of the items; and control storage, handling, and delivery of the items. A configuration management plan may also be part of acquisition, supply, development, operation, maintenance plan(s) or any other appropriate plan. Source: IEEE/EIA Systems & SW Engineering
38 Key CM terms Baseline The point at which a document or other object becomes a configuration item. Configuration Control The process of managing change to a configuration item. Configuration Item A document or other object placed under configuration control. Discrepancy An error in software caused either by improperly implementing a correct requirement or failing to implement it. Enhancement A change to a product designed to improve or augment its performance. Source: Systems & SW Engineering
39 Software Configuration ManagementIn software engineering, software configuration management (SCM or S/W CM) is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it. If a configuration is working well, SCM can determine how to replicate it across many hosts. Roger S. Pressman (2009). Software Engineering: A Practitioner's Approach (7th International ed.). New York: McGraw-Hill. Systems & SW Engineering
40 SCM Challenges ISO , Guidelines for the Application of ISO 9001 to the development, supply and maintenance of software. The key issues ISO addresses are: Product exists earlier in software (during design and development) Software product can be [modified and] proliferated easily Focusing on these issues mirrors the guidance in Clause 7.4 of ISO 9000-1:1994: The process of development, supply, and maintenance of software is different from that of most other types of industrial products in that there is no distinct manufacturing phase. Software does not "wear out" and, consequently, quality activities during the design phase are of paramount importance to the final quality of the product. Systems & SW Engineering
41 SCM Lessons Learned Work your plan: Implement and conduct the configuration management activities according to the program's configuration management plan. Use checklists: A basic checklist can assist in capturing the necessary efforts. Automate to manage complexity: If the program is sufficiently complex, identify and install an automated tool to support the configuration management tasks. Consider the other stakeholders (engineers/programmers, users, contractors, interfacing systems, and sustainment organizations) in the selection of any automated configuration management tools. Source: https://www.mitre.org/publications/systems-engineering-guide/acquisition-systems-engineering/configuration-management Systems & SW Engineering
42 SCM Checklist Have all items subject to configuration control been identified in the program plan? Has a closed loop change management system been established and implemented? Has a government configuration control board been established for both development and sustainment? Are impact reviews performed to ensure that the proposed changes have not comprised the performance, reliability, safety, or security of the system? Does the developer's CM create or release all baselines for internal use? Does the developer's CM create or release all baselines for delivery to the customer? Are records established and maintained describing configuration items? Are audits of CM activities performed to confirm that baselines and documents are accurate? Do sponsor, program office, primary developer team, and sustainment organizations have CM systems and expertise? Are developers and managers trained equivalently on CM? Are CM resources across development team interoperable and compatible (i.e., use CVS, CAD/CAM, Requirements Management may represent logistical issues if left unmanaged)? (List excerpt only) Source: https://www.mitre.org/publications/systems-engineering-guide/acquisition-systems-engineering/configuration-management Systems & SW Engineering
43 Software Tower ExerciseLesson Plan Status Overview System Engineering Processes Work Breakdown Structure (WBS) WBS Exercise Technical Reviews Systems and Software Engineering Challenges System/Software Development Requirements Configuration Management Software Tower Exercise Systems & SW Engineering
44 Tower Exercise Refer to the Exercise folder for this lesson to conduct the Tower Exercise. Systems & SW Engineering
45 Today you learned to: Explain the DoD Systems Engineering Process in the context of Information Technology (IT) / Software (SW) Development. Describe the role of the Software Engineer (SwE) in supporting the Systems Engineer (SE). Identify DoD SE technical reviews, technical processes, and technical management processes. Identify SE Lessons Learned & Best Practices when dealing with software. Distinguish the different activities that comprise the SE requirements technical and technical management processes. Given a scenario, recognize aspects of these engineering management principles of Requirements Management, Risk Management, Configuration Management and Interface Management to a development effort. Systems & SW Engineering
46 Backup slides Systems & SW Engineering
47 CM Automation From MIL HDBK 61A: For software, the design evolves through a software engineering process, using a variety of integrated tools, often called the software engineering environment, e.g., Computer-aided software engineering (CASE). The process results in computer based versions of documentation [See Activity Guide: Table 3-9. Software Documentation], source, and executable code for every CSCI [computer software configuration item]. The process the contractor employs to manage the automated software documentation (e.g., software library management and archiving) is similar to the process used to manage automated hardware documentation, although different tools may be employed. Upon close examination, it is fundamentally the same process used to manage the files which contain software code. Example: Multi-User ECP Automated Review System (MEARS) for Engineering Change Proposal (ECP) automation – see next slide Systems & SW Engineering
48 GOTS Tool for CM Multi-User ECP Automated Review System (MEARS) for Engineering Change Proposal (ECP) automation MEARS is a flexible, Software as a Service (SaaS), application that specializes in Configuration Management, Change Management, and Contract Data Requirements List (CDRL) Management. MEARS manages the creation, change and archive of all information in a centralized or distributed data repository (securely or in a secure environment) and provides easy access to all users via visual collaboration capabilities. Developing complex products, manufacturing and maintaining them through their life requires managing evolving product configurations embodying information developed by multiple groups inside the organization and in the supply chain. The challenge of managing complex configurations can lead to costly errors and delays. MEARS provides a comprehensive methodology for managing the configuration (hierarchical set of information) of a product or system throughout its life. Benefits: Government off-the-shelf (GOTS) Product Authorization to Operate (ATO) APMS registered and IRB/DBC approved DoDAF Conformance 100% Reimbursable Joint Interest Program Compliance: MEARS is compliant with DoD standards and policies, such as MIL-HDBK-61A and MIL-STD-973 and its successors. We are certified on the Air Force network, the Navy/Marine Corps Intranet (NMCI), and Army networks. Systems & SW Engineering Government off the Shelf (GOTS) refers to any materials, e.g., software, hardware, documentation, etc., which the government provides to a program, and which typically come from other existing or completed programs.