THE RISK DRIVEN MODEL

THE RISK DRIVEN MODEL - Introduction

As digital systems become part of everyday life for most of us that caused increase in the development of software systems and applications hugely. The increasing number also shows the worries of developers for risk of failure for different stages of the development and different platforms including web. The management of risk is very important factor to be considered for all software development processes. The risk driven model is very simple and easy to use with having low “risk of failure” level which attracts most of the developers.

However, the development of software means developer must anticipate the possible risk of failure for different stages by using right tools and techniques. Though which development technique is more reliable? Or which architecture is enough for developer? And which is model should developer use is still a question. So here I present how risk driven is enough for the developers for all stages (including analysis, security, testing, composition and decomposition etc.) and platforms (including web platforms, trusted computing, UML etc.)

The increasing number of development has heightened the risk of failure for different stages of the development and different platforms including web. The management of risk is very important factor to be considered for all software development processes. The risk driven model is very simple and easy to use with having low “risk of failure” level which attracts most of the developers.

However, the development of software means developer must anticipate the possible risk of failure for different stages by using right tools and techniques.

There are lots of architectural design techniques for software development. The Risk-Driven Model allows developers to design architecture by identifying their most common risks and applying only architecture and design techniques that mitigate them. The main element of the Risk-Driven Model is the promotion of risk to prominence. It is possible to apply the Risk-Driven Model to essentially any software development process, such as waterfall or agile, while still keeping within its spirit.

As they build successful software, software developers are choosing from alternate designs, discarding those that are doomed to fail, and preferring options with low risk of failure. When risks are low, it is easy to plow ahead without much thought, but, invariably, challenging design problems emerge and developers must grapple with high-risk designs, ones they are not sure will work. Henry Petroski, a leading historian of engineering, says this about engineering as a whole:The concept of failure is central to the design process, and it is by thinking in terms of obviating failure that successful designs are achieved. ... Although often an implicit and tacit part of the methodology of design, failure considerations and proactive failure analysis are essential for achieving success. And it is precisely when such considerations and analyses are incorrect or incomplete that design errors are introduced and actual failures occur.

To address failure risks, the earliest software developers invented design techniques, such as domain modeling, security analyses, and encapsulation that helped them build successful software. Today, developers can choose from a huge number of design techniques. From this abundance, a hard question arises: Which design and architecture techniques should developers use?

If there were no deadlines then the answer would be easy: use all the techniques. But that is impractical because a hallmark of engineering is the efficient use of resources, including time. One of the risks developers face is that they waste too much time designing. So a related question arises: How much design and architecture should developers do?

There is much active debate about this question and several kinds of answers have been suggested:

> No up-front design. Developers should just write code. Design happens, but is coincident with coding, and happens at the keyboard rather than in advance.

> Build a documentation package. Developers should employ a comprehensive set of design and documentation techniques sufficient to produce a complete written design document.

> Ad hoc. Developers should react to the project needs and decide on the spot how much design to do.

> The team must always (or never) build full documentation for each system.

> The team must always (or never) build a class diagram, a layer diagram, etc.

> The team must spend 10% (or 0%) of the project time on architecture.

> Use a yardstick. For example, developers should spend 10% of their time on architecture and design, 40% on coding, 20% on integrating, and 30% on testing.

The ad hoc approach is perhaps the most common, but it is also subjective and provides no enduring lessons. Avoiding design altogether is impractical when failure risks are high, but so is building a complete documentation package when risks are low. Using a yardstick can help you plan how much effort designing the architecture will take, but it does not help you choose techniques.

Where a software development process orchestrates every activity from requirements to deployment, the risk-driven model guides only architectural design, and can therefore be used inside any software development process.

The risk-driven model is a reaction to a world where developers are under pressure to build high quality software quickly and at reasonable cost, yet those developers have more architecture techniques than they can afford to apply. The risk-driven model helps them answer the two questions above: how much software architecture work should they do, and which techniques should they use? It is an approach that helps developers follow a middle path, one that avoids wasting time on techniques that help their projects only a little but ensures that project-threatening risks are addressed by appropriate techniques.

Here, we will examine how risk reduction is central to all engineering disciplines, learn how to choose techniques to reduce risks, understand how engineering risks interact with management risks, and learn how we can balance planned design with evolutionary design. This article walks through the ideas that underpin the risk-driven model.

The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: "What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?" The risk-driven model can be summarized in three steps: 1. Identify and prioritize risks, 2. Select and apply a set of techniques, 3. Evaluate risk reduction.

You do not want to waste time on low-impact techniques, nor do you want to ignore project-threatening risks. You want to build successful systems by taking a path that spends your time most effectively. That means addressing risks by applying architecture and design techniques but only when they are motivated by risks.

