Integrating Risk Management in SDLC | Set 2

Prerequisite – Integrating Risk Management in SDLC | Set 1
In this article we will be discussing System design and Development phase of SDLC.
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

It involves a series of seven activities:

  1. Examine requirement Document – It is quite important for the developers to be a part of examining requirement document to ensure understandability of requirements listed in requirement document.

    Risk Factors –
    RD is not clear for developers: It is necessary for the developers to be involved in 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 solid understanding of the requirements of the system. Hence will land up creating a design for the system other than the intended one.

  2. Choosing the architectural design method activity – It is method to decompose system into components. Thus it is a way to define software system components. There exist many methods for architectural design like 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 most suitable method depending upon the project’s need. But it is important to choose 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 current machine. The choice of programming language depends upon the architectural model chosen.

  3. Choosing the programming language activity –Choosing programming language should be done side by side with 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. Thus may reduce the maintainability and portability of the system.

  4. Constructing physical model activity – The physical model consisting of symbols is a simplified description of hierarchical 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 from where to start and how to decompose such large and complex system 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 case of large size components that are further decomposable into sub components, may suffer difficulty in implementation and also poses difficulty for assigning functions to these components.
    • Unavailability of expertise for reusability: Lack of proper expertise to determine the components that can be reused pose a serious risk to project. As developing components from scratch takes lot of time in comparison to reusing the components. Thus delaying the projection completion.
    • Less reusable components: Incorrect estimation of reusable components during analysis phase leads to two serious risk to the project- first delay in project completion and second is budget over run. 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 project budget over run.
  5. Verifying design activity – Verifying design means to ensure 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 design is correct solution for the system it is necessary that design meets all requirements.
    • Many feasible solutions: When verifying design, developer may come across many alternate solutions for the same problem Thus, for choosing best possible design that meets all requirements is difficult. Choice depends upon the system and its nature.
    • Incorrect design: While verifying design it might be possible that the proposed design either matches few requirements or no requirement at all. It may be possible that it is a completely different design.
  6. Specifying design activity – This activity involves following main tasks:
    1. Identify the components and defines data flow between them
    2. For each identified component state its function, data input, data output and resource utilization.

    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 them 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 design document as small as possible.
    • Omitting data processing functions: Data processing functions like create, read are the operations that components perform on data. Accidental omission of these functions should be avoided.
  7. 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: Design document should be detailed enough explaining each component, sub components, sub sub components in full detail so that developers may work independently on different modules. If DD lacks this features then programmers cannot work independently.
    • Inconsistent DD: If same function is carried out by more than one component. Then in that case it will result in redundancy in design document and will eventually result in inconsistent document.
    • Unclear DD: If the design document do 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: 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 document will be difficult for the programmers to understand .

4. Development:
This stage involves the actual coding of the software as per the agreed upon requirements between developer and client.
Support from Risk Management Activities –
All designed controls are implemented during this stage.

This phase involves two steps: Coding and Unit Testing.

  1. 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 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 from where to start coding.
    • Lack of independent working environment: Due to unclear and incomplete design document 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 leads to wrongly implemented user interface 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, programming language may not work with the chosen method.
    • Repetitive code: In large projects there arises need to rewrite the same piece of code again and again. This consumes lot of time and also increase lines of code.
    • Modules developed by different programmers: In large projects, modules are divided between the programmers. But different programmer has a different style and way of thinking. This lead to a inconsistent, complex and ambiguous code.
  2. Unit Testing Activity – Each module is tested individually to check whether it meets the specified requirements or not and perform the functions it is intended to do.

    Risk Factors –

    • Lack of fully automated testing tools: Even till today unit testing is not fully automated. This makes 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 module or need to pass data to other module. As no module is completely independent in itself. Stub is the piece pf code that replaces the module that accepts data from module being tested. Driver is the piece of code that replaces the module that passes data to the module being tested. Coding drivers and stubs consumes 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 future.
    • Testing team not experienced: 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 to rerun 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.

Refer for other four phases – Integrating Risk Management in SDLC | Set 3

My Personal Notes arrow_drop_up

Check out this Author's contributed articles.

If you like GeeksforGeeks and would like to contribute, you can also write an article using or mail your article to See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.