Lesson 7.3: System Development Life Cycle Flashcards
Requirements analysis
Requirements analysis requires significant input from stakeholders, such as potential users, as well as those with other ties, such as legal or financial interests. In cases where the beneficiary is an entity, like a company or government agency, requirements analysis may start with a feasibility study. The feasibility study determines whether development is possible under the given constraints and whether the development aligns with the organization’s mission. In the case of producing commercial off-the-shelf (COTS) systems for the mass market, requirements analysis is likely to begin with a market study by the system developer.
The requirements analysis process consists of three steps:
- Compiling and analyzing the needs of the system use
- Negotiating with project stakeholders on trade-offs between wants, needs, costs, and feasibility
- Developing a set of requirements identifying the necessary features and services of the completed system
The system requirement specification (SRS)
The system requirement specification (SRS) is a written agreement between all parties that records the system requirements and guides system development. The SRS also helps resolve disputes that arise during development. Because of how important the SRS is in the development process, organizations such as IEEE and large systems clients, such as the U.S. Department of Defense, have adopted standards for requirement specifications.
The system requirement specification (SRS) is a written agreement between all parties that records the system requirements and guides system development. The SRS also helps resolve disputes that arise during development. Because of how important the SRS is in the development process, organizations such as IEEE and large systems clients, such as the U.S. Department of Defense, have adopted standards for requirement specifications.
The SRS should clearly define objectives to determine a system’s success. Too often, however, the SRS fails to delineate the system objectives.
Design
While the requirements analysis describes the system, the design creates a plan for constructing the system. Requirements analysis identifies the problem to be solved, while design plans a solution. Requirements analysis is often equated with deciding what the system should do, whereas design is equated with deciding how the system would do it. If, for example, the user’s ability to access necessary systems using a limited number of steps is defined as a user requirement, the design phase may include the layout of drop-down boxes and the coloring scheme. When the design phase is complete, the organization should have a detailed description of the system structure.
implementation phase
The system is built during the implementation phase, including such things as developing programs and databases and creating data files. As projects move from the design phase into the implementation phase, the demand for specialized technical skills increases. It is during the implementation stage of software development projects, for example, that the distinction between a system analyst and a programmer becomes clear. A system analyst is involved throughout the entire development process. A programmer is primarily tasked with writing programs that implement the design produced by a system analyst.
Many factors influence the successful implementation of a system—training, team skills, team communication, effective project management, quality assurance, and upper-management commitment are just a few.
system maintenance
During system maintenance, the system is monitored, evaluated, and modified as needed. System maintenance is a continuous phase that covers a wide variety of activities, including troubleshooting application errors and incompatibilities, updating documentation, and providing end-user support. There are four primary categories of software maintenance: corrective, adaptive, perfective, and preventive.
Corrective maintenance
The goal of corrective maintenance is to remove errors to ensure functionality of the system. In Mei’s medical office, if a patient record application causes the operating system to reboot, Mei might begin corrective maintenance by reviewing the application and/or operating system logs.
Adaptive maintenance
Adaptive maintenance is performed when organizational changes affect system requirements, such as changes in the organizational procedures, forms, or system controls and security needs. For example, Mei’s medical office might change how nurses obtain and verify their patients’ identity, such as adding barcode reader functionality to read barcodes from patients’ wristbands.
Perfective maintenance
Perfective maintenance is performed when new components are introduced, or existing components are improved, to enhance overall system performance. Examples of perfective maintenance include a new operating system for performance improvement or a new technology to increase efficiency.
Preventive maintenance
Preventive maintenance refers to changes made to increase the life span of systems and could include restructuring, optimizing code, or updating documentation that impacts the scalability, stability, and maintainability of the system. One maintenance activity that could be categorized as preventative is testing air conditioning units in the server rooms.
System quality control
As systems have become more complex, malfunctions, cost overruns, and missed deadlines are becoming more common, resulting in a need for more effective quality control processes. System quality control goes beyond debugging to include improving procedures and developing training for employees. The ISO 9000 series of standards address industrial activities such as design, production, installation, and servicing. The ISO/IEC 15504 is a set of standards developed jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It is common for third-party system developers to meet specific standards.
Quality control must also maintain effective documentation practices. It is important that each step of the development process is accurately documented for future reference. Without maintaining up-to-date documentation, it is likely the records will be inaccurate or no longer applicable. Documenting the various audits throughout the system development process helps reduce errors.
testing
glass-box testing (white-box testing)
Techniques based on the Pareto principle and basis path testing rely on knowledge of a system’s internal components. This is known as glass-box testing, commonly referred to as white-box testing, which includes having developers test internal structures of software
Black-box testing
Black-box testing does not rely on the tester’s knowledge of the system’s structure but is focused on the user experience (UX).
Methodologies that fall within the black-box category are alpha, beta, and user acceptance testing.
In alpha testing, the first stage, developers and/or an internal UX team test a preliminary version of the software, providing feedback about performance and functionality. The second stage is beta testing, sometimes referred to as pilot testing. In this stage, the next version of the system is given to a segment of end users for similar testing from their perspective before the final version is released. The final stage is referred to as user acceptance testing. During this stage, the users test the system in an operational setting to make sure the system continues to align with business objectives and meet the goals of the stakeholders.
Documentation
A system is not effective unless people can learn to use it and maintain it properly. Documentation is an important part of a system. The production of documentation is a component of the system development process. There are three types of system documentation: user documentation, system documentation, and technical documentation. User documentation explains the system to users and may include information such as how to access certain features, frequently asked questions (FAQs), and contact information for customer support.
System documentation describes the system’s internal configuration so the system can be maintained later in its life cycle. A major part of software development system documentation is software code. The code needs to be versioned and presented in a readable format. Versioned code allows developers to track modifications and reverse any changes that have been problematic. Readability is important so that any contributing developer can read the code. Development companies have created conventions for writing programs that include several common features:
indentation conventions for script readability
naming conventions for variables and constraints
documentation conventions for sufficient program documentation
Technical documentation describes how to install and maintain the system, including information about installing updates and providing feedback to the development team.
