1. ISA 201 Intermediate Information Systems Acquisition

2. Lesson 6 Systems & Software Engineering
Lesson Point of Contact:
Name: John Rice
Phone:
Read Ahead: None
Length of Presentation:
Presentation: 3.5 hours
Exercise: 0.5 hours (optional)
ELOs
ELO Explain the DoD Systems Engineering Process in the context of an IT/SW Development. (Bloom 2)
MT The SE V with SW Allocated Baseline (SRS and IRS) that are presented during the SSR and PDR
ELO Describe the role of the Software Engineer in supporting the Systems Engineer. (Bloom 2)
ELO Identify DoD SE technical reviews, technical processes, and technical management processes. (Bloom 1)
ELO Identify System Engineering Lessons Learned and Best Practices when dealing with software. (Bloom 1)
ELO Distinguish the different activities that comprise the requirements technical and technical management processes.
ELO Given a scenario, recognize aspects of the engineering management principles of Risk Management, Configuration Management and Interface Management to a development effort. (Bloom 2)
Major Takeways: N/A
Quiz questions:
Which of the following is a formal technical review?
Critical Design Review
Which of the following is NOT one of the Systems Engineering Technical Processes?
Business Case analysis

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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
ELO Explain the DoD Systems Engineering Process in the context of an IT/SW Development. (Bloom 2)
MT The SE V with SW Allocated Baseline (SRS and IRS) that are presented during the SSR and PDR
ELO Describe the role of the Software Engineer in supporting the Systems Engineer. (Bloom 2)
ELO Identify DoD SE technical reviews, technical processes, and technical management processes. (Bloom 1)
ELO Identify System Engineering Lessons Learned and Best Practices when dealing with software. (Bloom 1)
ELO Distinguish the different activities that comprise the requirements technical and technical management processes.
ELO Given a scenario, recognize aspects of the engineering management principles of Risk Management, Configuration Management and Interface Management to a development effort. (Bloom 2)
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms: .
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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

7. Systems Engineering in IT Acquisition
IT 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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Hardware and software development require a systems engineering approach even though different domains. The translation of needs into system production and sustainment, by multidisciplinary teams, is conducted across the lifecycle. Risk management, interface management, configuration management, etc. all apply.
Key Questions to Ask and Anticipated Answers: Isn’t software different since the production phase is simply coding, not manufacturing? The SE process is tailored for software, as shown on subsequent slides. However, the fundamental processes, including code “production” have similarities and SE models still apply.
Terms \ Definitions \ Acronyms: N/A
Systems & SW Engineering

8. Software Engineering in IT Acquisition
According 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: One of the most important responsibilities of SW engineers is conducting engineering a thorough study of the software requirements. Some requirements involve the functions the program needs to carry out. The program may, for example, need to verify that a user is authorized to access it. Other requirements involve constraints, for example, systems already in place. See SW Development Lifecycle chart later in lesson.
Key Questions to Ask and Anticipated Answers: What competencies are required of SW engineers? Acquiring a core of software development knowledge that will remain relatively stable across a span of years, even as new languages are developed and others go out of favor. Standard relating to this knowledge is IEEE Std , "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. This standard defines a comprehensive set of processes that cover the entire life-cycle of a software system – from the time a concept is made to the retirement of the software.
Terms \ Definitions \ Acronyms: N/A
Systems & SW Engineering

9. Lesson 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

10. Systems Engineering Plan
Introduction—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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Systems engineering planning addresses the scope of the technical effort required to develop the system. The basic questions of “who will do what” and “when” are addressed. As a minimum, a technical plan describes what must be accomplished, how systems engineering will be done, how the effort will be scheduled, what resources are needed, and how the systems engineering effort will be monitored and controlled. The planning effort results in a management-oriented document covering the implementation of program requirements for systems engineering, including technical management approaches for subsequent phases of the life cycle. In DoD it is an exercise done on a systems level by the government, and on a more detailed level by contractors.
Key Questions to Ask and Anticipated Answers: Why do we need another document just to perform basic SE processes? The document is the outcome of SE planning, not a document for document’s sake. Plus it can be used by other members of the project office to get familiar with the system, organization, schedule, etc.
Terms \ Definitions \ Acronyms: N/A
Systems & SW Engineering

11. Software Development Plan
Describes 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Source: USAF Weapon Systems Software Management Guidebook – Appendix I
Systems & SW Engineering

12. Software Life Cycle Processes
IEEE 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

