The document discusses software risk management and types of risks in software development projects. It identifies five main types of risks: schedule risks, budget risks, operational risks, technical risks, and programmatic risks. It then describes various tools and techniques for risk identification, assessment, and management, including documentation reviews, brainstorming, risk tables, and risk monitoring. Effective communication is also highlighted as important for coordinating the project team and managing risks.

1. Software Risk Management
Risk is uncertain events associated with future events which have a probability of occurrence
but it may or may not occur and if occurs it brings loss to the project.
Risk identification and management are very important task during software project
development because success and failure of any software project depends on it.
Types of Risk in Software Development :
1. Schedule Risk
1. Schedule related risks refers to time related risks or project delivery related planning risks.
2. The wrong schedule affects the project development and delivery.
3. These risks are mainly indicates to running behind time as a result project development
doesn’t progress timely and it directly impacts to delivery of project.
4. Finally if schedule risks are not managed properly it gives rise to project failure and at last
it affect to organization/company economy very badly.

2. Some reasons for Schedule risks :
* Time is not estimated perfectly
* Improper resource allocation
* Tracking of resources like system, skill, staff etc
* Frequent project scope expansion
* Failure in function identification and its’ completion
2. Budget Risk :
1. Proper finance distribution and management are required for the success of project
otherwise it may lead to project failure.
2. Always the financial aspect for the project should be managed as per decided but if
financial aspect of project mismanaged then there budget concerns will arise by giving
rise to budget risks.

3. Some reasons for Budget risks :
* Wrong/Improper budget estimation
* Unexpected Project Scope expansion
* Mismanagement in budget handling
* Cost overruns
* Improper tracking of Budget
3. Operational Risks
Operational risk refers to the procedural risks means these are the risks which happen in
day-to-day operational activities during project development due to improper process
implementation or some external operational risks.
Some reasons for Operational risks :
* Insufficient resources
* Conflict between tasks and employees
* Improper management of tasks
* No proper planning about project
* Less number of skilled people
* Lack of communication and cooperation
* Lack of clarity in roles and responsibilities
* Insufficient training

4. 4. Technical Risks
Technical risks refers to the functional risk or performance risk which means this technical
risk mainly associated with functionality of product or performance part of the software
product.
Some reasons for Technical risks
* Frequent changes in requirement
* Less use of future technologies
* Less number of skilled employee
* High complexity in implementation
* Improper integration of modules

5. 5. Programmatic Risks
Programmatic risks refers to the external risk or other unavoidable risks. These are the
external risks which are unavoidable in nature. These risks come from outside and it is out
of control of programs.
Some reasons for Programmatic risks :
* Rapid development of market
* Running out of fund / Limited fund for project development
* Changes in Government rules/policy
* Loss of contracts due to any reason

6. Risk Identification: Tools And Techniques
Documentation Reviews
The standard practice to identify risks is reviewing project related documents such as lessons learned, articles,
organizational process assets, etc
Information Gathering Techniques
The given techniques are similar to the techniques used to collect requirements. Let's look at a few of them:
1. Brainstorming
Brainstorming is done with a group of people who focus on the identification of risk for the project.
2. Delphi Technique
A team of experts has consulted anonymously. A list of required information is sent to experts, responses are compiled,
and results are sent back to them for further review until agreement is reached.
3. Interviewing
An interview is conducted with project participants, stakeholders, experts, etc to identify risks.
4. Root Cause Analysis
Root causes are determined for the identified risks. These root causes are further used to identify additional risks.

7. 5. Checklist Analysis
The checklist of risk categories is used to come up with additional risks for the project.
6. Assumption Analysis
Identification of different assumptions of the project and determining their validity further
helps in identifying risks for the project.

9. Risk projection :
It is also called risk estimation, is attempts to rate each risk in 2 ways the probability or
likelihood in which the risk is real and the consequences of the problems related with the
risk should it occur.
The project planner along with other technical and managers staff, performs 4 risk projection
activities that are as follows :
1. Establish a scale which reflects the perceived likelihood if a risk.
2. Described the outcome of the risk.
3. Estimate and impact of the risk on the project and the product
4. The overall accuracy of the risk projection by that there will be no misinterpret.

10. Developing Risk Table :
1. Project team begins by listing all risks in the first column of the table.
(Accomplished with the help of the risk item checklists).
2. Each risk is categorized in the second column.
(e.g. PS implies a project size risk, BU implies a business risk).
3. The probability of occurrence of each risk is entered in the next column of the table.
The probability value for each risk can be estimated by team members individually.
4. Individual team members are polled in round-robin fashion until their assessment of
risk probability begins to converge.