The key element of the risk-driven model is the promotion of risk to prominence. What you choose to promote has an impact. Most developers already think about risks, but they think about lots of other things too, and consequently risks can be overlooked. A recent paper described how a team that had previously done up-front architecture work switched to a purely feature-driven process. The team was so focused on delivering features that they deferred quality attribute concerns until after active development ceased and the system was in maintenance. The conclusion to draw is that teams that focus on features will pay less attention to other areas, including risks. Earlier studies have shown that even architects are less focused on risks and trade-offs than one would expect.

But what if your perception of risks differs from others’ perceptions? Risk identification, risk prioritization, choice of techniques, and evaluation of risk mitigation will all vary depending on who does them. Is the risk-driven model merely improvisation?

No. Though different developers will perceive risks differently and consequently choose different techniques, the risk-driven model has the useful property that it yields arguments that can be evaluated. An example argument would take this form:

We identified A, B, and C as risks, with B being primary. We spent time applying techniques X and Y because we believed they would help us reduce the risk of B. We evaluated the resulting design and decided that we had sufficiently mitigated the risk of B, so we proceeded on to coding.

This allows you to answer the broad question, "How much software architecture should you do?" by providing a plan (i.e., the techniques to apply) based on the relevant context (i.e., the perceived risks).

Other developers might disagree with your assessment, so they could provide a differing argument with the same form, perhaps suggesting that risk D be included. A productive, engineering-based discussion of the risks and techniques can ensue because the rationale behind your opinion has been articulated and can be evaluated.

Many developers believe that they already follow a risk-driven model, or something close to it. Yet there are telltale signs that many do not. One is an inability to list the risks they confront and the corresponding techniques they are applying.

Any developer can answer the question, "Which features are you working on?" but many have trouble with the question, "What are your primary failure risks and corresponding engineering techniques?" If risks were indeed primary then they would find it an easy question to answer.

Technique choices should vary: Projects face different risks so they should use different techniques. Some projects will have tricky quality attribute requirements (e.g., security, performance etc.) that need up-front planned design, while other projects are tweaks to existing systems and entail little risk of failure. Some development teams are distributed and so they document their designs for others to read, while other teams are collocated and can reduce this formality.

When developers fail to align their architecture activities with their risks, they will over-use or under-use architectural techniques, or both. Examining the overall context of software development suggests why this can occur. Most organizations guide developers to follow a process that includes some kind of documentation template or a list of design activities. These can be beneficial and effective, but they can also inadvertently steer developers astray.

Here are some examples of well-intended rules that guide developers to activities that may be mismatched with their project’s risks.

Such guidelines can be better than no guidance, but each project will face a different set of risks. It would be a great coincidence if the same set of diagrams or techniques were always the best way to mitigate a changing set of risks.

Imagine a company that builds a 3-tier system. The first tier has the user interface and is exposed to the Internet. Its biggest risks might be usability and security. The second and third tiers implement business rules and persistence; they are behind a firewall. The biggest risks might be throughput and scalability.

If this company followed the risk-driven model, the front-end and back-end developers would apply different architecture and design techniques to address their different risks. Instead, what often happens is that both teams follow the same company-standard process or template and produce, say, a module dependency diagram. The problem is that there is no connection between the techniques they use and the risks they face.

Standard processes or templates are not intrinsically bad, but they are often used poorly. Over time, you may be able to generalize the risks on the projects at your company and devise a list of appropriate techniques. The important part is that the techniques match the risks.

The three steps to risk-driven software architecture are deceptively simple but the devil is in the details. What exactly are risks and techniques? How do you choose an appropriate set of techniques? And when do you stop doing architect and start/resume building? The following sections dig into these questions in more detail.

Risks: In the context of engineering, risk is commonly defined as the chance of failure times the impact of that failure. Both the probability of failure and the impact are uncertain because they are difficult to measure precisely. You can sidestep the distinction between perceived risks and actual risks by bundling the concept of uncertainty into the definition of risk. The definition of risk then becomes:

risk = perceived probability of failure × perceived impact

The Risk driven can imply to all of the software development process and all other different models. And developer must anticipate the possible risk of failure for different stages by using right tools and techniques. Effective management of those risks is presently perceived as one of the most important areas of project management.

Still, current software processes leave a considerable space for improvement. As process improvement aims at maximizing process quality and effectiveness while minimizing its risks. There are always the risk on every process of development and developers can apply these risk management or driven techniques also to all other development models i.e. waterfall model etc.

Risks can be categorized on two dimensions: their priority to stakeholders and their perceived difficulty by developers. Be aware that some technical risks, such as platform choices, cannot be easily assessed by stakeholders

Overall, this report tells how we can use the risk driven model to different software development platform and approaches like evaluating quality of web services, process composition, unified modeling languages, balancing, integration, security risk management, security testing, security analysis, trusted system, software analysis.