Once software development Is late, adding more resources typically results In making the project even later. Software Risk Management Most software development projects are very large and complex. Breaking a software-intensive project into more manageable parts helps the people Involved better understand the tasks and resources needed. By understanding the complexity of an effort, managers are better able to plan and manage the risk. Software Items (SSL): The Building Blocks As part of the Systems Engineering Process, the software Is usually broken down Into smaller building blocks called Software Items (SSL).
After being developed and individually tested, Software Items are integrated with the hardware and ultimately the entire system. A Software Item (SSL) is a collection of software that performs closely related functions. Each SSL Is uniquely designated throughout the life cycle for purposes of: Conducting qualification testing. Controlling interfaces. Ensuring configuration management. Mitigating risk. Note: In the past, Software Items were called Computer Software Configuration Items (CICS).
SIS and Work Breakdown Structures As you learned in a previous lesson, a Work Breakdown Structure (WEBS) divides employ projects into pieces so that risks can be identified and managed. As illustrated below, WEBS can be used to organize the Software Items (SSL) and to show the relationship among the different system components. 2 Software Units To facilitate programming, Software Items (SSL) can be broken down into smaller, logically related pieces. Many commercial standards call these pieces “Software Units. ” Software Units include individual programs such as modules or routines that perform specific functions.
Development Paradigms In an earlier lesson, you learned about the importance of structuring a tailored acquisition or program strategy. The software developer uses a similar structured approach to lay out software development tasks. These different ways of laying out tasks are referred to as “software development paradigms. ” What Are Paradigms? In a software engineering context, the approaches to structuring software development are frequently called “Software Development Paradigms. ” A more common word for paradigm is model.
Types of Paradigms (Models) The three common software development models are called: Waterfall Paradigm Incremental Paradigm Spiral Model The Waterfall Paradigm is implemented using a sequential process. In the traditional Waterfall Paradigm: Each stage is a prerequisite for succeeding activities. Successful completion of a stage is required before starting the next one. Formal reviews are used to assess the completion of each stage. As illustrated below, the developer must be able to accurately estimate the difficulty of all required steps. Therefore, the Waterfall Paradigm works best with a precedent supersensitive system. Precedent System A Precedent System includes the following characteristics: Stable system and software requirements, not significantly different than those of rebelliously developed system(s). Systems engineering and software development teams with previous experience developing similar systems. The Incremental Paradigm involves developing “pieces” of the software for a system in a series of incremental steps. There are many variations of this paradigm. When an incremental approach is used, it is important to make sure that the developer is prepared to build and integrate all of the increments.
When using this model, special emphasis should be placed on the selection of the items to be included in the last increment. Sometimes the last increment can be the hardest to complete! When incremental development is used, an Integrated Product Team (PIT) may be used to help define the number, size, and phasing of the increments. Involving the PIT can reduce risk and ensure that all of the user’s requirement will be satisfied by the increments. 4 The Spiral Model is a risk-driven prototyping approach to software development. This model: Identifies high-risk areas (e. G. User interface, cost, performance constraints, evolving requirements, etc. ) and develops software prototypes starting with the highest risk first. Allows development to begin before the final design is fully evolved. Uses feedback room these prototypes for mitigating risks. Spiral Model development is especially appropriate for unprecedented software- intensive systems. Key characteristics of the Spiral Model include: Risk based-prototyping. Feedback from prototype. Elaboration of draft documentation during the life cycle. Repetition until risk is at an acceptable level. Unprecedented System An Unprecedented System is one that has not been developed before. No models of previous system(s) or experience base exist on which to base the development of a new, similar system. Software Development This section presents key activities related to software development. The use of a software development paradigm does not negate the need to implement an overall systematic development process within that paradigm. Overview of Software Development Typically, software is designed using a “top-down” strategy.
After software coding and implementation, testing and integration follow a “bottom-up” strategy. When illustrated, the software development process looks like a V-shape. 6 SW Development Process integrated with SE Process During these steps, the Systems Engineering Process: Develops complete and consistent top-level specifications. Determines which requirements are best performed through software. Software Requirements Analysis Based on the overall Systems Design, the software developer then: Helps to finalize the selection of Software Items (SSL). Determines detailed requirements for each SSL.
Software Requirements Specification One key to effective software development is well defined software requirements. The result of the Software Requirements Analysis step is a detailed software requirements specification. Software requirements are typically detailed in a Software Requirements Specification (SIRS). This document becomes the “blueprint” for each Software Item to be developed. Unstable Requirements Software requirements specifications are important. Well designed and defined requirements can prevent “requirements creep” that can lead to unstable requirements.
Unstable and ill-defined requirements are major cost and schedule drivers. 7 Building Stable Requirements To ensure stability, requirements should be stated so that they are: Traceable: Requirements should be able to be tied to system and user requirements. Understandable: Users and developers should be able to understand the requirements. Achievable: The developer should be able to achieve the requirements within the estimated cost. Measurable: Developers and users should be able to measure the requirements during testing.
After the requirements are stabilized, the developer builds detailed designs for each Software Item. At this point it is critical to ensure that all requirements are addressed. Requirements are carefully traced from one development stage to the next. Coding and Implementation During this phase the developer writes or implements the code for each Software Unit. Each Software Unit is then usually tested in a stand-alone mode. Remember, each Software Item can be partitioned into several Software Units. Comprehensive Testing The focus of the development process now shifts to conducting comprehensive computerized testing.
Comprehensive testing demonstrates that the delivered software will satisfy the requirements. Although not mentioned before, some human- based software testing begins much earlier. Types of Software Testing Software testing can be divided into the broad categories of human-based and computerized testing. The type of testing performed depends on the software development stage. Human-Based Testing Human-based testing is a method of examining: Requirements 8 Design Code This type of testing is primarily a manual process. Testing begins as early as possible in the software development life cycle.
Human-based testing identifies software errors early when those errors are cheapest to correct. This type of testing is critical for ensuring software quality. Examples of Human-Based Testing Examples of human-based testing include: Desk Checking Walk-Thorough Formal Inspections Desk checking involves individuals reviewing the quality and correctness of their own work. Although commonly used, desk checking is not very effective at uncovering errors. Walk-Thorough During a walk-through, the author of the product being evaluated makes a presentation of the product (e. , software requirements, design, and code) to a group for review. The presentation is followed by a general discussion from the participants after which the presenter receives feedback on the specific item being reviewed. Formal Inspections Formal Inspections (also called Peer Reviews): Are led by a trained, impartial moderator. Involve inspection teams that use established criteria to review the software product (e. G. , software requirements, design, and code). Are done primarily by the software developer. However, the Government may participate at requirement-level reviews.
Are highly effective when done properly. Computer-Based Testing Computer-based testing: Refers to those testing activities that start after coding is complete. May use a variety of Computer-Aided Software Engineering (CASE) tools. Computer-Based Testing: Examples Examples of Computer-Based Testing include: Software Unit Integration and Testing Software Item Qualification Testing Hardware Item and Software Item Integration and Testing Subsystem Integration and Testing System Qualification Testing Software Unit Testing Software Unit Testing is a low-level test of an individual Software Unit.
Software units are typically routines, modules, or smaller portions of a larger program. Software Unit Integration and Testing Many Software Units make up a Software Item. Unit Integration and Testing involves progressive integration of the units making up an IS and testing their operation with one another, including internal interfaces. After all the units have been integrated and tested, the Software Item they comprise is tested as an entity. The basis of this test, which can be called “Qualification Testing,” is typically described in the Software Requirements Specification (SIRS).
This level of testing involves integration and testing of the various Hardware Items (HIS) and Software Items (SSL) that can make up a subsystem. This test involves the integration, testing, and qualification of the various subsystems that make up the complete system being developed. 10 This type of testing is a high-level technical test designed to qualify the entire system against its systems-level requirements, which are typically described in the System Specification. Managing Development Risk Development of some categories of software-intensive systems, especially embedded systems, may be high risk.
Some examples of these high risk categories include: Real-time critical software systems that generate some action in response to external vents under severe time and reliability constraints. Programs having a high cost of failure in terms of human life, national security, or mission success. For these inherently risky systems, the Program Manager may choose to use an Verification and Validation Independent Verification and Validation (IV) is the systematic evaluation of software products and activities by an agency that is not responsible for the system development.
Verification involves confirming that either a result is correct or that a procedure or sequence of operations has been performed. An example of Verification s determining that the software requirements analysis is complete and that software design activities can be started. Validation involves testing to ensure that software requirements are implemented correctly and completely. An example of Validation is acceptance testing, where the system is put through its paces and its performance is validated against the requirements.
Metrics In order to determine the status of an acquisition, the Program Manager needs to measure the development progress achieved. DOD policy mandates the use of a software measurement program. Proper use of software measurement (also called tries or indicators) can provide early insight into cost and schedule risks and product quality. A software metric is any measure that will allow a manager to measure and evaluate the products and/or the processes of a software development project. 1 Software Metrics Categories Software metrics can be classified into the following three categories: Management Quality Process The choice of the particular metrics to use on a given program should be driven by risk. Programs should measure those areas having the greatest risk impact. Management Metrics Management metrics are: Primarily concerned with indicators that help determine progress against plan. Measures selected from indicators that have an impact on the effect, cost, and schedule of the required effort.
Examples of management metrics include: Software Size Software Personnel Status Computer Resource Margins Software Requirements Volatility Development Progress Test Program Status Status of Software Problem Reports Quality Metrics Quality metrics help assess product quality attributes such as: Performance Ease of change User satisfaction Supportability Examples of quality metrics include: Error Density Reliability Usability 12 Complexity
