Integrating Risk Management in SDLC | Set 3

Prerequisite – Integrating Risk Management in SDLC | Set 1, and Set 2.

We have already discussed the first four steps of the Software Development Life Cycle. In this article, we will be discussing the remaining four steps: Integration and System Testing, Installation, Operation and Acceptance Testing, Maintenance, and Disposal. We will discuss Risk Management in these four steps in detail.

5. Integration and System Testing

In this phase, first, all modules are independently checked for errors, bugs. Then they are related to their dependents and dependency is checked for errors finally all modules are integrated into one complete software and checked as a whole for bugs.

Support from Risk Management Activities

In this phase, designed controls are tested to see whether they work accurately in an integrated environment. This phase includes three activities: Integration Activity, Integration Testing Activity, and System Testing Activity. We will be discussing these activities in a bit more detail along with the risk factors in each activity.

• Integration Activity: In this phase, individual units are combined into one working system.
  • Risk Factors:
    • Difficulty in combining components: Integration should be done incrementally else it will be very difficult to locate errors and bugs. The wrong sequence of integration will eventually hamper the functionality for which the system was designed.
    • Integrate wrong versions of components: Developing a system involves writing multiple versions of the same component. If the incorrect version of the component is selected for integration it may not produce the desired functionality.
    • Omissions: Integration of components should be done carefully. Single missed components may result in errors and bugs, that will be difficult to locate.
• Integration Testing Activity: After integrating the components next step is to test whether the components interface correctly and to evaluate their integration. This process is known as integration testing.
  • Risk Factors:
    • Bugs during integration: If wrong versions of components are integrated or components are accidentally omitted, then it will result in bugs and errors in the resultant system.
    • Data loss through the interface: Wrong integration leads to a data loss between the components where the number of parameters in the calling component does not match the number of parameters in the called component.
    • Desired functionality not achieved: Errors and bugs introduced during integration result in a system that fails to generate the desired functionality.
    • Difficulty in locating and repairing errors: If integration is not done incrementally, it results in errors and bugs that are hard to locate. Even if the bugs are located, they need to be fixed. Fixing errors in one component may introduce errors in other components. Thus it becomes quite cumbersome to locate and repair errors.
• System Testing Activity: In this step integrated system is tested to ensure that it meets all the system requirements gathered from the users.
  • Risk Factors:
    • Unqualified testing team: The lack of a good testing team is a major setback for good software as testers may misuse the available resources and testing tools.
    • Limited testing resources: Time, budget, and tools if not used properly or unavailable may delay project delivery.
    • Not possible to test in a real environment: Sometimes it is not able to test the system in a real environment due to lack of budget, time constraints, etc.
    • Testing cannot cope with requirements change: User requirements often change during the entire software development life cycle, so test cases should be designed to handle such changes. If not designed properly they will not be able to cope with change.
    • The system being tested is not testable enough: If the requirements are not verifiable, then In that case it becomes quite difficult to test such a system.

6. Installation, Operation, and Acceptance Testing

This is the last and longest phase in SDLC. This system is delivered, installed, deployed, and tested for user acceptance.

Support from Risk Management Activities

The system owner will want to ensure that the prescribed controls, including any physical or procedural controls, are in place prior to the system going live. Decisions regarding risks identified must be made prior to system operation. This phase involves three activities: Installation, Operation, and Acceptance Testing.

• Installation Activity: The software system is delivered and installed at the customer site.
  • Risk Factors:
    • Problems in installation: If deployers are not experienced enough or if the system is complex and distributed, then in that case it becomes difficult to install the software system.
    • Change in the environment: Sometimes the installed software system doesn’t work correctly in the real environment, in some cases due to hardware advancement.
• Operation Activity: Here end users are given training on how to use software systems and their services.
  • Risk Factors:
    • New requirements emerge: While using the system, sometimes users feel the need to add new requirements.
    • Difficulty in using the system: Being a human it is always difficult in the beginning to accept a change or we can say to accept a new system. But this should not go on for long otherwise this will be a serious threat to the acceptability of the system.
