In our last issue, we posed the following questions that we believe each quality executive should be able to answer about risk. The questions are:
In The BeginningTo quote Charlie Brown, “Aaaaaaaaaaaargh!” Haven’t we learned anything? The mantra for years has been to build security in at the beginning not the end. Continue reading
There are many risks involved in creating high quality software on time and within budget. With ever-increasing software complexity, increasing demands for bigger and better products, and even decreasing time to market, the software industry is a high-risk business.
When software teams don’t manage these risks, they leave their projects vulnerable to factors that can cause major rework, major cost or schedule over-runs, delivered product that don’t match their intended use requirements (for example, product that have safety, security, usability or functionality gap) or other project failures. Continue reading
We deal with appetites and thresholds every day, both personally and professionally. Project risk management is no exception and knowing your appetite and threshold may save your project a lot of grief.
When managing project risks (or any risks for that matter), I’ve found that there are always two versions of appetite and threshold. The first is what I’ll call the “perceived” level and the second is the “actual” level. This may sound like splitting hairs, but I’ve found multiple times on projects that they both do exist and always come into play at some point.
In my work as a software architect and security expert, I always consider boundary conditions such as malicious input as opposed to normal behavior. I also consider innocuous errors that could lead to disastrous consequences.
I immediately applied this approach to the NSA Prism program and came up with 3 scenarios: