Intermediate Systems Acquisition Course. Software Design

Transcription

1 Software Design The development and integration of software is a complex and challenging aspect of system acquisition. History demonstrates that building information systems is a very involved undertaking with a high degree of risk and uncertainty. To reduce risks and uncertainty, you must select the appropriate development methodology (given your program's unique characteristics), use best practices, and comply with congressional policy. This lesson addresses how software systems are developed within the Department of Homeland Security (DHS). Understanding the common DHS processes and rules that govern and guide the development process is critical to the success of today's complex software-intensive systems. This lesson will also address how acquisition professionals are responsible for complying with the Clinger-Cohen Act and the Federal Information Technology Acquisition Reform Act (FITARA) in the development of software and software intensive systems. It will also discuss software development best practices. You may print or save the Software Design lesson for future reference. Page 1 of 25

2 Objectives Upon completion of this lesson, you should be able to: Identify software development life cycle activities and standards Identify software development best practices essential for creation of high-quality software Discuss the importance of interoperability of software-intensive systems as they relate to network applications Discuss how the Clinger-Cohen Act and Federal Information Technology Acquisition Reform Act (FITARA) relate to software-intensive system designs Page 2 of 25

3 Overview of Software Development There are several key activities for software development commonly used at DHS. Sequence and level of detail for each area are outlined in the Systems Engineering Life Cycle (SELC) tailoring plan. Software development includes the following tasks. The tasks are iterative. Requirements Analysis Design Coding and Testing Integration and Testing Software Unit Integration & Testing Software Qualification Testing Section 508 Testing Page 3 of 25 Requirements Analysis: In this activity, requirements are analyzed to determine an optimal functional architecture, interfaces are defined, and performance parameters are allocated for both hardware and software. Software requirements analysis determines the detailed requirements for each software item (SI). The detailed software requirements specification becomes the blueprint for each SI to be developed. Design: Using outcomes from system requirements analysis, system design transforms the set of requirements into a toplevel solution. The system design determines which requirements are best performed through software, and guides the selection of blocks of code known as Software Items (SIs). Coding and Testing: During this activity, code is written and implemented for each software unit. Each software unit is then tested in a stand-alone mode. Integration and Testing: This activity involves integration and testing of various hardware items and software items (SIs) that can make up a subsystem. Software Unit Integration & Testing: This activity involves progressive integration of the units making up a software item (SI) and testing their operation with one another, including internal interfaces.

4 Software Qualification Testing: This activity involves high-level technical testing designed to qualify the entire system against its systems-level requirements, which are typically described in the System Specification. Section 508 Testing: In 1998, Congress amended the Rehabilitation Act of 1973 to require Federal agencies to make their electronic and information technology (EIT) accessible to people with disabilities. The law (29 U.S.C. 794 (d)) applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508, agencies must give disabled employees and members of the public access to information that is comparable to access available to others.

5 Software Development at DHS "The Systems Engineering Life Cycle (SELC) allows a program/project to employ any software development methodology that it chooses, so long as there is a reasonable basis for choosing the selected development methodology and the choice and rationale for its selection have been appropriately documented in the program/project SELC Tailoring Plan. Programs may also choose to employ different development methodologies on its projects depending upon each project s unique characteristics/attributes. Many programs are comprised of multiple projects that each have different technical development approaches." DHS Systems Engineering Life Cycle Guidebook, "For information technology (IT) programs and projects, DHS has established agile development as the preferred developmental approach. Programs/projects implementing agile development are still subject to the requirements of the Acquisition Lifecycle Framework (ALF) and the Systems Engineering Life Cycle (SELC)." Instruction , Agile Development and Delivery for Information Technology The reason for choosing the software development methodology must be documented in the tailoring plan. DHS directs program managers to take an "Agile-First" approach to software development. For an agile software development effort, most or all of the activities of the SELC still take place, but in a different sequence or different way; these differences must be documented in the tailoring plan. You can find examples in the SELC Tailoring Examples for Selected Types of DHS Acquisition Programs document. Page 4 of 25

6 Requirements Engineering In order to succeed, the software developer must have a clear and complete understanding of requirements: Requirements engineering affects all aspects of systems development and maintenance because changes in requirements in one project may affect other related systems. For example, changes in requirements for a development project may affect the maintenance of existing systems, as well as the requirements of parallel development efforts. Requirements engineering involves communications among many internal and external stakeholders, such as systems engineers, operators, end-users (including persons with disabilities), contractors, and oversight agencies. Therefore, effective communication plans and activities must be established and implemented with appropriate levels of detail for all stakeholders. - Adapted from the Requirements Engineering Section of a Software Engineering Institute (SEI) article titled, A Framework for Software Product Line Practice. Page 5 of 25

7 Requirements Engineering in DHS The DHS Requirements Engineering User's Guide provides a series of related activities and products that must be addressed when engineering requirements for information technology (IT) projects. These include: Identify desired business capabilities from activities conducted as part of strategic planning, enterprise engineering, operations, and other components of the enterprise life cycle Create a Concept of Operations (CONOPS), a Business Impact Assessment, and subsequent requirements documents, including: Operational Requirements Document (ORD) Requirements Traceability Matrix Functional Requirements Document (FRD) System Requirements Document (SRD) NOTE: On an agile software development effort, the FRD and the SRD may be replaced by a Capability and Constraints (CAC) document and the Product logs. Establish an appropriate set of activities, products, tools, and techniques to support development of systems and/or components. These include testing, prototyping, modeling, analyses, documentation and communication of trade-off decisions and results. These efforts should align to best practice organizations (e.g., Project Management Institute (PMI), Institute of Electrical and Electronics Engineers (IEEE)), and show evidence of successful execution in support of the DHS mission. Page 6 of 25

8 Software Development Best Practices To reduce risk and uncertainty, best practices that have been developed over time should be used to provide a robust approach to software development. Here are six best practices for software acquisition based on the Airlie Council in 1994, and they still apply today. Formal Risk Management Agreement on Interfaces Metric-Based Scheduling and Tracking Program-Wide Visibility of Progress versus Plan Configuration Management (CM) Testing Let's examine each one. Page 7 of 25

9 Formal Risk Management All information and software-intensive development systems have risk. The cost of resolving risk is low in the early stages of a project, but usually increases dramatically with time. A formal risk management process requires: The acceptance of risk as a major consideration for management The commitment of resources to properly do risk management The use of formal methods to identify, monitor, and control risk Risks may become realities, and then they are issues. The goal of formal risk management is to identify and mitigate risks before they become issues whose management is much more difficult. Refer to the earlier lesson on risk management for more information. D Page 8 of 25 Graphic depicting the risk management process. Risk Management includes four activities: planning, assessment, handling, and monitoring. Risk assessment includes both identification and analysis. Documentation is important throughout the process.

10 Agreement on Interfaces To mitigate technical risk, a baseline user interface specification should be agreed upon before implementation activities actually start. For projects involving development of both hardware and software, there should be a separate software specification with explicit and complete interface descriptions. For example, a Global Positioning System requires both hardware and software to operate. The interface components of the software will determine how the user operates the device, with touch screen options and various features like voice activation. Page 9 of 25

11 Metric-Based Scheduling and Tracking A good software measurement program can become the yardstick for measuring progress and can function as an early-warning system. To do this well, the PM should calculate size metrics, estimate costs, and establish schedules early, then track project status continuously through the use of metrics. Page 10 of 25

12 Program-Wide Visibility of Progress versus Plan When everyone is involved in identifying problems early, the likelihood of missing problems is greatly reduced. Early problem identification improves risk management and leads to project success. Core indicators of project health should be readily available to all personnel. Feedback channels should be encouraged to enable bad news to move up and down the project hierarchy, rather than keeping bad news 'close hold.' The chart on this page displays common agile software development metrics. D Select the image to view an enlargement Page 11 of 25 A variety of agile software development metric charts including a release burndown chart, release velocity chart, sprint burndown chart, and team velocity chart.

13 Configuration Management Configuration management (CM) is an integrated process for identifying, documenting, monitoring, evaluating, controlling, and approving all changes made during the life cycle of a program. Version control is a critical part of configuration management. Because software is essentially an 'invisible' and highly complex product, software configuration management is vital to the control of software-intensive system development. For softwareintensive systems, configuration management failure guarantees chaos. D Page 12 of 25 Graphic indicating that changes involve four activities, completed iteratively: Identify, Evaluate, Approve, and Control.

14 Testing Testing is a critical activity during software development, and should occur continuously. Along with testing, both formal and informal inspections are essential, as well as technology demonstrations. Some testing is manual, and some is automated. A person must manually conduct code reviews to ensure that the software development effort has the right overall approach to the code, and that it is in line with coding standards. Before time and money are spent fully developing the system, it is important to validate the fundamental architecture of the code. Automated testing ensures that the code functions the way that it is supposed to; however, it can only perform the testing for which it is designed. For example, it can ensure that planned security measures are in place for known threats. Manual testing, on the other hand, looks for problems caused by misuse and human error that were not anticipated by the automated testing. What will happen if a user enters the wrong information into the system? What happens when a person tries to hack into the system? During manual testing, people try to break the system to uncover its weaknesses. Finally, manual testing is important to ensure the system is user-friendly. Page 13 of 25

15 Plan-Do-Review at the Sprint Level Agile software development efforts usually work in "sprints." A sprint covers a short period of time, typically 1-4 weeks. A sprint is the opposite of the common term "milestone." A milestone is a major high-level system or programmatic event that is typically widely separated in time from other milestones. The Plan-Do-Review best practice is an agile approach that works well for information and software-intensive systems. Adopted from the commercial sector, it can be broken down into the following parts, which are completed iteratively: Plan the Work Do the Work Review the Work This best practice states that to adequately control software projects, Program Management Offices should: Encourage developers to divide up work into small packages Establish project-relevant quality criteria for those packages Avoid accepting percent complete as a metric for them, using instead more discrete measures of performance Page 14 of 25 Plan the Work: The team determines at the beginning of a sprint what will be completed and what constitutes completion, i.e., "Definition of Done." At the end of the sprint, those tasks are either done or not done. Under this approach, no partial credit (e.g., we are 85% complete with module XYZ...) is allowed. Review the Work: Reviews may take the form of sprint reviews and demonstrations, standard technical reviews, completion of specification qualification tests, or project audits.

16 Software Acquisition Management Promising Practices In addition to the nine best practices previously discussed, there is a list of "Promising Practices" for software acquisition management, known as the 16 Critical Software Practices for Performance- Based Management. Select each button below to review these best pratices. Page 15 of 25 Project Integrity: Adopt continuous risk management Estimate cost and schedule empirically Use metrics to manage Track earned value Track defects against quality targets Treat people as the most important resource Construction Integrity: Adopt life cycle configuration management Manage and trace requirements Use system-based software design Ensure data and database interoperability Define and control interfaces Design twice, code once Assess reuse risks and costs

17 Product Stability and Integrity: Inspect requirements and design Manage testing as a continuous process Compile and smoke test frequently

18 Knowledge Review The DHS Office of Health Affairs (OHA) has a mission requirement to provide for medical preparedness against public health threats both naturally occurring and man-made. OHA is developing a software program to virtually exercise their capabilities to demonstrate and test governmental preparedness. After the program development budget has been 50% expended, OHA discovers that the specifications for the portal that OHA personnel will use to access a database at the Federal Emergency Management Agency, where a significant amount of data resides, have not been finalized. What best practice does this violate? A. Formal Risk Management B. Defect Tracking Against Quality Targets C. Metric-Based Scheduling and Tracking D. Agreement on Interfaces Correct! Agreement on Interfaces will prevent vague, inaccurate, and untestable interface specifications. In this case, the interface requirements were not finalized. Page 16 of 25

19 Measuring Software Technology Maturity Two other considerations for acquiring IT are maturity of software and the need for interoperability with other systems. The technology readiness levels (TRLs) you learned about in a previous lesson apply to software as well. Software developers can use these TRLs to assess the maturity of available software components to be used in a system's design. The overall system software TRL would be considered at reviews to convey to management the risk of chosen approaches. D Select the image to view an enlargement Select the D-link to read a detailed explanation of the graphic Page 17 of 25 An image of a thermometer representing how technology readiness levels are measured from levels 1 through 9, with descriptions of each level to the right of the thermometer, and labels of how the levels overlap appearing on the left side. Basic Technology Research occurs during TRL 1 and 2. Level 1 is when basic principles are observed and reported, and level 2 is when the technology concept and/or application is formulated. Research to Prove Feasibility occurs during TRL 2 and 3. Level 3 is when the analytical and experimental critical function and/or characteristic proof-of-concept is developed. Technology Development occurs during TRL 3, 4, and 5. Level 4 is when component and/or prototype validation in a laboratory environment occurs, and level 5 is when component and/or prototype validation in a relevant environment occurs. Technology Demonstration occurs during TRL 5 and 6. Level 6 is when system/subsystem model or prototype demonstration in a relevant environment occurs. System/Subsystem Development occurs during TRL 6, 7, and 8. Level 7 is when system prototype demonstration in an operational environment occurs and level 8 is when the actual system is completed and mission qualified through test and demonstration. System Test Launch and Operations occurs during TRL 8 and 9. Level 9 is when the actual system is successful through mission-proven operational capabilities.

20 Software Interoperability Interoperability is a key performance parameter (KPP) for many homeland security systems, especially those that need to exchange data with other systems across federal, state, and local boundaries. We can define interoperability as follows: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units." ISO/IEC (International Organization for Standardization/International Electrotechnical Commission) , Information Technology Vocabulary, Fundamental Terms With respect to software, the term interoperability is used to describe the capability of different programs to exchange data via a common set of exchange formats, to read and write the same file D Page 18 of 25 Graphic showing that computer internet connectivity is worldwide, and involves digital surveillance, personal computing, home system, and access control.

21 Software Interoperability Defined Interoperability may also be defined as the: Ability of a system, unit, or personnel to provide services to, and accept services from, other systems, units or personnel; the services exchanged enable them to operate effectively together Condition achieved between systems when information or services are exchanged directly and satisfactorily between the system and the users In economics and business, a network effect is the impact that one user of a good or service has on the value of that product to other users. For DHS, the negative impact of poor interoperability is poor service to all users. Page 19 of 25

22 Achieving Interoperability Here are some points to promote software interoperability: Ensure data and databases use standard data in systems to facilitate information sharing Systems and software should be designed, consistent with U.S. export control laws, so as to permit their use in a multi-national environment Interoperability can be difficult to achieve with commercial-off-the-shelf (COTS) software, which can add or change features rapidly with little attention to backward compatibility Interoperability issues may arise when coordinating the design, development, and deployment of increments from multiple systems and systems of systems Technology companies often don't have the resources, need, desire, or profit motive to address interoperability Achieving interoperability acr/ ss simultaneously evolving systems-of-systems is extremely difficult Page 20 of 25

23 Achieving Interoperability (continued) Here are a few more points related to achieving interoperability: The Government's investment framework must include a process for ensuring interoperability with other systems and increments from other software-intensive capital assets Component systems must successfully complete a synchronization event to demonstrate interoperability before deployment An operational architecture is a set of elements consisting of information exchange requirements, mission area interactions, tasks, interoperability tables, logical connectivity, and a description of the environment where the information system is to be operated A technical architecture identifies the services, interfaces, standards, and their relationships; it also: Defines systems rules Establishes standards for interoperability Applies technology references that influence architecture decisions Page 21 of 25

24 Knowledge Review FEMA has a requirement to implement and maintain a data warehouse containing information on all issues relevant to a natural disaster. FEMA will have to ensure that the Office of Health Affairs (OHA) can access the database, as well as input raw data, since OHA oversees the health aspects of contingency planning for chemical, biological, radiological, and nuclear hazards. FEMA is considering buying a commercial off-the-shelf (COTS) software package for this purpose. Which of the following is a negative impact typically associated with COTS programs? A. Interoperability can be difficult to achieve across simultaneously evolving systems B. ward compatibility can be a problem when new features have been added to the software C. Standard databases may not be available Incorrect! The correct choice is B, ward compatibility can be a problem when new features have been added to the software. COTS software can often add or change features with little attention to backward compatibility. Page 22 of 25

25 Clinger-Cohen Act and FITARA As you learned earlier in this course, the Clinger-Cohen Act is the umbrella federal legislation for IT and software-intensive systems. The act mandates effective IT system management, requires that acquisitions support core missions, and requires process reengineering. Key areas of particular emphasis in the Clinger-Cohen Act include: The act established a Chief Information Officer (CIO) in each federal agency; the CIO must certify Clinger-Cohen Act compliance on all major IT investment programs Agencies are required to design and implement a capital planning and investment control (CPIC) process for making IT investment decisions; IT investment decisions must be made based on measurable criteria Agencies must develop strategic performance goals for every IT system to evaluate results and benefits; periodic cost, schedule, productivity, and quality assessments are required The Federal Information Technology Acquisition Reform Act (FITARA) establishes an enterprise-wide approach to federal IT investment, promotes cross-functional partnerships between the CIO and key senior agency officials, provides an opportunity to move to a more disciplined and "agile" IT investment strategy, and emphasizes IT and asset management to facilitate valuedelivery of IT investments and resource planning. Implementation of FITARA at DHS is managed by the Enterprise Business Management Office (EBMO). Page 23 of 25

26 Agile Software Development at DHS Instruction Agile Development and Delivery for Information Technology establishes agile software development as the preferred developmental approach at DHS. This instruction applies throughout DHS to all IT acquisitions (e.g., programs, projects, or activities) whose purpose is to deliver an IT, or embedded-it, capability. The DHS agile framework does not mandate a specific agile method. Programs/projects implementing agile development are still subject to the requirements of the Acquisition Lifecycle Framework (ALF) and the SELC. Agile Development is defined as: Select the image to view an enlargement Select the D-link to read a detailed explanation of the graphic An iterative and incremental approach to developing IT capabilities where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams. Agile development promotes continuous adaptive planning, development, testing, and delivery/integration, and encourages rapid and flexible response to change. Agile is not one specific methodology, but is a conceptual framework implemented through various agile methods that promote delivering working, tested, deployable IT solutions on an incremental basis to increase value, visibility, and adaptability, and to reduce program/project risk. You can find more information and details about agile at DHS on the DHS Agile Center of Excellence website. D Page 24 of 25 Graphic depicting the agile scrum framework. The Product Owner receives inputs from executives, the team, stakeholders, customers, and users. The Product log is a ranked list of what is required, including features and stories. At the sprint planning meeting, the team selects from the backlog, starting at the top, as much as it can commit to deliver by the end of the sprint. The sprint backlog contains the task breakouts. During the 1 to 4 week sprint, the sprint end date and the team deliverable do not change. The scrum master provides metrics such as a burndown or burnup chart, and the team holds a daily scrum meeting every 24 hours. At the end of the sprint, the team holds a sprint review and goes over the finished work. The team also holds a sprint retrospective meeting.

27 Summary Software development involves a series of tasks, not always in the same order, including requirements analysis, design, coding of software units, and integration and testing of completed software items. Along the way, the Systems Engineering Life Cycle (SELC) provides a structure of activities and reviews to assess progress, manage risk, and support program decisions. Many methodologies are available for developing software, and DHS expects program managers to select the appropriate methodology to reduce risk. The choice should be based on factors such as stability of requirements, level of risk, and whether or not a precedent for the software exists. The SELC should be tailored to the fit the unique characteristics of each project. Best practices have been drawn from past experience to guide software development efforts. This lesson offered best practices to promote project integrity, sound construction, and product stability. Interoperability, the ability of programs to exchange data via a common set of formats and protocols, is an important but challenging requirement for many homeland security systems. The Clinger-Cohen Act and Federal Information Technology Acquisition Reform Act (FITARA) mandate changes in information technology management to ensure software and hardware investment decisions are tied to strategic performance goals. You may print the Software Design lesson or save it for future reference. Please select the next lesson from the table of contents to continue with the course. Page 25 of 25