The SPAMEX system.

Anthony Fernandez 07/11/03

IN 1005 Software Engineering

1. Introduction

The SPAMEX system proposed by SCABB is outlined in the attached letter. I hope to suggest a suitable software process model for the development of the SPAMEX system in the following document.

2. The ‘Waterfall’ Model

The waterfall model consists of several stages of the development life-cycle, each of which are completed in turn.

The first stage in applying this model to the development of the SPAMEX system would be to document the system concept and identify the system requirements. After analysing these requirements, one would break the system into pieces, for example; TIP user interface, customer database etc. Each of these components (or subsystems) now require detailed design before the coding can take place. After each of the components has been tested and debugged individually, they can be integrated to form part of the whole SPAMEX system. The system as a whole can now be tested and deployed although requiring ongoing maintenance.

The waterfall model was the first of its kind and is still widely used. It allows documented evidence of progress as each stage must be approved and ‘signed off’ before the next stage is undertaken. This should appeal to SCABB since they have access to these documents and can track the progress of the development of their software. It would also benefit the project manager, who would be able to ensure consistency in the quality of the software and manage accordingly his investments in time and money.

The model also allows the various stages of the development to be overlapped in accordance with the wishes of SCABB. This is particularly useful in this case as the current brief presented by SCABB is not to the detail required by the developer. Further meetings between both parties would be essential and ongoing changes in requirements will be inevitable. However, such iterations are not possible without significant investments in time and money from both the developer and SCABB.

As we can see, one of the main characteristics of the waterfall model is that commitments be made for each stage early on and each one must be completed and ‘signed off’ before the next is undertaken. Many problems may arise from this when applied to the SPAMEX system. For example, instability and other coding problems may not be discovered until the testing of the whole system. In such cases re-design may be required, which is very problematic because from the very beginning, this model assumes feasibility before implementation.

The waterfall model works well when requirements are stable and well defined, the present SPAMEX brief is somewhat vague and specific details may only be attained through extensive client-developer interaction. The present brief does not define enough fixed requirements; these are essential when applying the waterfall model in order to avoid the evolution of the subsystems, which may result in an unstable system development.

This is a preview of the whole essay

The main foreseeable disadvantage to SCABB will be the fact that the waterfall model is a document-driven model. It is unlikely that employees at a managerial level at SCABB will be able to understand the documentation thoroughly; they will not have access to a working model until the entire system has been coded. If the product doesn’t meet their needs at this late stage, there is little that can be done without further expenditure.

3. Evolutionary Development

Developing the SPAMEX system in an evolutionary style can take one of two paths; exploratory development or throw-away prototyping.

Exploratory development is particularly suitable for requirements which are well defined by the client and well understood by the developer. This allows the developer to evolve a system from the initial specification. However, this may not be suitable for the SPAMEX system since the requirements proposed at present are not defined well enough for this method to take place.

Throw-away prototyping however is ideal for the development of the SPAMEX system since it relies on ongoing client-developer interaction to produce refined software that is developed with a client-focused orientation. For the development of SCABB, this method allows for the lack of specific detail in the requirements and uses this brief as a starting point to develop the system through extensive communication between the client and the developer.

Evolutionary development takes an outline description such as described in the initial letter from SCABB. Using this, the developer can construct a specification, develop the system and validate it before presenting this initial prototype to SCABB. Following the feedback given by SCABB, the above stages may be repeated taking into account the client’s new requirements and thus an intermediate prototype is available to SCABB for trial. These stages may be repeated any number of times until a final version of the system is presented.

The speed at which such development takes place is reliant upon the number of prototypes which are created and the speed at which each one of them is developed. This requires special skills in rapid prototyping which are expensive and will add to the overall cost of the system as well as the time which it takes to develop. Furthermore, if contracts are made to outside developers with skills in rapid prototyping, their methods may not be compatible with in-house developers.

When applying such a model, there is often a lack of process visibility since it is hard for either party to foresee the end result. However, evolutionary development is very useful for the rapid development of subsystems, for example; the TIP or TAC user interface. This would allow SCABB to trial the front-end of the system and offer feedback to the developer without concerning themselves with the inner workings of the system.

