<- previous    index    next ->

Lecture 11, Business and Risk Considerations


Management statement: "It is not a customer unless it has
both a need and ability to pay enough for us to make a profit."

Risk, not software project specific

Key team member in auto accident. Key team member disabled by medical problem.

Risk for software projects

Unrealistic schedule. (It may be phony, management psychology.) Cost overrun. The budgeted labor hours are exceeded. (May be to bad budget estimating, changing requirements, more than predicted defects, configuration management problems, general quality problems, inadequate test plans and testing.) Unrealistic requirement among reasonable requirements. (Some, seemingly harmless statement that can be a show stopper.) Language risk, if everything is specified and the language. (A needed library not available for that specific language.) ((In principle, Universal Turing Machine or any common language can code up any possible algorithm.)) Operating system risk, if everything is specified and the OS. (For knowledgeable developers, requiring Windows, Linux, MacOSX is not a problem. Developing entire application on one OS, then trying to port the application to other OS is high risk.) Not enough information to write specific requirements. (This can cause feature bloat, team working a cross purposes, inability to develop a workable test plan. Generally, this is high risk and will be a failed software development project.) Wrong inputs to write specific requirements. (Error or misunderstanding of customer or product use requirements is high risk. If corrected requirements come after design, design effort lost. After test, both deign and test effort lost. After customer gets software, total project investment lost.) Incomplete testing. (Really bad when customer finds more than typical, or expected number of errors.)

Risk avoidance

With Waterfall Model, much risk is avoided by rapid prototyping. Spiral Model risk avoidance: Designed to be a "risk-driven" process model. For each project artifact, requirements specification, design document, test plan, coding: the project team must decide how much detail is enough and how many process cycles are needed to minimize overall risk. (This minimizes risk of a defective product, thus good quality, yet has cost and schedule risk.) Rational Unified Model risk avoidance: Develop iteratively with risk as the primary iteration driver. Manage requirements, only make required changes. Continuously verify quality, use metrics and full SQA activity. Develop and test component by component. Determine credibility of cost and schedule estimates, priorities, and risk. (This model came about based on best practices to develop good quality software. Part of the process is to set realistic cost and schedule requirements.) Agile Model risk avoidance: Each iteration has all functions: requirements analysis, design, coding, unit testing, acceptance testing. This minimizes risk and allows the project to adapt to changes quickly. (The biggest risk, with high probability, is schedule and cost overrun.) Philosophy on personal risk: Statistically, you will be hurt about 90% of the time by a friend or family member or associate. Statistically, you will be hurt about 10% of the time by an enemy or stranger or casual acquaintance. You probably have few enemies and there are more than seven billion strangers you will never encounter. Hurt includes: hurt feelings, loss of money or opportunity, ... An old proverb: "Keep your friends close and your enemies even closer." "Do not believe anything you read or hear." Until you have checked and double checked. Do not repeat anything you read or hear, until you have triple checked independent sources. You do not want to be a liar.

Now evaluate your risk

In this course. In your other courses. Any risk avoidance you can do?
    <- previous    index    next ->

Other links

Go to top