1.

Risk definition

2.Risk types

3.Software risk management

4. Risk management activities.

5. Testing Risk

6. Risk Matrix

7. Risk control
• Risk is an expectation of loss, a potential problem that may occur in the
future.

• It is generally caused due to lack of information, control or time.

• Loss can be increase in production cost, development of poor quality

product, not being able to complete the project on time.

3
• A risk can be of two types

–(1) internal risks that are within the control of the project
manager.

–(2) external risks that are beyond the control of project manager.

4
• A software project can be concerned with a large variety of risks.

• In order to be adept to systematically identify the significant risks which might

affect a software project, it is essential to classify risks into different classes.

• Project risks

• Technical risks

• Business risks
• Project risk includes Time, budget, quality.

• Since the software is intangible, it is very tough to monitor and

control a software project.

• For example in the manufacturing of cars, the plan executive

can recognize the product taking shape.
• Technical risks concern potential method (functions), interfacing, testing, and
maintenance issue.

• It also consists of an ambiguous specification, incomplete requirements,

changing specification, technical uncertainty, and technical obsolescence.

• Most technical risks appear due to the development team's insufficient

knowledge about the project.
• This type of risks contain risks of building an excellent product that no
one needs it, losing budgetary or personnel commitments.

• Long development time leads to a potential risk of finding similar

software in the market.
• Reviewing requirements is an important part of risk management, in order to achieve a balance
between needed functionality and scope creep.

• Unclear requirements from stockholders.

• Low level of requirement presentations.

• Unverifiable Requirements : requirements that can not be verified or tested.

• Managing risk in code is one of the best and most efficient methods of risk

management.

• Low Readability of code defines a predicted risk.

• Low level of coherence of software components increases risk like hood.

• Increasing dependency between components increase risk probability.

• The business domain defines the shape and content of data.

• Modeling of data is an exercise in risk management that improves understanding of the

business domain.

• Code must complement the business rules applied to the data (access data, change values).

• Data size and its growth

• The most important step to define and predict test

• Testing is proof that code fulfills two main risk management criteria, firstly that it satisfies
requirements and secondly that it does so without errors.

• Insufficient test cases

• Preform validation test without defect test

• Perform Validation test without verification test

• Validation testing
– To demonstrate that the software meets its requirements (correct inputs)

• Defect testing
– To discover faults or defects in the software
– A successful test is a test that makes the system perform incorrectly and so exposes a defect in
the system.

Examples of defect test

1. Arithmetic Defects
2. Logical Defects
 Validation vs Verification
• Validation:
"Are we building the right product”.
• The software should do what the user really requires.

• Verification:
"Are we building the right product right”.
• The software should conform to its specification.

16
 Validation Verification

It always involves executing the code. .1 It does not involve executing the code. .1

2. It is computer based execution of program. 2. It is human based checking of documents and

files.

3. Validation uses methods like black box 3.Verification uses methods like inspections,
(functional) testing, gray box testing, and white reviews, walkthroughs.
box (structural) testing etc.

4. Validation is an external process done by the 4. Verification is done by project team to ensure
customer and identified stakeholders before that they are on the right track and working as per
accepting the deliverable. the agreed specification and process

17
 Equivalence partitioning

18
 Equivalence partitioning

Groups of valid input

System

outputs

invalid input

19
 Equivalence partitions

A program that accepts 4 to 10 inputs that are five digits

20
• High: means the effect of the risk would be very high and non-tolerable.

– The company might face loss.

• Medium: it is tolerable but not desirable.

–The company may suffer financially but there is a limited risk.

• Low: It is tolerable. There lies little or no external exposure or no financial loss.

 Impact

Negligible Minor Moderate Significant Severe

Very likely Low medium Medium Medium high High High

Likely Low Low medium Medium Medium high High

Likelihood Possible Low Low medium Medium Medium high Medium high

Unlikely Low Low medium Low medium Medium Medium high

Very unlikely Low Low Low medium Medium Medium

• Basic Methods for Risk Management

• Avoid:

• Mitigate:

• Transfer:

• Accept:
• The best thing you can do with a risk is avoid it.

• If you can prevent it from happening, it definitely won’t hurt your

project.

• The easiest way to avoid this risk is to walk away from the cliff, but

that may not be an option on all project.

• Organizational leaders typically decide on risk avoidance when the risk itself has a potential damage to

the organization and it is very likely to occur.

• To avoid a risk, enterprise executives must use policies and calculations to decide when to avoid the

risk.
Risk effect

project Technical business

Cost Investment
Quality Technical essues
Market share
time
• (Business Risk)
• An organization may decide not to make a risky investment. After analyzing the investment risks
and rewards, risk managers may deem the project.

