Integrating Risk Management in SDLC | Set 2

Prerequisite: Integrating Risk Management in SDLC | Set 1

We have seen the Risk Management Techniques in SDLC which we have discussed Preliminary Analysis, System Analysis, and Requirement Definition part. In this article, we will be discussing the System Design and Development phase of the Software Development Life Cycle (SDLC). We will discuss how risk is managed in these two phases. Let’s proceed with the System Design part.

3. System Design

This is the second phase of SDLC wherein system architecture must be established and all requirements that are documented needs to be addressed. In this phase, the system (operations and features) is described in detail using screen layouts, pseudocode, business rules, process diagrams, etc.

Support from Risk Management Activities

• Accurate Classification of assets criticality
• Planned controls accurately identified

System Design undergoes a list of seven activities that are listed as follows.

• Examine the Requirement Document: It is quite important for the developers to be a part of examining the requirement document to ensure the understandability of the requirements listed in the requirement document.
  • Risk Factors – RD is not clear for developers: It is necessary for the developers to be involved in the requirements definition and analysis phase otherwise they won’t be having a good understanding of the system to be developed. They will be unable to start designing on a solid understanding of the requirements of the system. Hence will land up creating a design for the system other than the intended one.
• Choosing the Architectural Design Method Activity: It is the method to decompose the system into components. Thus it is a way to define software system components. There exist many methods for architectural design including structured object-oriented, Jackson system development, and formal methods. But there is no standard architectural design method.
  • Risk Factors – Improper Architectural Design Method: As discussed above there is no standard architectural design method, one can choose the most suitable method depending on the project’s need. But it is important to choose the method with utmost care. If chosen incorrectly it may result in problems in system implementation and integration. Even if implementation and integration are successful it may be possible that the architectural design may not work successfully on the current machine. The choice of programming language depends upon the architectural model chosen.
• Choosing the Programming Language Activity: Choosing a programming language should be done side by side with the architectural method. As programming language should be compatible with the architectural method chosen.
  • Risk Factors – Improper choice of programming language: Incorrect choice of programming language may not support chosen architectural method. This may reduce the maintainability and portability of the system.
• Constructing Physical Model Activity: The physical model consisting of symbols is a simplified description of a hierarchically organized system.
  • Risk Factors:
    • Complex System: If the system to be developed is very large and complex then it will create problems for developers. as developers will get confused and will not be able to make out where to start and how to decompose such large and complex systems into components.
    • Complicated Design: For a large complex system it may be possible due to confusion and lack of enough skills, developers may create a complicated design, which will be difficult to implement.
    • Large-Size Components: In the case of large-size components that are further decomposable into sub-components, may suffer difficulty in implementation and also poses difficulty in assigning functions to these components.
    • Unavailability of Expertise for Reusability: Lack of proper expertise to determine the components that can be reused poses a serious risk to the project. Developing components from scratch takes a lot of time in comparison to reusing the components. Thus delaying the projection completion.
    • Less Reusable Components: Incorrect estimation of reusable components during the analysis phase leads to two serious risks to the project- first delay in project completion and second budget overrun. Developers will be surprised to see that the percentage of the code that was considered ready, needs to be rewritten from scratch and it will eventually make the project budget overrun.
• Verifying Design Activity: Verifying design means ensuring that the design is the correct solution for the system under construction and it meets all user requirements.
  • Risk Factors:
    • Difficulties in Verifying Design to Requirements: Sometimes it is quite difficult for the developer to check whether the proposed design meets all user requirements or not. In order to make sure that the design is the correct solution for the system it is necessary that the design meets all requirements.
    • Many Feasible Solutions: When verifying the design, the developer may come across many alternate solutions for the same problem Thus, choosing the best possible design that meets all requirements is difficult. The choice depends upon the system and its nature.
    • Incorrect Design: While verifying the design it might be possible that the proposed design either matches few requirements or no requirements at all. It may be possible that it is a completely different design.
