.: Methodology

.: Risks

In software development, “risks” are unknowns which could significantly affect the success of a project.

The goal of risk-analysis is to eliminate as many of these unknown factors as early in the development process as possible in order to avoid the waste of time and resources on efforts that are ultimately unsuccessful or ineffective.

By making an explicit effort to evaluate risks early in the project, we can shape the remainder of the project to use technologies, concepts, or tools which have been shown to be appropriate and effective for this project, greatly minimizing the chance of a failed project or one which costs substantially more than originally planned.

The following is a sampling of some of the risks a software project may face. Every project is different, with its own profile of risks—not all of these risks apply to every project.

Performance. Minimum performance levels are required for specific functions. Need to know whether those levels can be met.
Reliability. The application requires essentially 100% uptime, no runtime errors, and completely accurate outputs. What needs to be in place in order to insure this level of reliability?
Fitness for purpose. What is the likelihood that the finished application will not serve the intended purpose? At what points in the project are specific measures needed to guarantee this does not happen?
Will users like it? Is there a possibility that users will not like the application and will not want to use it?
Will customers buy it? This risk is not primarily the responsibility of the software developer, but it is one the developer should be concerned with. With respect to what the developers and stakeholders know or should know, are we creating a product that customers will buy? Has the requirements analysis phase adequately addressed this question? What are the attributes of the application that will affect the customer’s desire for the product and their decision to buy (and recommend) the product?
Will people use it? What are the reasons people may not use the application? What is the ratio of user-effort to user-benefit? How does this affect the requirements and design of the application?
Reliability of development tools. Are there any doubts about performance or reliability of the development tools for the project? About the database to be used, or third-party software components? Are any new technologies being used whose reliability is unknown? Are we using any data structures or communication protocols that are new or non-standard and may not be compatible with external resources? If the application is reliant on third-party components, what is our fall-back position if the third-party vendor goes out of business or ends support for the product we are using?
Validity of time and cost estimates. What is our level of confidence in time and cost estimates? How much of a buffer does the budget allow for contingencies? To what extent do the time and cost estimates allow for changes of scope during the project? How do we measure the cost-effectiveness threshold in relation to “go / no-go” decisions on the project?
Valid closure on requirements. What is our confidence regarding the validity of the application’s requirements document? How do we verify that all stakeholders understand the requirements and agree with them? How do we avoid the problem of stakeholders as a group being wrong about some of the stated requirements? Where are the areas in this project where that might happen?
Dependence on peer-systems. Does this application depend on any peer-systems for its operation? For example, does it communicate with any third-party systems via web services? Does it interact with in-house systems whose correct operation is essential to this application? What is a justifiable level of confidence in the correct and timely operation of these peer-systems? Do we have fall-back options if and when these systems fail?
Dependence on infrastructure. What are the critical elements of infrastructure—such as networks, servers, switching, desk top computers, storage systems, etc.—that have unknown or unpredictable reliability? Does this application require any of these elements to have an exceptionally high level of reliability? If so, what is our fall-back position, or what can be done to guarantee the required reliability?
Functionality of third-party components. Do all third-party hardware or software components required for this application have the required functionality? For example, if a large database is required for the application, and low-latency replication is essential, do we know for a fact that the candidate DBMS actually delivers the functionality and performance levels we expect?
Validity of algorithms / heuristics. If the success of this application is dependent on proprietary algorithms or heuristic methods, do we know for a fact that these methods are valid and effective? Do we need to objectively test the validity and effectiveness of these methods before proceeding further into the project?
Conformance to corporate standards and procedures. Are there corporate or organization standards which affect the time, cost and/or approach to development of this application? Are there standards regarding development language, design methodologies, documentation standards, approved third-party tools and components, testing methods?

Discovery / Requirements