Design and development approaches

Предыдущая15161718192021222324252627282930Следующая

It is also important to understand the current generic lifecycle types, methods and approaches to IT service development, in order to decide on standards for the Service Design stage of the lifecycle. To achieve this, a good understanding is needed of the following aspects of the various Service Development Life Cycle (SDLC) approaches:

There is more detail on SDLC in Chapter 5.

3.11.3.1 Rapid Application Development

It is necessary to understand the differences between object-oriented and structured systems development, the basic principles of the ‘Agile’ (Rapid Application Development (RAD) or accelerated development are other terms used in this area) movement and to recognize how a commitment to a software package solution changes the structure of the approach.

These approaches, which by default address a single system (and related services) only, can be supplemented by architectural approaches, such as those based on component-based re-use (see the section on architecture for further discussion).

The application lifecycle model described in the section on Applications Management (section 5.1.3) can be viewed as an example of linear or ‘waterfall’ (or ‘V’ model) based approach, and will not be discussed in further detail here, other than for comparison purposes with other approaches.

The main feature of RAD is the introduction of increments and iterations in the development process for the management of the risks associated with uncertainty and changing requirements. Traditional approaches have assumed that a complete set of requirements could be defined early in the lifecycle and that development costs could be controlled by managing change. However, discouraging change can mean being unresponsive to business conditions. RAD approaches accept that change is inevitable and attempt to minimize the costs of responding to them while still retaining the required quality.

The use of increments implies that a service is developed piece by piece, where every piece could support one of the business functions that the entire service needs. Incremental delivery could result in shorter time to market for specific business functions. The development of every increment requires traversal of all lifecycle stages.



Iterative development implies that the lifecycle will be traversed more than once, by design. Techniques such as prototyping are used to get a better understanding of the requirements (by testing functional, management and operational activities and through communication with users).

Combinations of iterative and incremental approaches are possible. It is possible to start with the specification of requirements for the entire service, followed by the design and development of the application incrementally.

RAD development methods, including the Unified Process and Dynamic Systems Development Method (DSDM) are seen as a response to business expectations, with the goal of reducing the cost of change throughout a development project. DSDM utilizes continuous user involvement in an iterative development and incremental approach, which is responsive to changing requirements, to develop a software system that satisfies the business requirements on time and on budget. Another example, Extreme Programming (XP), calls for developers to:

To make good use of an incremental approach, the design process needs to be based on a separation of concerns, by grouping functions within increments in such a way that their interdependence is minimized.

In general terms, accelerated application development methods adopt a three-phase lifecycle model: accelerated analysis and design, time-boxed development and production and implementation. The methods are usually underpinned by software engineering technology, and rely on joint (IT-user) working and prototyping to quickly define requirements and create a working prototype.

From a business perspective, the use of incremental development and delivery by developers means that a valid, distinct part of the overall service can be delivered before the development team is in a position to complete the whole project. This approach offers early benefits to the business, and provides an opportunity for both the business and development team to discover emergent service properties and learn from their experience. However, it is often difficult to find a sufficiently small first increment that can provide a meaningful service to business.

RAD methods embodying iteration and incremental delivery can be used to reduce both development and implementation risks. The actual projects may not necessarily be easier to manage, but they can facilitate implementation and acceptance. They offer more options for contingency and enable developers to deal with changing business requirements and environmental conditions. They also provide both milestones and decision points for project control purposes. These methods can additionally be used to:

Important Rapid Application Development (RAD) constraints or Critical Success Factors (CSFs) include:

The use of RAD approaches requires skilled, multidisciplinary teams, who are able to advise on when to apply such approaches.

Category Conventional development Accelerated development
General approach Sequential phases Evolutionary
User resource commitment ±15% throughout the project 100% throughout project for project sponsor, ±30% for selected others
Risk Higher – longer-term project problems may not emerge until well into the development project Lower – problems surface early in the development process, requiring quick resolution
Executive sponsorship Has approval authority, but not actively involved High participation – sets scope, reviews progress and resolves issues
Use of joint session, iteration and prototyping techniques Optional Required
Developer skills Specialists, some with limited experience acceptable Highly experienced, multi-skilled professionals required
Use of process support technology, e.g. CASE tools Optional Required
Team structure Usually large with specialized skill sets Usually small with general skill sets, supplemented by specialists as needed
Rigorous scope management Necessary Critical
Phase structure 4–5 phases 3 phases
Individual accountability Difficult to assess Precise accountability

Table 3.4 Comparison between conventional (‘waterfall’) and RAD approaches

3.11.3.2 Off-the-shelf solutions

Many organizations now choose to fulfil their IT service requirements through purchasing and implementing commercial off-the-shelf (COTS) software package solutions. A framework for selecting, customizing and implementing these off-the-shelf packaged solutions is needed and includes the need to:

Detailed standards will be needed on:

Additionally, procedures for evaluating and comparing competing packages in terms of customization/integration requirements are needed and should include:

Standards for documenting requirements prior to package market investigation should include ones specifically showing:

When evaluating COTS solutions, consider the following three ways in which a requirement can be fulfilled:

Also investigate the strategy and release plan of the package supplier and ascertain whether it is aligned to yours, and to what extent you can expect your future requirements to be met by the package.


9035688195340431.html
9035752152517551.html
    PR.RU™