Which of the following phases of the information system development life cycle is considered as the ongoing process?

II. SDLC

The SDLC can be defined as the formalized process of developing information systems through the following successive phases:

Feasibility study

System investigation

System analysis

System design

System implementation

Review and maintenance

This generic SDLC model, designed by the National Computing Center of the United Kingdom in the late 1960s, was described in 1971 by A. Daniels and D.A. Yeates (Fig. 1).

Each phase of the model consists of subphases and each stage must be completed to a great extent before moving to the next one. The segmentation of the SDLC into logical phases aims at facilitating information system development by focusing on one manageable subset of the whole project at a time. The term “life cycle” can have various interpretations according to the context in which it is used. Basically, it denotes the fundamental phases or stages of the evolution a product or activity passes through from its creation to its maturity and retirement. There are numerous variations of information system development methodologies based on the life cycle concept, such as the waterfall or the V-shaped model. The original waterfall model is generally considered to have been defined by Winston Royce in 1970 (Proceedings of the IEEE WESCON) and proposes the following seven phases: system requirements, software requirement, analysis, program design, coding, testing, and operations.

This model, treated usually as purely linear, explicitly accommodates iteration by proposing that feedback loops should ideally take place between the preceding and succeeding phases, but rarely with the more remote phases in the sequence in order to scale down the change process into manageable limits and minimize development costs. It also makes provision for simulation, that is, prototyping, proposing that the version of a computer system delivered to the customer for operational deployment should be the second version, at least as far as critical design or operation areas are concerned. It should be noted, however, that remarkably similar conceptions about the stagewise approach to information systems development had been published back in the mid-1950s. At the symposium of the United States Office of Naval Research (ONR) in June 1956, Herbert Benington described a nine-phase model for the production of large program systems, which proceeds from a general operational plan through system operation and evaluation. The phases of this model are the following:

Operational plan (broad design requirements prepared jointly by systems engineers and users)

Machine specifications and operational specifications

Program specifications

Coding specifications

Coding

Parameter testing (testing of component subprograms according to coding specifications)

Assembly testing (program assembled and tested using simulated and real data)

Shakedown (completed program testing in operational environment)

System evaluation

It can be seen that testing is a main consideration in Benington's model of information system development. Another variation of the SDLC model, where project verification and evaluation of each phase is also required, is the V-shaped model. In contrast to the original waterfall model, where the testing phase occurs at the end of the development cycle, the V-shaped model explicitly requires the definition of criteria for testing the progress of the development process at each phase. Extensive testing may result in an increase of development costs and extension of the completion time of a project, but it is useful for risky and unfamiliar projects contributing significantly to system quality and performance. In contrast, the waterfall model may be more appropriate for low-risk projects where requirements are well understood and potential bugs can be identified more easily.

It should be noted that the life cycle models require extensive documentation to be produced within each phase. Each major stage of the life cycle models produces an output or a deliverable, which provides the basis for the next phase. Thus, the model assumes that one phase should be completed, at least to a great extent before proceeding to the next one, which is often restrictive, as it does not accommodate any changes occurring during the development process. On the other hand this provides a rigorous approach to system development. A series of milestones should also be established at the outset. Milestones are defined as end points of system development activities and help monitor the progress of the project. GANTT bar charts and PERT flow-diagram charts can be used to depict the phases of the project and the associated milestones, the concurrent phases, the critical path, and the time elapsed and required to complete project's phases, subphases, and tasks.

I.A.2. Systems Development Life Cycle

The systems development life cycle (SDLC) was the primary conceptual basis for planning in this era. The SDLC for information systems evolved from the basic life cycle notion for complex systems. This theory postulated that the development of all complex systems naturally evolved through a sequential series of phases that were appropriately managed in different ways, and each of which demanded different mixes of resources to proceed effectively and efficiently. The classic SDLC for a single system is shown in the central portion of Fig. 1. There, it is depicted as consisting of three phases—system definition, physical design, and implementation. Other more elaborate versions of the SDLC specify many subphases of these three phases.

IV. Systems Development Life Cycle

The systems development life cycle can be performed many ways. In fact, each organization may develop its own list of tasks, techniques, and (automated) tools, which can be referred to as “their” methodology. Each of these methodologies has common themes. The first includes ways to search for facts about the system. The basic fact finding techniques include questionnaires, interviews, observation, and document collection.

The second theme includes ways to determine the data necessary to produce the logical requirements specified by the organization. The data will be represented by a predetermined model. The most common data model used is the entity relationship diagram.

The third theme includes ways to determine the processes (actions) necessary to produce the results as defined by the requirements of the system. The processes will be represented by a predetermined model. One common process model used is the data flow diagram.

Once the themes have been identified then there are predetermined tasks and techniques to finish the project as defined by the approved methodology of the organization.

