2. Risk strategies
• According to Webster’s Dictionary,
– Risk is the possibility of suffering loss.
• Any decisions that we take generally carries some
amount of risk.
• Any decision we take may result in a gain or loss for us.
In both cases, we must bear the consequences.
• In simple terms, this results in taking a risk.
• Risk-taking entails making a choice.
• Risk involves change in some form like a change in
place, a change in profession and change in opinion.
• Software engineering also entails many risks.
• What are the risks pertaining to the software project?
• How will any change, inherent or circumstantial, affect
the performance of the project?
• At every step, we must make a choice be it the selection
of people for the project or the selection of equipment to
be used.
3. Risk strategies
• There are two commonly used strategies to deal with risks in
software engineering
– Reactive strategies and
– Proactive strategies.
• There is a phrase “cross the bridge when you come across it”, which
when applied to a software project would mean taking care of
problems as and when we come across them without planning for
them in advance.
• This is termed as “Reactive strategy”, which means we react to the
problem.
• With reactive strategies, the team does nothing about risks until
something goes wrong.
• When a problem arises, the team goes into action and takes
initiative to solve the problem.
• Reactive strategy can be depicted as Figure.
Problem
occurs
Takes
Action
4. Reactive strategy
• Assume that there was a software project in progress
with three software engineers involved in all kinds of
responsibilities.
• The firm never accounted for the fact that any one of
them may leave. It simply took for granted the
continuance of the staff. But, all of a sudden, two of the
engineers leave the project.
• In such a situation, the entire burden falls upon the lone
software engineer.
• Due to shortage of time, it may so happen that the firm is
unable to hire new staff immediately and the project may
have to be abandoned or delayed.
• In the given example, reactive strategy would mean
hiring and training new staff after the earlier staff has
quit.
• Had the problem been foreseen, the engineers who plan
to quit could be made to train the new staff and then
leave.
5. Proactive strategy
• Proactive means taking the initiative.
• Proactive strategy with respect to a software
project would mean acting in advance, predicting
that a problem may arise and taking
precautionary measures for it.
• Identification of risks that may occur, prioritizing
them and planning solution strategies to deal
with these risks are part of proactive strategy.
• Figure illustrates this strategy.
Predicts
Problem Takes
Action
Problem
occurs
6. Characteristics Of Risks
• Any kind of risk possesses two
characteristics –
• Uncertainty:
– Uncertainty is probability estimation about
whether the foreseen risk will actually occur.
• Loss:
– If the risk becomes a reality, unwanted
consequences or losses will occur.
– Loss is the direct consequence of the risk
actually taking place.
7. Software risks
• Risks can be categorized into several categories
• Project risks:
– These affect or threaten any project plan that has been laid.
– Project risks can cause time delays or increase in cost.
– These risks include personnel, customer, resource, budgetary,
scheduling and requirement risks.
• Business risks:
– Business risks affect the viability of the software to be built.
– Business risks can come in various forms:
• building a product that the marketing team does not know how to
sell,
• building a product that does not fit into the business strategy of the
company,
• building a superlative product that no one wants to use.
• Sometimes, business risks are unpredictable too.
8. • Technical risks:
– These risks can have an effect on the creation and completion of
software.
– In case such a risk becomes real, implementation could become
difficult and even impossible.
– Technical risks can occur within any of these stages:
implementation, interfacing, verification, design, and
maintenance.
– The causes for technical risks could be software obsolescence,
technical uncertainty, and ambiguity in specifications.
• Predictable risks:
– Certain risks like unrealistic delivery date, lack of documented
requirements or software scope can be predicted by evaluating
the project plan and the environment under which the project will
be developed.
– Predictable risks can be identified from past project experience.
• Unpredictable risks:
– These are the risks that may occur but cannot be predicted in
advance.
Software risks
9. Risk identification
• Risk Identification is a systematic attempt to specify
factors that may affect the project plan.
• It is important to identify the known and predictable risks
so that they can be avoided or controlled.
• For each of the risks listed in the previous section, there
are two types of risks -
– generic risks and
– product-specific risks.
• Generic risks can affect any software project whereas
product specific risks can be identified by those who are
familiar with the technology, the people and the project
at hand.
• Detailed examination of the project plan is necessary to
find out and identify the product specific risks.
10. Risk identification
• A risk item checklist is generally created to
help in identification of risks as well as focus on
different categories of risks.
• The checklist will consist of the following
parameters:
– Product size
– Customer characteristics
– Process definition
– Business Impact
– Development environment
– Technology
– Risk associated with staff size and experience
11. Product size
• This is the risk associated with the overall size of
the software to be built or modified.
• Project risk is directly proportional to product
size.
• Questions that maybe asked to check product
size can be drawn as follows:
– Estimated Lines of Code or function points
– Confidence in a size estimate
– Deviation of past projects from the estimate
– Size of the database created or used by the software
– Number of users
– Number of projected requirement changes
– Amount of reused software
12. Customer Characteristics
• These are the risks associated with the sophistication of the
customer and the ability of the developer to communicate with the
customer in a timely manner.
• Customers have different needs and different personalities.
• They also have varied associations with their suppliers and most
customers are often contradictory.
• Questions that may be asked to check the customer characteristics
are as given below:
– Have we worked with the customer before?
– Does the customer know what he wants?
– Will the customer spend time to formally define the requirements
and scope of the project at a meeting?
– Is the customer willing to communicate closely with the
developer?
– Will the customer participate in reviews?
– Is the customer technically sophisticated in the product area?
– Will the customer let the process occur without looking over our
shoulder during technically detailed work?
– Does the customer understand the software process?
13. Process definition
• These risks are associated with the degree to
which the software process has been defined
and followed by the development organization.
• Questions that may be asked to check process
definition risks are as given below:
– Does management support a written policy that
stresses the use of a development process?
– Are staff members willing to use the process?
– Is the process similar for all projects?
– Are standards published and available for all
developers and managers?
– Are the standards being followed?
– How are the aspects of the process being monitored?
– What software tools are being used in the
development of the project?
14. Business Impact
• These are the risks associated with constraints
posed by the management or the market.
• Some parameters that can affect business
impact are given below:
– Effect of the product on company income
– Visibility of the product to senior management
– Number of customers using the end product and how
stable their needs remain
– Knowledge levels of end users, Level of
documentation needed for the customer
– Governmental constraints
– Cost of late delivery
– Cost of a defective product
15. Development environment
• These are risks associated with the availability and quality of the
tools that may be used to build the product.
• If defective materials and tools are used in any trade, the end
product will not meet the specified requirement.
• Good, proper tools are a pre-requisite to any trade.
• The checklist drawn to check the development environment will be
based on the availability of the following:
– Process and project management tools
– Analysis and design tools
– Appropriate tools for the project
– Appropriate compilers and code generators
– Testing tools
– Database or Data stores
– Integration of tools with each other
– Trained staff
– Help for using the tools
16. Technology
• These are risks associated with the complexity of the
system and the unfamiliarity with the new technology.
• The checklist for technology parameters is as given
below:
– Is the technology new to our organization?
– Does the customer demand new algorithms or input or output
technology?
– Does the software interface with new or unproven software?
– Is a specialized interface demanded by the product
requirements?
– Is the type of software to be developed new to our organization?
– Are we using new analysis, design or testing methods for this
project?
– Are the required development methods unconventional?
– Do the requirements put excessive performance constraints on
the product?
17. Risk associated with staff size and
experience
• In addition to all the above factors, we must also
assess staff size and experience.
• The questions that will help us arise at the right
conclusion are as follows:
– Are the best people available?
– Do the people have the right combination of skills?
– Are there enough people?
– Is the staff committed for the entire duration of the
project?
– Is there any staff working part time on the project?
– Does the staff have the necessary training?
– Will the change in staff be low enough to maintain
continuity?
