Register now or log in to join your professional community.
i want to know about the risk management analysis in the software engineering. What steps we taken for risk management to analyze, design and development in software engineering?
Interesting question.
Not sure why there is only one answer. This can be discussed for hours.
Anyways, let me start here and fellows to join us later.
Though the question is not clear enough to understand.
I assume that you want to know what is risk management and how to do that.
Let me start..
Risk management in software engineering is to anticipate the various future danger, failure, defect, or harm that could be possible on the software due to mistakes in software development process.
Risk is involved in every phase of SDLC, so the first task is to anticipate a risk for each phase. You can do all risk anticipation at the start of the phase or at start of SDLC or both.
I will advise both. You can anticipate high level risk at start of the SDLC. and then keep updating at start of each phase.
Now once you listed the risk next task is to rank/index it.
Rank/index is nothing but probability of risk occurrence (i.e how likely the risk will occur) multiplied by its impact.
The impact can be1 to5.
The probability can be1-5.
So the rank can be1 -25.
e.g. The probability is5 and the impact3, the risk index can be15.
You can also put a threshold for your project.
e.g. you set the threshold as20 and if any of the risk reaches or crosses this threshold. An immediate action is required.
Now once you anticipated the risk and its index.
The next task is to take action.
You can avoid, mitigate, or provide a contingency plan.
Try first to avoid the risk. So that, that defect/failure/harm will never occur.
If not possible, try to mitigate it. i.e. plan some action to perform which will lower the chances or impact of the defect/failure/harm.
If not avoided, you should have contingency plan which will tell you what to do if that defect/failure/harm occurred. So that you will not have to run search for solution once that defect/failure/hard occurred.
Even if the risk is mitigated you should have contingency plan.
You can also classify risk in order have better control in risk management:
• SOFTWARE REQUIREMENT RISKS
1.Lack of analysis for change of requirements.
2.Change extension of requirements
3.Lack of report for requirements
4.Poor definition of requirements
5.Ambiguity of requirements
7.Change of requirements
8.Inadequate of requirements
9.Impossible requirements
10.Invalid requirements
• SOFTWARE COST RISKS
1.Lack of good estimation in projects
2. Unrealistic schedule
3.The hardware does not work well
4.Human errors
5.Lack of testing
6. Lack of monitoring
7.Complexity of architecture
8.Large size of architecture
9.Extension of requirements change
10.The tools does not work well
11.Personnel change, Management change, technology change, and environment change
12.Lack of reassessment of management cycle
• SOFTWARE SCHEDULING RISKS
1.Inadequate budget
2.Change of requirements and extension of requirements
3.Human errors
4.Inadequate knowledge about tools and techniques
5.Long-term training for personnel
6.Lack of employment of manager experience
7.Lack of enough skill
8.Lack of good estimation in projects
• SOFTWARE QUALITY RISKS
1.Inadequate documentation
2.Lack of project standard
3.Lack of design documentation
4.Inadequate budget
5.Human errors
6.Unrealistic schedule
7.Extension of requirements change
8.Poor definition of requirements
9.Lack of enough skill
10.Lack of testing and good estimation in projects
11.Inadequate knowledge about techniques, programming language, tools, and so on
Source/References:
Risk Management in Software Engineering.doc
http://en.wikipedia.org/wiki/Risk_management