SDLC

The systems development life cycle (SDLC, also called the software development life cycle or simply the system life cycle) is a system development model. SDLC is used across the IT industry, but SDLC focuses on security when used in context of the exam. Think of “our” SDLC as the secure systems development life cycle; the security is implied.

Fast Facts

The following overview is summarized from NIST SP 800-14:

Prepare a security plan: Ensure that security is considered during all phases of the IT system life cycle and that security activities are accomplished during each of the phases.

Initiation: The need for a system is expressed and the purpose of the system is documented.

Conduct a sensitivity assessment: Look at the security sensitivity of the system and the information to be processed.

Development/acquisition: The system is designed, purchased, programmed, or developed.

Determine security requirements: Determine technical features, like access controls; assurances, like background checks for system developers; or operational practices, like awareness and training.

Incorporate security requirements in specifications: Ensure that the previously gathered information is incorporated in the project plan.

Obtain the system and related security activities: May include developing the system’s security features, monitoring the development process itself for security problems, responding to changes, and monitoring threats.

Implementation: The system is tested and installed.

Install/turn-on controls: A system often comes with security features disabled. These need to be enabled and configured.

Security testing: Used to certify a system; may include testing security management, physical facilities, personnel, procedures, the use of commercial or in-house services such as networking services, and contingency planning.

Accreditation: The formal authorization by the accrediting (management) official for system operation and an explicit acceptance of risk.

Operation/maintenance: The system is modified by the addition of hardware and software and by other events.

Security operations and administration: Examples include backups, training, managing cryptographic keys, user administration, and patching.

Operational assurance: Examines whether a system is operated according to its current security requirements.

Audits and monitoring: A system audit is a one-time or periodic event to evaluate security. Monitoring refers to an ongoing activity that examines either the system or the users.

Disposal: The secure decommission of a system.

Information: Information may be moved to another system, or it could also be archived, discarded, or destroyed.

Media sanitization: There are three general methods of purging media: overwriting, degaussing (for magnetic media only), and destruction.8

Aligning to the SDLC

Many organizations subdivide their SDLC methodologies into a larger number of phases than the five referenced in NIST guidance, potentially offering closer alignment of SDLC phases and corresponding RMF tasks. Table 6.1 lists some SDLC phase names commonly used in government organizations, arranged by the five general phase names used in NIST documentation and where applicable indicating different terms that may be used to represent the same phase.

Table 6.1. Common SDLC Phases and Outputs

Warning

NIST documentation addressing aspects of the system development life cycle typically references Special Publication 800-64, Security Considerations in the System Development Life Cycle, the most recent version of which was released in 2008. This guidance describes a representative five-phase SDLC and highlights security activities and considerations in each phase. Special Publication 800-37 aligns each RMF task to one or more SDLC phases, but in some cases positions tasks within different phases than in Special Publication 800-64. For instance, security control selection in step 2 of the RMF is part of the initiation phase Special Publication 800-37 but is presented as part of development in Special Publication 800-64 [10]. System owners should validate that the alignment of RMF tasks to SDLC phases matches the practices and process standards in their own agencies.

The objectives of RMF planning include estimating the time and level of effort required to complete all necessary tasks, adjusting the RMF-specific timeline and milestones for task completion to reflect SDLC dependencies or constraints associated with the project to deploy the system, and beginning the process of assigning the personnel and resources necessary to support the effort. While it is often impossible to accurately predict the time and resources needed for the RMF before completing the system security categorization in step 1, systems owners use planning to evaluate anticipated RMF needs against available resources, including funding, and to determine the best approach for accomplishing the RMF tasks. For systems being developed or implemented by non-government personnel such as contractors, system owners may include appropriate RMF tasks within the scope of work to be performed under the contract. Some key RMF tasks cannot be delegated in this way, notably including security control assessment, which should be performed by an independent assessor, and system authorization, which is an inherently governmental function and therefore can only be performed by government personnel. Organizations may choose to provide or contract for RMF-specific services separate from other aspects of system development and operations, either by establishing internal capabilities to deliver relevant security services and project support or by contracting for such services [11].

14.4.2 Waterfall

Most solution providers use the waterfall life cycle approach for software solution development. The waterfall approach (refer Figure 14.3) helps to understand the extent of the residual risks and allows one to work conscientiously toward reducing those risks.

At the end of each phase, a baseline is established which becomes the platform for the next phase, and until the previous phase is officially approved no next phase should be started, hence delays on any approvals lead to project delays and have cost implications. The execution component is responsible for the final deliverable of the project and is built around pure code development, system configuration, or a combination of both.

