Главная Обратная связь

Дисциплины:






Design and development approaches



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:

  • The structure (for example, milestones/stages/phases)
  • The activities (for example, the workflows or detailed steps/tasks described within an approach)
  • The primary models associated with the chosen method, typically giving a process perspective, a data perspective, an event perspective and, often, a user perspective. Examples include use case diagrams, class diagrams and state chart diagrams from the Unified Modelling Language (UML).

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:

  • Produce a first service delivery in weeks, to achieve an early win and rapid feedback
  • Invent simple solutions, so there is less to modify and also facilitating change
  • Improve design quality continually
  • Test early for less expensive fault-finding
  • Use basic disciplines such as reviews, configuration and change management to keep control.

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:

  • Reach or converge on a design acceptable to the customer and feasible to the development team
  • Limit the project’s exposure to the unpredictable elements of both business and environmental change
  • Save development time, although for a successful RAD project, something other than schedule must be negotiable. (RAD has the best chance for success if the business is willing to negotiate on both functionality and quality).

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

  • ‘Fitness for business purpose’ as the criterion for acceptance of deliverables
  • Representation of all parties that can impact application requirements throughout the development process
  • Customers, developers and management accepting informal deliverables, e.g. notes from user workshops rather than formal requirements documents
  • Creating the minimum documentation necessary to facilitate future development and maintenance
  • Empowerment of development teams to make decisions traditionally left to management
  • Iteration being used in such a manner as to converge towards an acceptable business solution
  • Prototypes that can incorporate evolving requirements quickly, to gain consensus early in the lifecycle.

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:

  • Fully understand the advantages and disadvantages of the package approach
  • Define a framework for effective software package selection
  • Define a framework for effective customization and integration
  • Define functional requirements at the appropriate level
  • Develop a checklist of management and operational requirements
  • Define product and supplier requirements
  • Define service integration requirements
  • Identify and investigate potential off-the-shelf software package solutions
  • Present recommendations about the fit of a selected off-the-shelf software package against agreed requirements, and define the implications of this.

Detailed standards will be needed on:

  • Packages and prototyping
  • Defining the structure of weighted evaluation matrices
  • Iteration in package selection.

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

  • Evaluating the functional match
  • Scripted demonstrations and user-driven evaluation
  • Evaluating the management and operational match
  • Evaluating the implementation requirements match.

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

  • High-level functions (for scoping purposes)
  • Business functions and significant events
  • Significant input and output requirements
  • Data (static) structures
  • Identifying relationships between those structures, functions and events
  • Service-wide management and operational requirements
  • Non-functional requirements such as performance, throughput, disaster recovery capabilities, infrastructure and security standards.

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

  • Available off-the-shelf
  • Can be configured. Estimate the effort to perform the configuration. This only needs to be done once and will be preserved over upgrades of the product
  • Must be customized. Estimate the effort to perform the customization initially and to repeat it on each upgrade of the product, bearing in mind that the customization concept might not be applicable to future releases.

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.





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...