Prev | Current Page 129 | Next

Peter Farrell-Vinay

"Manage Software Testing"


No high-level designs are being developed, nor is any prototyping). When in week 26 a new project
manager is appointed he speedily junks all the existing code, changes the development approach, sacks
the team leaders, reorganizes the development process, and puts a workable plan in place. The failure of
the project to use an appropriate development method was having a knock-on effect throughout the
whole of the project. It was a source of risks and a major driver. Here are some more:
??? Use of an inappropriate (unrelated to the risk) method or process.
??? Lack of customer involvement. Apart from the obvious need for a sufficient set of requirements
there is the need for feedback to users of (fragments of) the proposed solution.
??? Dissimilarity to previous projects. If ???we??™ve never done anything as (big/complex/different) as this
before??? is an issue, then beware.
??? Project complexity. This is relative to the experience of an organization. What might exhaust some
organizations will be run-of-the-mill to others.
??? Requirements volatility. If such changes aren??™t allowed for, the project will soon deteriorate.
This list appears to be merely a set of big risks, however each point shown will affect a range of related
risks. When the existence of the big risk is recognized, the subsidiary risks can be tackled together rather
than in isolation.
32
Manage Software Testing
3.1.3 Product Risk
Among the various risks the project may pose, the product risk in particular needs to be decomposed
since some features are more risk-bearing than others.


Pages:
117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141