11. Note :
1. A risk factor which has a high impact but a very low
probability of occurrence should not absorb a significant
amount of management time.
2. Weather, low impact risk with high probability should be
carried forwarded into the management steps and high impact
risk with moderate to high probability that follow.
Fig: Impact on Project assessments

12. Assessing Risk Impact
Nature of the risk - the problems that are likely if it occurs.
e.g. a poorly defined external interface to customer hardware (a technical risk) will
prevent early design and testing and will likely lead to system integration problems late in
a project.
Scope of a risk - combines the severity with its overall distribution (how much of the
project will be affected or how many customers are harmed?).
Timing of a risk - when and how long the impact will be felt.
Overall risk exposure, RE, determined using:
RE = P x C
P is the probability of occurrence for a risk.
C is the the cost to the project should the risk occur.

13. Risk Refinement :
Process of reiterate the risks as a set of more detailed risks that will be easier to mitigate
(Justify), monitor, and manage.
Risk Mitigation : It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows :
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring : It is an activity used for project tracking.
It has the following primary objectives as follows:
1. To check if predicted risks occur or not.
2. To ensure proper application of risk avoidance steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.

14. Risk Management and planning
1. It assumes that the mitigation activity failed and the risk is a reality.
2.This task is done by Project manager when risk becomes reality and causes severe
problems.
3. If the project manager effectively uses project mitigation to remove risks successfully
then it is easier to manage the risks.
4. This shows that the response that will be taken for each risk by the manager.
5. The main objective of the risk management plan is the risk register.
6. This risk register describes and focuses on the predicted threats to a software project.

15. Communication Techniques
Important Note : Communication techniques are methods used by a communicator,
speaker, or listener to improve the effectiveness and reach of every conversation or
interaction. For better understanding, one can assume that these techniques are equal to
skills that a person must possess to have a better communication process.
Communication is an essential process in coordinating a software development project
and sharing knowledge between the team members.
It can also bring challenges, that when improperly dealt with can delay a team project or
even cost money to the company.

16. FIVE TYPES OF COMMUNICATION
1. VERBAL COMMUNICATION :
Verbal communication occurs when we engage in speaking with others. It can be face-to-
face, over the telephone, via Skype or Zoom, etc. Some verbal engagements are informal,
such as chatting with a friend over coffee or in the office kitchen, while others are more
formal, such as a scheduled meeting.
2.NON-VERBAL COMMUNICATION :
Non-verbal communication includes facial expressions, posture, eye contact, hand
movements, and touch. For example, if you’re engaged in a conversation with your boss
about your cost-saving idea, it is important to pay attention to both the their words and their
non-verbal communication. Your boss might be in agreement with your idea verbally, but their
nonverbal cues: avoiding eye contact, sighing, scrunched up face, etc.

17. 3. WRITTEN COMMUNICATION
Whether it is an email, a memo, a report, a Facebook post, a Tweet, a contract, etc. all
forms of written communication have the same goal to distribute information in a clear and
concise manner – though that objective is often not achieved. In fact, poor writing skills often
lead to confusion and embarrassment.
4.LISTENING
Active listening, however, is perhaps one of the most important types of communication
because, if we cannot listen to the person sitting across from us, we cannot effectively
engage with them.
5.VISUAL COMMUNICATION
We are a visual society. Think about it, televisions are running 24/7, Facebook is visual with
memes, videos, images, etc., Instagram is an image-only platform, and advertisers use
imagery to sell products and ideas. Think about from a personal perspective, the images we
post on social media are meant to convey meaning – to communicate a message.

18. Requirement analysis is significant and essential activity after elicitation. We analyze,
refine, and scrutinize the gathered requirements to make consistent and unambiguous
requirements. This activity reviews all requirements and may provide a graphical view of
the entire system. After the completion of the analysis, it is expected that the understand
ability of the project may improve significantly. Here, we may also use the interaction
with the customer to clarify points of confusion and to understand which requirements
are more important than others

19. Draw the context diagram:
The context diagram is a simple model that defines the boundaries and interfaces of the
proposed systems with the external world. It identifies the entities outside the proposed
system that interact with the system.
Development of a Prototype (optional):
One effective way to find out what the customer wants is to construct a prototype, something
that looks and preferably acts as part of the system they say they want.
We can use their feedback to modify the prototype until the customer is satisfied
continuously. Hence, the prototype helps the client to visualize the proposed system and
increase the understanding of the requirements. When developers and users are not sure
about some of the elements, a prototype may help both the parties to take a final decision.

