«Sharam Hekmat PragSoft Corporation Contents 1. INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 SOFTWARE TOOL 1.4 GLOSSARY OF TERMS 2. ...»
• Data Models It should be emphasised that design decisions are made in all three types of modelling. In business modelling we do not simply record the way the business operates now (‘as-is’ processes), we also consider how it could operate with the potential benefit of introducing information systems that can streamline the business activities (‘to-be’ processes). In application modelling, we invent metaphors, screens, and abstractions that enable end-users to use the application as an effective and intuitive tool that blends with their work processes, rather than becoming an obstacle to their work. In system modelling, we invent software artefacts that collectively not only realise the functional requirements for the application, but also satisfy its non-functional requirements.
2.2 Lifecycle Reference Models A software lifecycle is a map, depicting the stages that a software system undergoes, from its original inception, to its final termination (i.e., from cradle to grave). There is, however, no universally agreed www.pragsoft.com 10 UML Process lifecycle that is suited to all software development projects. Various lifecycles have been invented for different purposes. Project characteristics (such as size, timeframe, volatility of requirements, architecture, technologies, expected system lifetime) influence the most appropriate choice of lifecycle for a project.
This section outlines different software lifecycles and their intended usage context. The relationship between the different lifecycles is managed through a gateway reference model. This is described first.
2.2.1 Gateways Reference Model Every software project involves a number of key milestones. Each milestone represents an important event, and provides a review opportunity to decide whether the project should proceed to the next
step. These milestones are called gates. Five universal gates are defined:
Gate Description 0 A business case exists for the proposed solution.
1 Business requirements have been specified and agreed upon.
2 An integration-tested release has been produced, ready for system testing.
3 The release has successfully passed system testing.
4 The release has successfully passed acceptance testing.
Not all gates are relevant to all lifecycles. Also, in some lifecycles a gate may be passed iteratively (i.e., one chunk at a time).
2.2.2 Linear Lifecycle Model The linear lifecycle model (also called the waterfall lifecycle) views software development as a set of phases that take place linearly (i.e., one after the other).
This lifecycle is largely outdated because of the common problems it suffers from:
• It assumes that it is feasible to produce an accurate specification of requirements before getting involved in the design and implementation of the system. Experience has shown that, in most cases, this is not practical. In practice, requirements often tend to be vague and incomplete.
Users are not certain of what they want and, once they see a working system in operation, tend to change their mind.
• It takes too long to produce a demonstrable system, during which time the business climate and hence requirements may change substantially. So by the time the system is delivered, it may be already obsolete.
UML Process 11 Copyright © 2005 PragSoft
• The impact of defects in earlier phases is far too great on later phases. For example, a requirements defect discovered during the coding phase may cost 100-1000 times a coding defect to correct.
• The rate of rework tends to increase substantially from phase to phase, because each phase tends to uncover defects in the deliverables of earlier phases. This in turn derails the project plan and often puts unrealistic pressure on the development team, which ultimately may result in their demotivation and break up.
• The track record of this lifecycle in the industry is very poor, with over 60% of projects never delivering, and of those delivered, over 50% not being used by the end-users.
Despite these shortcomings, the linear lifecycle does have a place in the software industry. Situations
where its application may be sensible include:
• Where the requirements are stable, well understood, and well documented. An example of this is the re-engineering of an existing system that is largely consistent with user requirements, but perhaps technologically obsolete.
• Where the system does not directly interact with end-users (e.g., firmware and communication software).
• Where there is a wealth of existing experience about the problem domain and the project team has had considerable experience of developing similar systems. For example, a company with a good track record of successfully developing payroll applications, is unlikely to hit nasty surprises when developing yet another payroll application.
2.2.3 Proof-of-Concept Lifecycle Model The Proof of Concept (POC) lifecycle is suited to situations where a proposed concept (e.g., a business process, an architecture) needs to be proven before making further development investment. This is largely a risk management tool: by verifying the suitability and effectiveness of an idea on a small scale, we minimise the potential loss resulting from its failure. In practice, most ideas are partially successful, and the POC provides an opportunity to address their shortcomings before implementing them on a large scale.
The POC lifecycle is simple, but iterative. It begins by establishing the objectives and the scope for the POC. The objectives must be clearly stated and, based on these, a modest scope should be
established. Here is an example:
The scope must be manageable, a good representative of the problem domain, and sufficiently rich to enable the verification of the objectives.
During design and coding in POC, emphasis is typically on speed of construction. Trade-off and corner cutting are acceptable practices, provided they do not conflict with the objectives. For example, in the above scenario, it would be perfectly acceptable to implement only rudimentary error handling. However, if one of the objectives were to verify system robustness under erroneous input data, then this would be unacceptable.
2.2.4 CBD Lifecycle Model The Component Based Development (CBD) lifecycle is an emerging lifecycle for the development of distributed client-server systems using component technology.
The Partial Modelling phase involves carrying out enough business/application/system modelling to define a meaningful build scope. A build delivers a well-defined set of business functionalities that end-users can use to do real work. In a process-centric information system, for example, a build may represent the realisation of one or more end-to-end business processes. The scope of a build is not a random selection, but rather a logical selection that satisfies specific development objectives.
Once a build scope is established, we need to decide which of the required components can be reused (e.g., already exist in the organisation or can be bought off-the-shelf) and which ones need to
be developed. Both these phases have their own mini lifecycles:
Reusing an existing component may require some adaptation. For example, the component interface might not be exactly what is required or some of the method behaviours may need alteration. This is achieved through adaptation, which involves wrapping the component with a thin layer of code that implements the required changes.
Building a new component should always begin with defining the component interface. This represents a permanent contract between the component and other components. Once the interface is defined and the intent of each method is established, the component can be designed and implemented.
With all the components for a build in place, the components are then integrated and tested.
Integration will require the writing of glue code that establishes the interaction between the components. Most component technologies allow this to be done productively using a scripting language.
An integrated build is then formally released (by going through system testing). This is then made available to end-users for evaluation. The evaluation environment may be the same as the development environment (for earlier builds that are not mature), or a pseudo live environment (for later builds that are sufficiently mature). The outcome of the evaluation influences the direction of subsequent builds.
2.2.5 DSDM Lifecycle Model The Dynamic Software Development Method (DSDM) lifecycle is another emerging lifecycle that is suited to the development of information systems (that have vague and/or unstable requirements) to tight time-scales. Unlike CBD, DSDM is independent of any particular technology, but like CDB, it relies on an iterative approach to development.
DSDM is also often referred to as RAD (Rapid Application Development). It consists of five main
• Feasibility study, which typically lasts a couple of weeks and assesses the suitability of the RAD approach to the business problem.
• Business study which scopes the overall activity and provides the baseline for subsequent work, including business functionality, system architecture, and development objectives.
• Functional model iteration which, through a series of prototyping iterations, establishes the application functionality. The prototypes are created for their functionality and not intended to be maintainable.
• Design and build iteration, which generates well-engineered prototypes for use in the intended environment.
• Implementation, which involves putting the latest increment into the operational environment and training the users.
The following diagram illustrates a key difference between DSDM and traditional methods. Whereas in the traditional methods, the functionality to be delivered is fixed and time and resources may vary to meet that functionality, in DSDM this is turned upside down: functionality is delivered to a fixed time and resource plan. This is based on a fundamental assumption that 80% of business functionality can be delivered in 20% of the time it takes to deliver the whole thing.
To achieve this, DSDM employs the timebox mechanism. For a given project, there is an overall timebox for the work to be done. This is hierarchically broken into shorter timeboxes of 2 to 6 weeks, which are the focus of monitoring and control activities. Each timebox has an immovable end date and a prioritised set of requirements assigned to it. Some of these requirements are mandatory and some of less priority. A timebox will produce something visible in order for progress to be assessed (e.g., a model or a component). Each timebox is inclusive of all its effort, and is divided
into 3 parts:
• Investigation, which is a quick pass to check that the team is taking the right direction.
• Refinement, which builds on the comments resulting from the review at the end of the investigation.
• Consolidation, which ties up any loose ends.
2.2.6 Small Change Lifecycle Model The Small Change (SC) lifecycle is a streamlined lifecycle suitable for making small changes to an existing system.
SC is especially suitable for implementing the type of changes undertaken in a minor release. For
• Addition of a new piece of functionality that is fairly similar, in its design, to existing functionality.
• Enhancing or enriching an existing piece of functionality without changing its underlying design.
• Making cosmetic changes to the front-end.
• Making changes to the format (but not the logical structure) of input or output data (e.g., changing a report format).