It is true that design issues are cheaper and easier to resolve through experimentation rather than analysis; this is why evolutionary development is often favoured as it allows a structured, disciplined avenue for experimentation.

3. Re-use Orientated Development

Re-use orientated development is based on the systematic re-use of existing components. Applying this model to the SPAMEX system would involve integrating existing components into the system rather than creating them from scratch.

The process starts from the initial requirements specification, followed by the analysis of each component. In order to accommodate existing components, changes to the requirements must be made before the system is designed with re-used components. The SPAMEX system would now be ready for development, integration and validation.

Using the re-use orientated model has significant advantages, namely the speed at which the system is delivered. This would benefit SCABB in particular since the money invested in man-hours would be reduced. In concern to the developer, the reduction of software developed in-house would be of primary importance.

In principle, this model should produce more reliable systems since existing components have undergone extensive testing. However, the use of existing components means that compromises in the requirements must be made for the SPAMEX system. This is a major drawback for systems such as SPAMEX, which ideally require bespoke components based on business algorithms and specific scenarios. Such precisely tailored components are not often available when applying re-use orientated development.

The SPAMEX system will require ongoing evolution due to the lack of detail in the brief, using re-use orientated development will give the developer less control over the system’s evolution, leaving SCABB with a product that may not fit their required needs.

4. Hybrid Process Models

Hybrid process models combine elements of the waterfall and evolutionary models. The models which I have studied are the incremental model and the spiral model.

4.1. Incremental Development

Applying the incremental model to the development of SPAMEX would begin by defining the requirements to greater detail than at present and assigning them to increments. Using these increments, the developer is now able to design the architecture of the system and develop, validate and integrate each increment though a series of iterations until the final system is produced.

This software process model gives better support for process iteration and allows easier integration of sub-systems. This would greatly benefit the SPAMEX system as its success depends on the stable relationship between the TIP, TAC and PAT sub-systems.

Rework in the software construction process is greatly reduced when using the incremental model due to the identification and resolution of coding problems early in the development life-cycle. Using the incremental model means that the project is less likely to fail and delivery is possible part-by-part. This however, is not necessary for the development of SPAMEX. A major draw back of the incremental model is that the increments must be relatively small; this makes it impractical for larger systems such SPAMEX. Furthermore, when using the incremental model, mapping requirements to increments is not always easy, especially when the requirements are not clearly defined, as in the SPAMEX brief.

4.2. Spiral Development

The spiral model is another hybrid process model that is often represented visually as a spiral; each loop representing an iteration. If applied to the SPAMEX system, the following activities would be repeated until a final system is reached; objective setting, risk assessment and reduction, development and validation and planning.

The spiral model specifically takes risk into consideration for each iteration, this is a benefit not only to SPAMEX, but to all software systems as they all carry a certain amount of risk during development. The spiral model is reflection of real-world practices rather than a theoretical model. This however can also be a disadvantage since it is relatively complex and difficult to follow strictly. It is only really suitable for large systems, not necessarily SPAMEX since we have already sub-divided it into TIP, TAC and PAT. An important issue that developers may be concerned with is the need for expertise in risk evaluation and reduction which is going to significantly increase the cost of development.

5. Conclusion

I have chosen to develop the SPAMEX system using evolutionary development and throw-away prototyping.

At present, SCABB have proposed only the outline for SPAMEX, to apply any other process model to a situation such as this would leave the client with unwanted results. Using throw-away prototyping however gives SCABB a chance to get a better understanding of the system they require and allows the developer to produce a much more refined system. This is done through a series of meetings between client and developer where SCABB would evaluate a rapidly developed system prototype and give feedback to the developer. The developer can use this new information to improve the system and present a more suitable prototype to SCABB at their next meeting. The result would be a highly refined system that has been developed with a customer-orientated focus.

The SPAMEX system.

This is a preview of the whole essay

Document Details

Related Essays

The Speenhamland System.

Respiratory System.

System Choice.

Proposed system