Software Engineering-Fourth Generation Techniques And Risk Management

Read Time:8 Minute, 30 Second

Software Engineering-Fourth Generation Techniques

The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common: each enables the software engineer to specify some characteristic of software at a high level.

The tool then automatically generates source code based on the developer’s specification.

There is little debate that the higher the level at which software can be specified to a machine, the faster a program can be built.

The 4GT paradigm for software engineering focuses on the ability to specify software using specialized language forms or a graphic notation that describes the problem to be solved in terms that the customer can understand.

Currently, a software development environment that supports the 4GT paradigm includes some or all of the following tools:

nonprocedural languages for database query, report generation, data manipulation, screen interaction and definition, code generation;

high-level graphics capability; spreadsheet capability, and automated generation of HTML and similar languages used for Web-site creation using advanced software tools.

Initially, many of the tools noted previously were available only for very specific application domains, but today 4GT environments have been extended to address most software application categories.

Like other paradigms, 4GT begins with a requirements gathering step. Ideally, the customer would describe requirements and these would be directly translated into an operational prototype.

But this is unworkable. The customer may be unsure of what is required, may be ambiguous in specifying facts that are known, and may be unable or unwilling to specify information in a manner that a 4GT tool can consume.

For this reason, the customer/developer dialog described for other process models remains an essential part of the 4GT approach.

For small applications, it may be possible to move directly from the requirements gathering step to implementation using a nonprocedural fourth generation language (4GL) or a model composed of a network of graphical icons.

However, for larger efforts, it is necessary to develop a design strategy for the system, even if a 4GL is to be used.

The use of 4GT without design (for large projects) will cause the same difficulties (poor quality, poor maintainability, poor customer acceptance) that have been encountered when developing software using conventional approaches.

Implementation using a 4GL enables the software developer to represent desired results in a manner that leads to automatic generation of code to create those results.

Obviously, a data structure with relevant information must exist and be readily accessible by the 4GL.

To transform a 4GT implementation into a product, the developer must conduct thorough testing, develop meaningful documentation, and perform all other solution integration activities that are required in other software engineering paradigms.

In addition, the 4GT developed software must be built in a manner that enables maintenance to be performed expeditiously.

Like all software engineering paradigms, the 4GT model has advantages and disadvantages. Proponents claim dramatic reduction in software development time and greatly improved productivity for people who build software.

Opponents claim that current 4GT tools are not all that much easier to use than programming languages, that the resultant source code produced by such tools is “inefficient,” and that the maintainability of large software systems developed using 4GT is open to question. There is some merit in the claims of both sides and it is possible to summarize the current state of 4GT approaches:

1. The use of 4GT is a viable approach for many different application areas. Coupled with computer-aided software engineering tools and code generators, 4GT offers a credible solution to many software problems.

2. Data collected from companies that use 4GT indicate that the time required to produce software is greatly reduced for small and intermediate applications and that the amount of design and analysis for small applications is also reduced.

3. However, the use of 4GT for large software development efforts demands as much or more analysis, design, and testing (software engineering activities) to achieve substantial time savings that result from the elimination of coding.

To summarize, fourth generation techniques have already become an important part of software engineering. When coupled with component-based development approaches, the 4GT paradigm may become the dominant approach to software development.

RISK MANAGEMENT

Every project is susceptible to a large number of risks. Without effective management of the risks, even the most meticulously planned project may go haywire / out of control.

A risk is any anticipated unfavourable event or circumstance that can occur while a project is underway.

Risk management aims at reducing the chances of a risk becoming real as well as reducing the impact of a risk that becomes real.

Risk management consists of three essential activities—

Risk identification
Risk assessment
Risk mitigation.

Risk Identification

The project manager needs to anticipate the risks in a project as early as possible.

As soon as a risk is identified, effective risk management plans are made, so that the possible impacts of the risks is minimised. So, early risk identification is important.

Risk identification is somewhat similar to the project manager listing down his nightmares.

For example, project manager might be worried whether the vendors whom you have asked to develop certain modules might not complete their work in time, whether they would turn in poor quality work, whether some of your key personnel might leave the organisation, etc.

All such risks that are likely to affect a project must be identified and listed.

Types of Risk

There are three main categories of risks which can affect a software project:

Project risks
Technical risks
Business risks

Project risks:

Project risks concern various forms of budgetary, schedule, personnel, resource, and customer-related problems.

An important project risk is schedule slippage. Since, software is intangible, it is very difficult to monitor and control a software project. It is very difficult to control something which cannot be seen. For any manufacturing project, such as manufacturing of cars, the project manager can see the product taking shape. He can for instance, see that the engine is fitted, after that the doors are fitted, the car is getting painted, etc.

Thus he can accurately assess the progress of the work and control it, if he finds any activity is progressing at a slower rate than what was planned.

The invisibility of the product being developed is an important reason why many software projects suffer from the risk of schedule slippage.

Technical risks:

Technical risks concern potential design, implementation, interfacing, testing, and maintenance problems.

Technical risks also include ambiguous specification, incomplete specification, changing specification, technical uncertainty, and technical obsolescence.

Most technical risks occur due the development team’s insufficient knowledge about the product.

Business risks:

This type of risk includes the risk of building an excellent product that no one wants, losing budgetary commitments, etc.

Risk Assessment

The objective of risk assessment is to rank the risks in terms of their damage causing potential.

For risk assessment, first each risk should be rated in two ways: The likelihood of a risk becoming real (r). The consequence of the problems associated with that risk (s). Based on these two factors, the priority of each risk can be computed as follows: p = r * s

Where, p is the priority with which the risk must be handled,

r is the probability of the risk becoming real, and

s is the severity of damage caused due to the risk becoming real.

If all identified risks are prioritised, then the most likely and damaging risks can be handled first and more comprehensive risk abatement procedures can be designed for those risks.

Risk Mitigation

After all the identified risks of a project have been assessed, plans are made to contain the most damaging and the most likely risks first.

Different types of risks require different containment procedures.

Most risks require considerable ingenuity on the part of the project manager in tackling the risks.

There are three main strategies for risk containment:

Avoid the risk:

Risks can be avoided in several ways. Risks often arise due to project constraints and can be avoided by suitably modifying the constraints.

The different categories of constraints that usually give rise to risks are:

Process-related risk:

These risks arise due to aggressive work schedule, budget, and resource utilisation.

Product-related risks:

These risks arise due to commitment to challenging product features (e.g. response time of one second, etc.), quality, reliability etc.

Technology-related risks:

These risks arise due to commitment to use certain technology (e.g., satellite communication).

A few examples of risk avoidance can be the following:

Discussing with the customer to change the requirements to reduce the scope of the work, giving incentives to the developers to avoid the risk of manpower turnover, etc.

Transfer the risk:

This strategy involves getting the risky components developed by a third party, buying insurance cover, etc.

Risk reduction:

This involves planning ways to contain the damage due to a risk.

For example, if there is risk that some key personnel might leave, new recruitment may be planned.

The most important risk reduction techniques for technical risks is to build a prototype that tries out the technology that you are trying to use.

For example, if you are using a compiler for recognising user commands, you would have to construct a compiler for a small and very primitive command language first.

There can be several strategies to cope up with a risk. To choose the most appropriate strategy for handling a risk, the project manager must consider the cost of handling the risk and the corresponding reduction of risk.

For this we may compute the risk leverage of the different risks.

Risk leverage is the difference in risk exposure divided by the cost of reducing the risk.

Even though we identified three broad ways to handle any risk, effective risk handling cannot be achieved by mechanically following a set procedure, but requires a lot of ingenuity on the part of the project manager.