Integrating Risk Management in SDLC | Set 1

The Software Development Life Cycle (SDLC) is a conceptual model for defining the tasks performed at each step of the software development process. This model gives you a brief about the life cycle of Software in the development phase. In this particular article, we are going to discuss risk management in each and every step of the SDLC Model.

Steps in SDLC Model

Though there are various models for SDLC, in general, SDLC (Software Development Life Cycle) comprises of following steps:

• Preliminary Analysis
• System Analysis and Requirement Definition
• System Design
• Development
• Integration and System Testing
• Installation, Operation, and Acceptance Testing
• Maintenance
• Disposal

We will be discussing these steps in brief and how risk assessment and management are incorporated into these steps to ensure less risk in the software being developed.

1. Preliminary Analysis

In this step, you need to find out the organization's objective

• Nature and scope of problem under study
• Propose alternative solutions and proposals after having a deep understanding of the problem and what competitors are doing
• Describe costs and benefits.

Support from Risk Management Activities: Below mentioned is the support from the activities of Risk Management.

• Establish a process and responsibilities for risk management
• Document Initial known risks
• The Project Manager should prioritize the risks

2. System Analysis and Requirement Definition

This step is very important for a clear understanding of customer expectations and requirements. Thus it is very important to conduct this phase with utmost care and given due time as any possible error will cause the failure of the entire process. Following are the series of steps that are conducted during this stage.

• End-user requirements are obtained through documentation, client interviews, observation, and questionnaires
• Pros and cons of the current system are identified so as to avoid the cons and carry forward the pros in the new system.
• Any Specific user proposals are used to prepare the specifications and solutions for the shortcomings discovered in step two are found.
• Identify assets that need to be protected and assign their criticality in terms of confidentiality, integrity, and availability.
• Identify threats and resulting risks to those assets.
• Determine existing security controls to reduce that risks.

Feasibility Study: This is the first and most important phase. Often this phase is conducted as a standalone phase in big projects not as a sub-phase under the requirement definition phase. This phase allows the team to get an estimate of major risk factors cost and time for a given project. You might be wondering why this is so important. A feasibility study helps us to get an idea of whether it is worth constructing the system or not. It helps to identify the main risk factors. 

Risk Factors: Following is the list of risk factors for the feasibility study phase.

• Project managers often make a mistake in estimating the cost, time, resources, and scope of the project. Unrealistic budget, time, inadequate resources, and unclear scope often lead to project failure.
• Unrealistic Budget: As discussed above inaccurate estimation of the budget may lead to the project running out of funds early in the SDLC. An accurate estimation budget is directly related to correct knowledge of time, effort, and resources.
• Unrealistic Schedule: Incorrect time estimation lead to a burden on developers by project managers to deliver the project on time. Thus compromising the overall quality of the project and thus making the system less secure and more vulnerable.
• Insufficient resources: In some cases, the technology, and tools available are not up-to-date to meet project requirements, or resources(people, tools, technology) available are not enough to complete the project. In any case, it is the project will get delayed, or in the worst case it may lead to project failure.
• Unclear project scope: Clear understanding of what the project is supposed to do, which functionalities are important, which functionalities are mandatory, and which functionalities can be considered as extra is very important for project managers. Insufficient knowledge of the system may lead to project failure.

Requirement Elicitation: It starts with an analysis of the application domain. This phase requires the participation of different stakeholders to ensure efficient, correct, and complete gathering of system services, their performance, and constraints. This data set is then reviewed and articulated to make it ready for the next phase. 

Risk Factors: Following is the list of risk factors for the Requirement Elicitation phase.

• Incomplete requirements: In 60% of the cases users are unable to state all requirements in the beginning. Therefore requirements have the most dynamic nature in the complete SDLC (Software Development Life Cycle) Process. If any of the user needs, constraints, or other functional/non-functional requirements are not covered then the requirement set is said to be incomplete.
• Inaccurate requirements: If the requirement set does not reflect real user needs then in that case requirements are said to be inaccurate.
• Unclear requirements: Often in the process of SDLC there exists a communication gap between users and developers. This ultimately affects the requirement set. If the requirements stated by users are not understandable by analysts and developers then these requirements are said to be unclear.
• Ignoring nonfunctional requirements: Sometimes developers and analysts ignore the fact that nonfunctional requirements hold equal importance as functional requirements. In this confusion, they focus on delivering what the system should do rather than how the system should be like scalability, maintainability, testability, etc.
• Conflicting user requirements: Multiple users in a system may have different requirements. If not listed and analyzed carefully, this may lead to inconsistency in the requirements.
• Gold plating: It is very important to list out all requirements in the beginning. Adding requirements later during development may lead to threats in the system. Gold plating is nothing but adding extra functionality to the system that was not considered earlier. Thus inviting threats and making the system vulnerable.
• Unclear description of real operating environment: Insufficient knowledge of real operating environment leads to certain missed vulnerabilities thus threats remain undetected until a later stage of the software development life cycle.

Requirement Analysis Activity: In this step requirements that are gathered by interviewing users or brainstorming or by another means will be: first analyzed and then classified and organized such as functional and nonfunctional requirements groups and then these are prioritized to get a better knowledge of which requirements are of high priority and need to be definitely present in the system. After all these steps requirements are negotiated. 

Risk Factors: Risk management in this Requirement Analysis Activity step has the following task to do.

• Nonverifiable requirements: If a finite cost-effective process like testing, inspection, etc is not available to check whether the software meets the requirement or not then that requirement is said to be nonverifiable.
• Infeasible requirement: if sufficient resources are not available to successfully implement the requirement then it is said to be an infeasible requirement.
• Inconsistent requirement: If a requirement contradicts any other requirement then the requirement is said to be inconsistent.
• Nontraceable requirement: It is very important for every requirement to have an origin source. During documentation, it is necessary to write the origin source of each requirement so that it can be traced back in the future when required.
• Unrealistic requirement: If a requirement meets all the above criteria like it is complete, accurate, consistent, traceable, verifiable, etc then that requirement is realistic enough to be documented and implemented.

Requirement Validation Activity: This involves validating the requirements that are gathered and analyzed till now to check whether they actually define what users want from the system. 

Risk Factors: Following is the list of risk factors for the Requirement Validation Activity phase.

• Misunderstood domain-specific terminology: Developers and Application specialists often use domain-specific terminology or we can say technical terms which are not understandable for the majority of end users. Thus creating a misunderstanding between end users and developers.
• Using natural language to express requirements: Natural language is not always the best way to express requirements as different users may have different signs and conventions. Thus it is advisable to use formal language for expressing and documenting.

Requirement Documentation Activity: This step involves creating a Requirement Document (RD) by writing down all the agreed-upon requirements using formal language. RD serves as a means of communication between different stakeholders. 

Risk Factors: Following is the list of risk factors for the Requirement Documentation Activity phase.

• Inconsistent requirements data and RD: Sometimes it might happen, due to glitches in the gathering and documentation process, actual requirements may differ from the documented ones.
• Nonmodifiable RD: If during RD preparation, structuring of RD with maintainability is not considered then it will become difficult to edit the document in the course of change without rewriting it.

Questions For Practice

1. Requirement Development, Organizational Process Focus, Organizational Training, Risk Management, and Integrated Supplier Management are process areas required to achieve maturity level. [UGC NET CSE 2014]

(A) Performed

(B) Managed

(C) Defined

(D) Optimized

Solution: Correct Answer is (C).

For a detailed Solution, refer to UGC-NET | UGC NET CS 2014 Dec – II | Question 42.