• (Technical risk)
• A company may choose to implement a proven and pre-tested technology instead of adopting a
new, untested technology.

• (Project Risk)
• A company may hire higher quality of developers to avoid time and quality risks
• If you can’t avoid the risk, you can mitigate it.

• This means taking some sort of action that will cause it

to do as little damage to your project as possible.

• As you plan the deadlines for the project or/and sprint, take into consideration all possible factors

that may lead to late delivery.

• Always assign tasks taking into consideration the number of team members available as well as

their skills, strengths and weaknesses.

• Always inform about your progress and address all problems/blockers during the Daily Scrum.

That’s the best way to go about quality assurance in software development.

• One effective way to deal with a risk is to pay someone else to
accept it for you.

• The most common way to do this is to buy insurance.

• Another way to let the client be involved in the risk effect (time
and cost)
• When you can’t avoid, mitigate, or transfer a risk, then you have to
accept it.

• But even when you accept a risk, at least you’ve looked at the
alternatives and you know what will happen if it occurs.

• If you can’t avoid the risk, and there’s nothing you can do to reduce
its impact, then accepting it is your only choice.
The point in risk management whatever the decision (Mitigate, Transfer, Accept)
is monitoring “tracking” risk from the beginning to the end of a project.

It is essential to have a risk tracking mechanisms, project managers should know

where they are with projects at all times.

The level of volatility points to the likelihood of a feature changing, while

completeness refers to how far you are in developing it.
Initiation Planning Implementation Phase Deployment Phase
Closing
Phase Phase Phase
The execution phase involves carrying out the details of your project plan phase in order to
deliver your products or services to your clients.

First comes project planning. Then comes project execution. No matter how well you plan, your
project won’t be successful unless you can effectively implement your ideas.

Project execution typically involves three primary components:

Following processes,

Managing people,

Distributing information.
• During the planning phase of project management, you should have outlined systems and procedures
to help finish your project within your organization’s requirements (time, cost and quality).

• Project manager should follow internal activities and external communications

• For example, you should follow created processes to interact with third-party vendors who supply
essential raw materials.

• You can look to your plan for guidance and move ahead with confidence. However, if circumstances or
market forces change, or user changes requirements your plan should be modified.
• Making sure your personnel are following the project plan is essential, but
keeping people on task is not your only job.

• It’s important that you also motivate, encourage, and cheer the team on.

• Pausing to celebrate each incremental victory is one way to show the team
how much you value them, and it will inspire them to keep up the hard work.
• The project execution phase is often the most extensive phase of the project life cycle.

• Involve your clients and stakeholders throughout the execution phase of the project. When you
keep stakeholders in the loop, you can prevent costly misunderstandings and delays.

• Instead of be separated from the client for weeks or months to complete an individual task
involve them in all activities.

• Two different development techniques in software (waterfall, Agile)

 Software process activities

Software Specification Analyses,

Requirements Requirements

Software Design

Development
Software implementation

Software testing Validation

Software Evolution
39
Upgrading changes
• A structured set of activities required to develop a software system.
• Many different software processes but all involve:

–Requirements: defining what the system should do;

–Design: defining the organization of the system
–Implementation: coding the system;
–Testing: checking that it does what the customer wants;
–Evolution: changing the system in response to changing
customer needs.

40
 The software process models
• A software process model represents the order in which the activities of software development
will be undertaken.

• It describes the sequence in which the phases of the software lifecycle will be performed.

41
• Waterfall model

• Agile model
–RAD (rapid application development)

–Incremental model

42
43
 Waterfall with Prototyping Model
A variation of the waterfall that adds a new phase, prototyping.
It can also be used to better understand and elicit user requirements

44
 Agile Model

An iterative approach.
During each iteration a single feature or small set of features are chosen and
implemented completely

45
46
47
• Update PMP and Communication Management Plan to assure project performance
(completing in time).

• The PMP should also be changed as a respond to user requirements changes or

business requirements changes
• Such as devices, servers, network components, and other equipment
needed to start the implementation phase.

• In modern software development methodologies implementation is

not delivered as a complete unit, instead it is delivered in cycles.

• To start each cycle its prerequisites should be reviewed and accepted.

• The Development Team begins implementation with the following tasks:

– Selection of standards, methods, and tools for deploying the system

– Carrying out of Implementation Phase activities according to the detailed project (work

breakdown structure) WBS started during the Planning Phase.

– Implementation activities need to be performed in cycles. (using Scrum board)

• Review of the change management process to ensure all Test Phase modifications have been
documented
• The Development Team installs the system in the production environment.

• While installing the system, the Development Team should keep the configuration information
updated by following the Configuration Management Plan defined in the Design Phase.

• The Development Team will repeat this activity for each iteration associated with a release to
production.

• (implementation and delivery phases are interconnected in software development)