13. Comparison of Software to Hardware
Like 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Similarities and differences between hardware and software dictate differing approaches to SE. Functionality may dictate hardware or software implementations, although with the trend towards software intensive systems more functionality is being incorporated into software (e.g. fly by wire aircraft vs. manually controlled).
Key Questions to Ask and Anticipated Answers: What is driving the trend toward software intensive systems? Software has no physical constraints (size/weight). It can be replicated and distributed with minimal cost and effort. Code can now be auto-generated and computer system processing / memory / input-output can provide improved performance.
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

14. Systems Engineering Process
Lesson 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

15. DoD Systems Engineering Process
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: Identify DoD SE technical reviews, technical processes, and technical management processes
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: The Vee is essentially decomposition (design) and realization (build and test). Verification and validation link each side of the Vee as requirements are determined to be “built right” and “the right thing built”, resp. In addition, the technical management processes are a means of controlling the technical processes of the Vee. Maintaining databases for requirements, configurations, risks, data, et.al. is key to effective technical management. Automated tools are available for these activities.
Key Questions to Ask and Anticipated Answers: Can these steps be revisited during the development process? Yes, the process is iterative and certain steps may need to be repeated or refined. For example, analysis of user requirements may result in discovery of invalid requirements with a return to the user for clarification/modification.
Terms \ Definitions \ Acronyms: IOC—Initial operational capability; FOC- full operational capability
Systems & SW Engineering

16. Software Development Process
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: Identify DoD SE technical reviews, technical processes, and technical management processes
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: IEEE/EIA 12207, Software Life Cycle Processes, describes the U.S. implementation of the ISO standard on software processes. This standard describes the development of software specifications as one aspect of the software development process. The process described in IEEE/EIA for allocating requirements in a top-down fashion and documenting the requirements at all levels parallels the systems engineering process. The standard requires first that system-level requirements be allocated to software items (or configuration items) and that the software requirements then be documented in terms of functionality, performance, and interfaces, and that qualification requirements be specified. Software item requirements must be traceable to system level, and be consistent and verifiable.
Key Questions to Ask and Anticipated Answers: Why aren’t systems engineers involved at the SI level and below? The efforts involving SIs, components and SUs fall into the category of design engineering (in the example; IT/Software Engineering) which is enabled by Systems engineering activities. However, going back to the definition of SE, “SEs are concerned with the whole system and take a top-down, interdisciplinary approach to design and management.” There may be risks, configurations, trade studies at the SI-level and below, that need to be conducted by SE’s, but these are technical management activities vs. design actions.
Terms \ Definitions \ Acronyms: SI—software item, HI—hardware item, DT—Developmental testing, OT&E—operational test & evaluation
IEEE 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

18. WBS Definition and Overview
A 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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Sources: PMBOK 5, MIL-STD-881C
Systems & SW Engineering

19. Software Components in WBS
As 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)
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: Identify DoD SE technical reviews, technical processes, and technical management processes
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
The SI is still too high a level to design and code directly so they are further broken into Software Units
SW Units are then designed, coded and tested
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
SI = Software Item
SU = Software Unit
SCI = Software Configuration Item. When a SI is identified for configuration control it is called an Software Configuration Item (SCI)
Systems & SW Engineering

20. IT System Decomposition
Baselines:
Functional
Allocated
Product
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: Identify DoD SE technical reviews, technical processes, and technical management processes
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
The decomposition of an IT system maps the physical elements to activities or products. In this case, technical reviews (and their associated configuration baselines) and lifecycle products (artifacts) are linked to the elements in the system, subsystems and lower-level items. The SU is the lowest-level element in an IT system decomposition and is aligned with coding and the CDR.
Key Questions to Ask and Anticipated Answers:
Why aren’t systems engineers involved at the SI level and below? The efforts involving SIs, components and SUs fall into the category of design engineering (in the example; IT/Software Engineering) which is enabled by Systems engineering activities. However, going back to the definition of SE, “SEs are concerned with the whole system and take a top-down, interdisciplinary approach to design and management.” There may be risks, configurations, trade studies at the SI-level and below, that need to be conducted by SE’s, but these are technical management activities vs design actions.
Terms \ Definitions \ Acronyms: N/A
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 Process
Work Breakdown Structure (WBS)
WBS Exercise
Technical Reviews
Systems and Software Engineering Challenges
System/Software Development Requirements
Configuration Management
Tower Exercise
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