The waterfall approach is best suited for a simplistic, yet systematic approach to meet the exact requirements of the client. The immediate benefit to the client is the constant realization of the benefits in terms of the expectations of the final deliverable. This approach also ensures that the provider can constantly measure itself to interpret the requirements of – and deliver the best solution to – the client. The tools that this methodology prescribes should have built-in quality and project control measures, ensuring that a certain quality level is maintained. These properties enhance the management of time and specifications of the project.

A system development life cycle includes the following steps:

User requirement specification (URS)

Business process analysis (AS-IS) and design (TO-BE)

System architecture analysis (AS-IS) and design (TO-BE)

Benefits case

Function analysis (FA)

Technical detail design (TDD)

Development

Software design verification testing (SDVT)

Factory acceptance testing (FAT)

Installation and commissioning

Site acceptance testing (SAT)

Training

Support and maintenance.

User requirements specification (URS) is a general term used in industry and it comprises the masterplan and the operational detail design (ODD), while a functional specification is a high level combination of the ODD (business design) and technical detail design (TDD).

Each of the testing steps in the development/configuration phase is tested against a step in the design phase. This ensures that the objective of the system is met and that it is fit for purpose.

II. Overview of ESDLC

The ESDLC presented by Guimaraes and Yoon consists of nine phases, as shown in Fig. 1. The design life cycle consists of nine phases:

Problem identification: Identifying the problems and opportunities where the organization can obtain benefits from an expert system. This phase also involves establishing the general goals of the system.

Feasibility study: Assessing the feasibility of expert systems development in terms of its technical, economic, and operational feasibility.

Project planning: Planning for the expert systems project, including identifying the development team members, the working environment, the project schedule, and the budget.

Knowledge acquisition: Extracting domain knowledge from domain experts and determining the requirements for the system.

Knowledge representation: Representing key concepts from the domain, and interrelationships between these concepts, using formal representation methods.

Knowledge implementation: Coding the formalized knowledge into a working prototype.

Verification and validation: Verifying and validating a working prototype against the system's requirement, and revising it as necessary according to domain experts' feedback.

Installation/transition/training: Installing the final prototype in an operating environment, training the users, and developing documentation/user manuals.

Operation/evaluation/maintenance: Operating the system in the working environment, evaluating its performance and benefits, and maintaining the system.

The prototype expert systems development commences with project approval. Phases 4 through 7 represent an iterative process whereby a prototypical ES is evolved, and the final prototype developed through these iterative phases is installed in an operating environment. The next section presents more detailed descriptions of each phase and discusses existing literature and findings in light of these phases.

Data conversion life cycle

The basic systems development life cycle for a data conversion project is the same as for any application development endeavor, with activity centered around planning, analysis, requirements, development, testing, and implementation. A pure “waterfall” methodology is not implied or necessary. Like other data-related projects, the activities in the analysis phase should include profiling the data in the source and target data structures. The requirements phase should include verifying that the assumptions made are true by trying the load of very small amounts of data. Unlike application development projects, there is no support phase in the data conversion life cycle, unless additional data sources are to be loaded to the target application later, such as when multiple systems are being consolidated over time, data is being moved from one system to another in phases, or an organizational merger or acquisition takes place.

Tier 3 Risk Management Activities

The NIST SDLC integrates risk management activities through the application of the NIST RMF. The specific risk management activities at tier 3 are guided by the output of the risk management activities conducted at tier 1 and tier 2, (i.e., where the risk management strategy and the risk response strategy are supported by an information security architecture).37 In addition, the output of the risk management activities from the other tiers also ensures the information system operates consistently with the information system resiliency38 requirements.

Tip

Cloud computing is one example where trust and trustworthiness39 between cloud service providers (CSPs) and a federal agency is critical for the effective application of the NIST RMF. The Federal Risk and Authorization Management Program (FedRAMP) “introduces an innovative policy approach to developing trusted relationships between Executive departments and agencies and cloud service providers (CSPs)” [11]. However, for a trusted relationship to exist, transparency into the risk management and information security activities must include operational visibility based on the adequate level of confidence needed by the federal agency using the cloud services. “Establishing a level of confidence about a cloud service environment depends on the ability of the cloud provider to provision the security controls necessary to protect the organization’s data and applications, and also the evidence provided about the effectiveness of those controls” [12]. This might require documenting the risk information needed to address the trust requirements in contracts, service level agreements (SLAs), or other forms of legal agreements.

12.9.6 Security Standards for Systems Development

These standards should be used within the context of the Forensic Laboratory’s Secure System Development Life Cycle. They are designed as a checklist to ensure that proper attention is given to all aspects relevant to the secure implementation of developed software.

A secure system development life cycle methodology should be implemented to consider security issues in all phases so that:

All security concerns are addressed.

Test criteria are met prior to implementation of operational software.

Change management procedures for operational software are implemented.

Discrepancies for all information and software are reported, monitored, and resolved.

Note

The Forensic Laboratory does not perform development or modification on purchased software packages.