20. Model the requirements:
This process usually consists of various graphical representations of the functions, data
entities, external entities, and the relationships between them. The graphical view may help
to find incorrect, inconsistent, missing, and superfluous requirements. Such models include
the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition
diagrams, etc.
Finalize the requirements:
After modeling the requirements, we will have a better understanding of the system
behavior. The inconsistencies and ambiguities have been identified and corrected. The flow
of data among various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed requirements, and the
next step is to document these requirements in a prescribed format. SRS

21. Analysis Principles
Over the past two decades, a large number of analysis modeling methods have been
developed in the literature.
By Analyzing Problems and their causes, investigator have developed a variety of notations
and corresponding sets of heuristic overcomes.
Note: Each analysis method has a unique point of view, however all analysis methods are
related by a set of operational principles as follows.
1. The information domain of a problem must be represented and understood.
2. The functions that the software is to perform must be defined.
3. The behavior of the software must be represented.
4. The Models that depict information and behavior must be partitioned in a manner that
uncovers detail in a layered (or Hierarchical) fashion.
5. The analysis process should move from essential information towards implementation
detail.
Note : By applying these principles, an analyst approaches a problem systematically.

22. A Set of guiding principles for Requirements analysis
1. Understand the problem before you begin to create the analysis model.
2. Develop Prototype that enable a user to understand how human / machine interaction
will occur.
3. Record the origin of and reason for every requirement.
4. Multiple use of requirements- building data, functional and behavioral models provide
the software engineering with different 3 views.
5. Rank Requirements: Tight deadline may prevent the implementation of every software
requirement. If an incremental process model is applied, those requirements to be
delivered in the first increment must be identified.
6. Work to Eliminate Ambiguity: As most requirements are described in natural
language, the opportunity for everyone. The use of formal technical review is one way to
uncover and eliminate ambiguity.

23. Feasibility study
A feasibility study is quite important phase in which highly management is possible, we can
decides on the feasibility report that whether or not the proposed system is worthwhile.
Feasibility study checks
* If the system contributes organizational objectives.
* If the system can be engineered using current technology and within budget.
* If the system can be integrated with other systems that are used.
Types of Feasibility study
1. Operational Feasibility
2. Technical Feasibility
3. Economic Feasibility
Note : The main aim of the feasibility study is not thinking how to solve problem,
back to determine whether the problem is work solving?

24. Note : Feasibility study leads to a decision like as follows
1. Proceed further
2. Not proceed further
3. Think again
Outcome of feasibility study
Few questions are going to rise after detail study of feasibility analysis.
1. What if the system was not implemented?
2. What are current project problems?
3. How will be the proposed system help?
4. What will be integration problems?
5. Is new technology needed?
6. Is new skill (staff, team members) required?
7. What facilities must be supported by the proposed system?

25. Note : Prototyping gives the opportunity to evaluate the product, ensure it's doing
what's intended, and determine if improvements needs to be made.
The software prototyping process includes the following points.
1. Identify initial requirements
A) What software will be able to do
B) who will be the exact users
C) user expectations from product
2. Develop initial prototype
In this case, developer will consider the requirements as proposed by the client and begin to
put together a model of what the finished product might look like.
3. Review :
Once the prototype is developed, the client has a chance to see what the product might look
like. In more advanced prototypes, the end consumer may have an opportunity to try out the
product and offer suggestions improvement. This is also called Beta Testing.
4. Revise
The final step in the process is to make revisions to the prototype based on the feedback of the
client and/or beta testers.

26. Why Use an SRS Document?
1. A software requirements specification is the foundation for your entire project. It lays the
framework that every team involved in development will follow.
2. It’s used to provide critical information to multiple teams like development, quality
assurance, operations, and maintenance. This keeps everyone on the same page.
3. Using the SRS helps to ensure requirements are fulfilled. And it can also help you make
decisions about your product’s life cycle.
4. Writing an SRS can also minimize overall development time and costs.
5. Embedded development teams especially benefit from using an SRS.

27. Software Requirements Specification vs System Requirements Specification
A software requirements specification (SRS) includes in-depth descriptions of the
software that will be developed.
A system requirements specification (SyRS) collects information on the requirements
for a system.
Note: “Software” and “System” are sometimes used interchangeably as SRS. But, a
software requirement specification provides greater detail than a system requirements
specification.

28. Requirement Specification
Software requirements specification (SRS) helps you to build groundwork for product
development.
What is a Software Requirements Specification (SRS) Document?
A software requirements specification (SRS) is a document that describes what the software
will do and how it will be expected to perform. It also describes the functionality the product
needs to fulfill all stakeholders (business, users) needs.
A typical SRS includes:
1. A purpose
2. An overall description
3. Specific requirements
Note : The best SRS documents define how the software will interact when embedded
in hardware or when connected to other software. Good SRS documents also account
for real-life requirements.