• Acceptance Testing Activity: The delivered system is put into acceptance testing to check whether it meets all user requirements or not.
  • Risk Factors:
    • User resistance to change: It is human behavior to resist any new change in the surroundings. But for the success of a newly delivered system, it is very important that the end users accept the system and start using it.
    • Too many software faults: Software faults should be discovered earlier before the system operation phase, as discovery in the later phases leads to high costs in handling these faults.
    • Insufficient data handling: New system should be developed keeping in mind the load of user data it will have to handle in a real environment.
    • Missing requirements: While using the system it might be possible that the end users discover some of the requirements and capabilities are missing.

7. Maintenance

In this stage, the system is assessed to ensure it does not become obsolete. This phase also involves continuous evaluation of the system in terms of performance and changes are made from time to time to initial software to make it up-to-date. Errors, and faults discovered during acceptance testing are fixed in this phase. This step involves making improvements to the system, fixing errors, enhancing services, and upgrading software.

Support from Risk Management Activities

Any change to a system has the potential to reduce the effectiveness of existing controls or to otherwise have some impact on the confidentiality, availability, or integrity of the system. The solution is to ensure that a risk assessment step is included in evaluating system changes.

• Risk Factors:
  • Budget overrun: Finding errors and fixing them involves repeating a few steps in SDLC again. Thus exceeding the budget.
  • Problems in upgrading: Constraints from the end-user or the not-so-flexible architecture of the system force it to be not easily maintainable.

8. Disposal

In this phase, plans are developed for discarding system information, hardware, and software to make the transition to a new system. The purpose is to prevent any possibility of unauthorized disclosure of sensitive data due to improper disposal of information. All of this should be done in accordance with the organization’s security requirements.

Support from Risk Management Activities

The Risk Management plan developed must also include threats to the confidentiality of residual data, proper procedures, and controls to reduce the risk of data theft due to improper disposal. However, by identifying the risk early in the project, the controls could be documented in advance ensuring proper disposition.

• Risk Factors:
  • Lack of knowledge for proper disposal: Proper disposal of information requires an experienced team, having a plan on how to handle the residual data.
  • Lack of proper procedures: Sometimes in a hurry to launch a new system, the organization sidelines the task of disposal. Procedures used to handle residual data should be properly documented, so that they can be used in the future.

How To Integrate Risk Management in SDLC?

Integrating risk management into the Software Development Life Cycle (SDLC) is crucial for ensuring the development of secure and reliable software. Here are the ways to integrate Risk Management in SDLC.

• Define and document the risk management process: The first step is to define the risk management process and document it in a formal policy or procedure. This process should include the identification, analysis, evaluation, treatment, and monitoring of risks throughout the SDLC.
• Identify and assess risks: The next step is to identify and assess risks at every stage of the Software Development Life Cycle (SDLC). This can be done through various techniques such as brainstorming sessions, risk assessments, threat modeling, and vulnerability assessments.
• Prioritize risks: Once risks have been identified and assessed, they need to be prioritized based on their potential impact on the system and their likelihood of occurrence. This helps in determining which risks need to be addressed first.
• Develop risk mitigation strategies: Once risks have been prioritized, risk mitigation strategies need to be developed. These strategies can include designing security controls, implementing secure coding practices, and conducting security testing.
• Incorporate risk management into the SDLC: Risk management should be incorporated into every phase of the SDLC. This can be done by including risk assessments in the requirements gathering phase, conducting security testing during the development phase, and conducting vulnerability assessments during the testing phase.
• Monitor and update the risk management plan: Risk management is an ongoing process, and risks need to be monitored and updated regularly. This can be done through regular risk assessments, vulnerability assessments, and threat modeling.
• By integrating risk management into the SDLC: Organizations can develop more secure and reliable software. This can help reduce the risk of data breaches, system failures, and other security incidents that can impact an organization’s reputation, financial stability, and customer trust.

Frequently Asked Questions

1. List some typical risk response strategies used in SDLC?

Answer:

In SDLC, there are four main risk response strategies:

• Avoidance
• Mitigation
• Transfer
• Acceptance

2. What differentiates Integrated Risk Management from Traditional Risk Management?

Answer:

Traditional Risk Management focuses on individual risks, while Integrated Risk Management also focuses on interactions between different risks.

3. List some common challenges that are faced while implementing Integrated Risk Management in SDLC?

Answer:

Some of the common challenges include:

• resistance to change
• difficulty in obtaining full support from all stakeholders
• complex risk interdependencies,
• data integration issues, etc.