22. WBS Exercise Background
Training 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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Exercise
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Provides background for THS decomposition
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Provides Template for proposed THS WBS
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

24. Technical Reviews Lesson Plan Status Overview Exercise 1
Systems 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
SSR
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Track how the DoD information technology systems engineering process supports DoD Acquisition Management processes
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: A depiction from the Lifecycle Framework Chart with technical reviews shown. The purpose of technical reviews is largely to identify and manage risk in a program. Entrance and exit criteria are provided and must be met, or a plan of action must be defined, to proceed into the next lifecycle phase. PDR and CDR are two required reviews and are critical to project success.
Instructors should point out the relationship between tech reviews and configuration baselines: Function Baseline is associated with SFR, Allocated Baseline is associated with PDR, and the Product Baseline is associated with CDR
Key Questions to Ask and Anticipated Answers: Can a review be skipped? Not all reviews are required on every program. However, the intent of the review is to assess technical maturity, risk and other developmental progress. If a review is not held, the intent of the review should be assured. For major programs, PDR and CDR are required per DoDI 5000.
Terms \ Definitions \ Acronyms: N/A
Alternative 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Track how the DoD information technology systems engineering process supports DoD Acquisition Management processes
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: System-level technical reviews are generally timed to correspond to the transition from one level of development to another. The technical review is the event at which the technical manager verifies that the technical maturity of the system or item under review is sufficient to justify passage into the subsequent phase of development, with the commitment of resources required. As the system or product progresses through development, the focus of technical assessment takes different forms. Early in the process, the primary focus is on defining the requirements on which subsequent design and development activities will be based. Similarly, technical reviews conducted during the early stages of development are almost always focused on ensuring that the top-level concepts and system definitions reflect the requirements of the user.
Key Questions to Ask and Anticipated Answers: Are all of these reviews feasible for software? Yes, even PCAs are conducted on both hardware- and software-configured products. The PCA verifies that the product corresponds to the build-to (or code-to) product baseline documentation previously approved at the CDR.
Terms \ Definitions \ Acronyms: N/A
Systems & SW Engineering

27. Systems & SW Engineering Challenges
Lesson 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

