Our instructor in the Risk Management course at SMU said that software is always a risk. Since I'm still lacking experience in risk management, I'm not able to either agree or disagree. Instead, I've been curious the reason why was that because he didn't talk much about the reason he thinks so. Today I just found a description in
Risk Management Guide for DoD Acquisition 2003 - DAU which lists difficulties that software causes:
In general, management of software risk is the same as management of other types of risk and techniques that apply to hardware programs are equally applicable to software intensive programs. Nevertheless, some characteristics of software make this type of risk management different, primarily because it is difficult to:
R-1. Identify software risk.
R-2. Estimate the time and resources required to develop new software, resulting in potential risks in cost and schedule.
R-3. Test software completely because of the number of paths that can be followed in the logic of the software.
R-4. Develop new programs because of the rapid changes in information technology and an ever-increasing demand for quality software personnel.
# List ordered by gm130s
Even though this list gives an insight, I'm still not yet fully agreed with the idea. It says the logic paths in software are too many to handle all, but I just don't know how few paths exist in the DoD type of system development, especially because I've been thinking that each DoD systems is one of the largest man-made system unit. However, trying NOT to compare software and DoD systems, it's true that there could be "infinitely" many paths in software the size of which is large to some extent. So, at the end of a day I can agree with the initial statement by my teacher, but there should still be some ways among software professionals to handle risks (otherwise they would fail in their business). I'll just wait and see further learning.
 |
Flan @ Zaguan Cafe, Dallas, TX. Can be also said as pudding (especially what Japanese call so, "プリン"). |
Comments