• Specifying Design Activity: This activity involves the following main tasks. It involves the components and defines the data flow between them and for each identified component state its function, data input, data output, and utilization of resources.
  • Risk Factors:
    • Difficulty in allocating functions to components: Developers may face difficulty in allocating functions to components in two cases- first when the system is not decomposed correctly and secondly if the requirement documentation is not done properly in that case developers will find it difficult to identify functions for the components as functional requirements constitute the functions of the components.
      • Extensive specification: Extensive specification of module processing should be avoided to keep the design document as small as possible.
      • Omitting Data Processing Functions: Data processing functions like create, and read are the operations that components perform on data. Accidental omission of these functions should be avoided.
• Documenting Design Activity: In this phase design document(DD) is prepared. This will help to control and coordinate the project during implementation and other phases.
  • Risk Factors:
    • Incomplete DD: The design document should be detailed enough to explain each component, sub-components, and sub-sub-components in full detail so that developers may work independently on different modules. If DD lacks these features then programmers cannot work independently.
    • Inconsistent DD: If the same function is carried out by more than one component. Then in that case it will result in redundancy in the design document and will eventually result in inconsistent documents.
    • Unclear DD: If the design document does not clearly define components and is written in uncommon natural language, then in that case it might be difficult for the developers to understand the proposed design.
    • Large DD: The design document should be detailed enough to list all components will full details about functions, input, output, resources required, etc. It should not contain unnecessary information. Large design documents will be difficult for programmers to understand.

4. Development

This stage involves the actual coding of the software as per the agreed-upon requirements between the developer and the client.

Support from Risk Management Activities

All designed controls are implemented during this stage. This phase involves two steps: Coding and Unit Testing.

• Coding Activity: This step involves writing the source code for the system to be developed. User interfaces are developed in this step. Each developed module is then tested in the unit testing step.
  • Risk Factors:
    • Unclear design document: If the design document is large and unclear it will be difficult for the programmer to understand the document and to find out where to start coding.
    • Lack of independent working environment: Due to unclear and incomplete design documents it is difficult for the team of developers to assign independent modules to work on.
    • Wrong user interface and user functions developed: Incomplete, inconsistent, and unclear design documents lead to wrongly implemented user interfaces and functions. Poor user interface reduces the acceptability of the system in the real environment among the customers.
    • Programming language incompatible with architectural design: choice of architectural method solely drives the choice of programming language. They must be chosen in sequence otherwise if incompatible, the programming language may not work with the chosen method.
    • Repetitive code: In large projects, there arises a need to rewrite the same piece of code again and again. This consumes a lot of time and also increases lines of code.
    • Modules developed by different programmers: In large projects, modules are divided between the programmers. But the different programmer has a different style and way of thinking. This led to an inconsistent, complex, and ambiguous code.
• Unit Testing Activity: Each module is tested individually to check whether it meets the specified requirements or not and performs the functions it is intended to do.
  • Risk Factors:
    • Lack of fully automated testing tools: Even today unit testing is not fully automated. This makes the testing process boring and monotonous. Testers don’t bother to generate all possible test cases.
    • Code not understandable by reviewers: During unit testing, developers need to review and make changes to the code. If the code is not understandable it will be very difficult to update the code.
    • Coding drivers and stubs: During unit testing, modules need data from other modules or need to pass data to another module. As no module is completely independent in itself. A stub is a piece of code that replaces the module that accepts data from the module being tested. The driver is the piece of code that replaces the module that passes data to the module being tested. Coding drivers and stubs consume a lot of time and effort. Since these will not be delivered with the final system so these are considered extras.
    • Poor documentation of test cases: Test cases need to be documented properly so that these can be used in the future.
    • The testing team is not experienced: The testing team is not experienced enough to handle the automated tools and to write short concise code for drivers and stubs.
    • Poor regression testing: Regression testing means rerunning all successful test cases when a change is made. This saves time and effort but it can be time-consuming if all test cases are selected for rerun.

Frequently Asked Questions On Risk Management

1. How do stakeholders help in Risk Management during Software Development Life Cycle?

Answer:

Stakeholders has crucial role in Risk Management during SDLC. They help in risk identification by providing insights into potential risks using different perspectives.

2. How does Risk Monitoring and Control happen in the Software Development life Cycle (SDLC)?

Answer:

Risk Monitoring and Control happens during SDLC by continuously tracking and reviewing the project during its development phase.

For other phases of Risk Management, refer to Integrating Risk Management in SDLC | Set 3.