RISK MANAGEMENT

MODULE 3

• IMPORTANTCE OF RISK MANAGEMENT

• INTEGRATION OF RISK MANAGEMENTIN SDLC
• RISK ASSESSMENT
• THREAT IDENTIFICATION
• VULNERABILITY IDENTIFICATION
• CONTROL ANALYSIS – IMPACT ANANLYSIS
• RISK DETERMINATION- RISK LEVEL MATRIX – CONTROL RECOMMEDATIONS
RISK MANAGEMENT
• Risk is the potential for a problem that can cause the loss of something valuable.
• Unnecessary risk can cost you time and money, especially in the IT industry where most software projects
have some element of risk Source
• Risk management is the process of identifying, assessing and controlling threats to an organization's capital
and earnings.
• These threats, or risks, could stem from a wide variety of sources, including financial uncertainty, legal
liabilities, strategic management errors, accidents and natural disasters.
• IT security threats and data-related risks, and the risk management strategies to alleviate them, have become a
top priority for digitized companies.
• As a result, a risk management plan increasingly includes companies' processes for identifying and
controlling threats to its digital assets, including proprietary corporate data, a customer's personally
identifiable information (PII) and intellectual property.
WHAT IS RISK IN SOFTWARE ENGINEERING?

• Very simply, a risk is a potential problem. It’s an activity or event that may
compromise the success of a software development project. Risk is the possibility of
suffering loss, and total risk exposure to a specific project will account for both the
probability and the size of the potential loss.
• Risk management includes the following tasks:
• Identify risks and their triggers
• Classify and prioritize all risks
• Craft a plan that links each risk to a mitigation
• Monitor for risk triggers during the project
• Implement the mitigating action if any risk materializes
• Communicate risk status throughout project
FIVE TYPES OF RISK IN SOFTWARE PROJECT
MANAGEMENT

• For most software development projects, we can define five main risk impact
areas:
1. New, unproven technologies
2. User and functional requirements
3. Application and system architecture
4. Performance
5. Organizational
RISK MANAGEMENT IN SDLC

• Software development life cycle (SDLC) is a conceptual model for defining

the tasks performed at each step of software development process.
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
1. PRELIMINARY ANALYSIS:
1. The organization’s objective
2. Nature and scope of problem under study
3. Propose alternative solutions and proposals after having the deep
understanding of problem and what competitors are doing
4. Describe costs and benefits.
• Support from Risk Management Activities –
• Establish a process and responsibilities for risk management
• Document Initial known risks
• Project Manager should prioritize the risks
 2. SYSTEM ANALYSIS AND REQUIREMENT
DEFINITION:
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.

Support from Risk Management Activities –

• Identify assets that need to be protected and assigning their criticality in terms of confidentiality, integrity and
availability

• Identify threats and resulting risk to those assets

• Determine existing security controls to reduce that risks

2. SYSTEM ANALYSIS AND REQUIREMENT
DEFINITION:

Five sub phases

1. Feasibility study
2. requirement elicitation
3. requirement analysis
4. requirement validation
5. requirement documentation
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
3. SYSTEM DESIGN:
3. SYSTEM DESIGN:
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.
3. SYSTEM DESIGN:
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. SYSTEM DESIGN:
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.
3. SYSTEM DESIGN:
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.
3. SYSTEM DESIGN:
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.
3. SYSTEM DESIGN:
6 Specifying design activity – This activity involves following main tasks: Identify the components
and defines data flow between them
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.
3. SYSTEM DESIGN:
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
 Unit Testing.
4. DEVELOPMENT: CODING ACTIVITY
• 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.
4. DEVELOPMENT: UNIT TESTING
ACTIVITY
• 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.
5. INTEGRATION AND SYSTEM TESTING:
• n this phase, first all modules are independently checked for errors, bugs. Then they
are related with their dependents and dependency is checked for errors and 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
integrated environment.
• This phase includes three activities:
Integration Activity,
 Integration Testing Activity,
System Testing Activity.
5. INTEGRATION AND SYSTEM TESTING:
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 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 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
component may result in error and bugs, that will be difficult to locate.
5. INTEGRATION AND SYSTEM TESTING:
• 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 interface: Wrong integration leads to a data loss between the components
where the number of parameters in the calling component do not match the number of
parameters in the called component.
• Desired functionality not achieved: Errors and bugs introduced during integration results 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 of the bugs are located, they need to be fixed.
Fixing error in one component may introduce error in other components. Thus it becomes
quite cumbersome to locate and repair errors.
5. INTEGRATION AND SYSTEM TESTING:
• 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: Lack of good testing team is a major setback for a good software as testers may
misuse the available resources and testing tools.
• Limited testing resources: Time, budget, tools if not used properly or unavailable may delay project delivery.
• Not possible to test in real environment: Sometimes it is not able to test system in the real environment due to
lack of budget, time constraints etc.
• Testing cannot cope up with requirements change: Users requirements often change during 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 up with change.
• System being tested is not testable enough: If the requirements are not verifiable, then In that case it becomes
quite difficult to test such system.
6. INSTALLATION, OPERATION AND ACCEPTANCE TESTING:

• This is the last and longest phase in SDLC. In 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,
• Acceptance Testing.
6. 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 environment: Sometimes the installed software system don’t work correctly
in the real environment, in some cases due to hardware advancement.
6. INSTALLATION, OPERATION AND ACCEPTANCE TESTING:

• Operation Activity: Here end users are given training on how to use
software system and its services.
• Risk Factors
• New requirements emerge: While using system, sometimes users feel need to
add new requirements.
• Difficulty in using 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 for a long otherwise this will be a serious threat to
acceptability of the system.
6. INSTALLATION, OPERATION AND ACCEPTANCE TESTING:

• Acceptance Testing Activity -Delivered system is put into acceptance testing to

check
• Risk Factors –
• User resistance to change: It is human behavior to resist any new change in the surroundings. But
for the success of a new 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 cost 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 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.
• whether it meets all user requirements or not.
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 time to time to initial
software to make it up-to date.
• Errors, 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 few steps in SDLC again. Thus exceeding the budget.
• Problems in upgrading: Constraints from end user or not so flexible architecture of the system forces it to be not easily
maintainable.
8. DISPOSAL:
• In this phase, plans are developed for discarding system information, hardware and software to make
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 –
Risk Management plan developed must also include threats to confidentiality of residual data, proper
procedures and controls to reduce 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 a experienced team, having a plan
on how to handle the residual data.
• Lack of proper procedures: Sometimes in hurry to launch a new system, organization sidelines the task of disposal.
Procedures used to handle residual data should be properly documented, so that they can be used in future.