Integrating Risk Management in SDLC | Set 1

Software development life cycle (SDLC) is a conceptual model for defining the tasks performed at each step of software development process. Though there are various models for SDLC, but in general SDLC comprises of following steps- 

1. Preliminary Analysis
2. System analysis and Requirement definition
3. System Design
4. Development
5. Integration and System Testing
6. Installation, Operation and Acceptance Testing
7. Maintenance
8. Disposal

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

1. Preliminary analysis:
In this step you need to find out: 
 The organization’s objective

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

Support from Risk Management Activities –

1. Establish a process and responsibilities for risk management
2. Document Initial known risks
3. Project Manager should prioritize the risks

2. System analysis and requirement definition:
This step is very important for a clear understanding of customer expectation and requirement. 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 entire process. Following are the series of steps that are conducted during this stage: 

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

3. 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 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? Feasibility study help us to get an idea whether it is worthy to construct the system or not. It helps to identify main risk factors. 

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

• Project manager often make a mistake in estimating cost, time, resources and scope of the project. Unrealistic budget, time, inadequate resources and unclear scope often leads to project failure.
• Unrealistic Budget: As discussed above inaccurate estimation of budget may lead to project running out of funds early in the SDLC. 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 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 case the technology, 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 worst case it may lead to project failure.
• Unclear project scope: Clear understanding of what project is supposed to do, which functionalities are important, which functionalities are mandatory, which functionalities can be considered as extra is very important for project managers. Insufficient knowledge of the system may lead to project failure.

4. Requirement Elicitation – It starts with analysis of application domain. This phase requires the participation from different stake holders to ensure efficient, correct and complete gathering of system services, its performance and constraints. This data set is then reviewed and articulated to make it ready for the next phase. 

Risk Factors –

• 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 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 do 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 analyst and developers then these requirements are said to be unclear.
• Ignoring non functional requirements: Sometimes developers and analyst ignore the fact that non functional requirements hold equal importance as functional requirements. In this confusion they focus on delivering what system should do rather than how system should be like scalability, maintainability, testability etc.
• Conflicting user requirements: Multiple users in a system may have different requirements. If not listed and analysed 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 the development may lead to threats in the system. Gold plating is nothing but adding extra functionality to the system that were 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 later stage of software development life cycle.
  

5. Requirement Analysis Activity – In this step requirements that are gathered by interviewing users or brainstorming or by another means will be: first analysed and then classified and organised such as functional and non functional 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 step has following task to do: 

• Non verifiable requirements: If a finite cost effective process like testing, inspection etc is not available to check whether software meets the requirement or not then that requirement is said to be non verifiable.
• 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 with any other requirement then the requirement is said to be inconsistent.
• Non traceable requirement: It is very important for every requirement to have an origin source. During documentation it is necessary to write origin source of each requirement so that it can traced back in future when required.
• Unrealistic requirement: If a requirement meets all above criteria like it is complete, accurate, consistent, traceable, verifiable etc then that requirement is realistic enough to be documented and implemented.
  

6. Requirement Validation Activity – This involves validating the requirements that are gathered and analyzed till now to check whether they actually defines what user want from the system. 

Risk Factors –

• Misunderstood domain specific terminology: Developers and Application specialists often use domain specific terminology or we can say technical terms which are not understandable for 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
  

7. Requirement Documentation Activity – This steps 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 –

• Inconsistent requirements data and RD: Sometimes it might happen, due to glitches in gathering and documentation process, actual requirements may differ from the documented ones.
• Non modifiable 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.