28. SW/SwE Challenges and Best Practices
General 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 (
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: With budgetary pressures in particular, several of the above challenges become more prominent. Affordability is mandated and that may impact quality of new systems or compromise modernization of existing systems. This elevates the technical management processes of risk management, interface management, configuration management, decision analysis, etc. as systems are repaired rather than replaced. Extending system life carries inherent risk and may result in obsolescence, another challenge more prominent in tight budget environments.
Key Questions to Ask and Anticipated Answers: How can open systems architecture benefit SE? OSA mitigates the situation of proprietary interfaces and vendor lock while allowing for compatible upgrades using commercial off the shelf components. A simple 110 Hz electrical outlet in the US is an open interface and upgraded equipment can be connected to the power source even with more technological advances to the interfacing unit.
Terms \ Definitions \ Acronyms: N/A
Systems & SW Engineering

29. System/Software Development Requirements
Lesson 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

30. IT Requirements Hierarchies
System 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: The CDD includes the Key Performance Parameters (KPPs) which are decomposed into system requirements, subsystem and component/CI requirements. Described as parent-child relationship in flowdown/traceability in requirements management process.
Key Questions to Ask and Anticipated Answers: Can KPPs from the CDD be stated verbatim in specifications as requirements? No, requirements in systems specifications and lower-level requirements documents must be specified in performance terms; KPPs are provided by the user and are decomposed/derived into requirements statements.
Terms \ Definitions \ Acronyms: CDD—Capabilities Description Document
Systems & SW Engineering

31. Individual IT Requirement Attributes
Every 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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Requirements are only as good as the requirements statement in the specification documents. Multiple characteristics determine the “goodness” of these statements. For example, the characteristic that a requirement be verifiable means it must be measurable as verification involves some method of quantitatively proving a requirement has been incorporated into the system build.
Key Questions to Ask and Anticipated Answers: What is meant by design independent? This allows trade space rather than a point- or limited- solution set. The implementation of the requirement should allow enough flexibility for innovative solutions, rather the forcing a specific solution.
Terms \ Definitions \ Acronyms:
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Correct
Does every requirement state something required of the system?
“A set of requirements is correct if and only if every requirement stated therein represents something required of the system to be built.” Davis (1993)
It is not possible to determine if a requirement is correct simply by reading the requirement. The correctness is verified by a subject-matter expert during a review.
Complete
Does the set of requirements include all significant requirements, whether related to functionality, performance, design constraints, attributes, or external interfaces?
Have the expected ranges of input values in all possible scenarios been identified and addressed?
Have responses been included to both valid and invalid input values?
Do all figures, tables, and diagrams include full labels, references, and definitions of all terms and units of measure?
Consistent
Is it internally consistent, with no subset of individual requirements described which are in conflict? (Examples: Vision document, the use-case model, and the Supplementary Specifications.)
Unambiguous
Does each requirement have one, and only one, interpretation?
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms: .
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Verifiable
Is every requirement stated verifiable?
Is there some finite cost-effective process with which a person or machine can check that the software product meets the requirement?
Ability to Rank Requirements
Has each requirement been tagged with an identifier to indicate either the importance or stability of that particular requirement?
Modifiable
Are the structure and style of the requirements in the software requirements set (use cases, supplementary specification, or software requirements specification) such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style?
Has redundancy been identified, minimized, and cross-referenced?
Traceable
Does each requirement have a clear identifier?
Is it distinguishable from non-essential statements in the requirements set?
Is the origin of each requirement clear?
Is backward traceability maintained by explicitly referencing earlier artifacts?
Is a reasonable amount of forward traceability maintained to artifacts spawned by the requirements set? For example, test cases.
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms: .
Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994
Systems & SW Engineering

34. Requirements and Contractual Arrangements
The 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.”
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: Words matter, especially as they relate to legally binding agreements. The hierarchy shown has a basis in contract law and is very important in systems engineering. In particular, the use of “shall” for mandated requirements binds the contractor to incorporate the requirement or risk breach of contract.
Key Questions to Ask and Anticipated Answers: Is it valid to state “the contractor shall…” in a requirements specification? No, the reqmt should be stated as “the system shall…” since it is a performance spec. The statement of work would specify tasks in term of what the contractor shall conduct.
Terms \ Definitions \ Acronyms: N/A
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points: The first requirement is not good, it really should be an entry in the contractor’s Statement of Work (SOW) not in the requirements document. Requirements two and three are valid as they relate to performance.
Key Questions to Ask and Anticipated Answers: What section of a performance spec contains requirements? Section 3 of a system performance specification contains requirements, while section 4 contains verification methods.
Terms \ Definitions \ Acronyms: Examples of SW Metrics:
Software Reliability (Rsw) is the probability that any given software session will be successful
Rsw = Number of successful session/Total number of sessions
Software Maintainability: Mean Time Software Reboot (MTSWR) is the time required to restore the system to a useful state following a system interruption using the normal initiation method
MTSWR = Total Elapsed Time to Restore a SW Intensive System/Total Number of SW Restorations
Systems & SW Engineering

36. Configuration Management
Lesson 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Source:
Systems & SW Engineering

39. Software Configuration Management
In 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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Source:
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 of SourceSafe, CVS, CAD/CAM, Requirements Management, and Subversion may represent logistical issues if left unmanaged)?
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Source:
Systems & SW Engineering

43. Software Tower Exercise
Lesson 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
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
Systems & SW Engineering

44. Tower Exercise
Refer to the Exercise folder for this lesson to conduct the Tower Exercise.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Exercise
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
FYI, I typically show a TED Talks video after the tower
exercise in lesson 6, Systems Engineering. Here's the link if you want to
check it out:
If the link doesn't work, you can do a Google search for 'Ted talks build a
tower build a team.'
I think it ties in well to the tower exercise and helps conclude the lesson,
if you'd like to consider incorporating it into the lesson in the future.
V/R,
Stephani
STEPHANI D. HUNSINGER, Lt Col, USAF
Professor of Acquisition Management
Defense Acquisition University, CNE-ET
9820 Belvoir Rd
Fort Belvoir, VA
Office: (703) ; DSN
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms: .
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms: .
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID: ELO Explain the nuances of the Systems Engineering process for IT systems compared to the process for developing and acquiring hardware-based systems
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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.
SLIDE INFORMATION***************************************************************************************************************************
*Slide Type: Content (Content or Exercise)
*Supporting ELOs ID:
*Policy / Directive / Standard / DTM ID: **********************************************************************************************************************************************************
Key Points:
Key Questions to Ask and Anticipated Answers:
Terms \ Definitions \ Acronyms:
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.