Unit 1.2.3 Software Development

The Waterfall Model

This is a well known model, consisting of a sequence of stages, each of which only begins once the previous stage is completed. It is possible to traverse back through the model to a previous step if necessary. The stages involved are:

Problem Definition
Feasibility Study
Analysis (incl System Investigation/Information Collection)
Design
Evaluation
Installation
Maintenance

Problem Definition

The problem must be carefully identified before the analyst can start the process of designing and building a system. This is because:

The customer may not know the capabilities of computer systems.
The analyst may not know the ins and outs of the problem area.
It ensures the correct problem is solved.
It ensures a solution is created which satisfies the customers needs.
It will determine the end of the project and therefore payment.

Feasibility Study

This study uses TELOS (Technical, Economic, Legal, Operational & Scheduling) to ensure that the project can be completed:

Technical - Is the technology available to solve the problem?
Economic - Is the project economically viable?
Legal - Can the problem be solved within the law?
Operational - Are there enough people to run the new system, and what is the effect on the customer?
Scheduling - Can the problem be solved within the time constraints?

Other factors could include social or environmental effects.

This study results in a Feasibility Report, which details the users requirements, the existing software and hardware, the current systems scope, the major data processing functions and processes, a cost-benefit analysis and a conclusion with recommendations.

Analysis

The analysis involves understanding the current system, the requirements of the new system, proposing the new system and a specification for the new system.

System Investigation (Information Collection)

This technique involves finding out as much as possible about the function of the current system. It can be done in multiple ways:

Questionnaires to Staff and Management
- A fast collection method as many questionnaires can be handed out all at once. It does require that the questions are simple as they cannot be explained.
Interviewing Staff and Management
- More detailed questions can be asked here, and questions asked could be based on previous responses to the questionnaire.
Procedural Observation
- Watching people in the workplace can provide useful information about the function of a system and the problems encountered.
Study of Documents
- These may include manuals/guidelines, codes of conduct, paper files, invoices, receipts, even notes on the wall!

Existing System Analysis

Data
- What data must be stored?
- How is this data collected?
  - Automatic - bar-codes, OMR etc.
  - Design of new data capture forms/methods
Input
- How is data entered into the system?
  - Keyed in manually, or using automated methods?
Processing
- What processing must occur on the data?

Design

All the inputs, processing and outputs must be designed for the new system. This can include screen designs and printed reports. It requires the type of system to be defined, for example a batch or real time system. The software installed must also be considered, as well as the HCI (Human Computer Interface).

This results in a design specification, which details the function of the system and may include its algorithms, designs, screen layouts or data storage methods.

Evaluation

Includes the thorough testing component of the system, using different approaches:

Alpha Testing - Uses workers inside the development company who have not worked on the project, and aims to find bugs in the system.
Beta Testing - Uses a select group of users outside the company to test the software in a different environment.
Destructive Testing - A form of testing which attempts to break the program in as many ways as possible.
Acceptance Testing - The user tests the program against the requirements specification. Once this testing is successful the project can be signed off.

Installation

This covers how the system will be installed. This includes any hardware purchases, staff training, data file creation, the changeover method, and future maintenance.

Documentation

There are two types - user and technical.

User - A guide on how to operate the system, providing descriptions of error messages and troubleshooting.
Technical - Used for later maintenance and may include descriptions of code and modules as well as algorithms.

Conversion

There are 3 main methods of conversion/changeover used:

Phased - One part of the system is changed to the new system while the rest remains on the old system. If any problems occur they are limited and therefore not system-critical.
Parallel - Both the old and new systems run side by side, using live data, so the efficiency of both systems can be compared. Eventually the older system can be taken offline completely.
Direct - A single point in time where the old system is turned off and the new system is brought online. The cheapest, easiest but potentially most dangerous method, as if the system fails there is no backup.

Maintenance

3 main types:

Adaptive - Improvements to the system to meet changes, such as a new VAT threshold.
Perfective - Improvements to meet users requirements, e.g. moving a button or menu.
Corrective - Bug fixing.

The Spiral Model

The spiral model centres around handling risk. It uses four stages, each of which forms a quarter of the spiral which is looped through:

Determine Objectives - The first stage determines the objectives of this iteration of the spiral according to the largest potential risks.
Identify and Resolve Risks - The possible risks are identified and alternative options are considered. The project may come to a halt if the risks are deemed too high.
Development and Testing - The component of the project being worked on is developed and tested.
Planning the next Iteration - This stage plans out what will happen in the next iteration of the spiral.

The spiral model handles risk well and is suited to large projects, but requires skilled risk assessors and managers, which can be costly.

Rapid Application Development (RAD)

This model uses prototype systems, which lack the total functionality of the final system. This could include screen mock-ups or a partially working system. This can be shown to the user for feedback and comments, from which improvements can be made. Each build-evaluate cycle adds improvements until the product is finished and the final prototype becomes the finished system. It is well suited to projects where requirements are unclear at the outset, and is likely to result in a product having excellent usability due to the feedback loop of prototyping. However, it is not suited to creating efficient code, and it does require the involvement of the end user.

Agile Methodology

The agile methodology is a collection of methodologies which cope well with changing requirements. The software is produced in an iterative manner, and features can be added in each iteration. It is commonly described as a set of values and principles that govern how code should be produced. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change. Commonly agile will include a "scrum-team" who develop the software in "sprints". After each of these iterations, the software will be evaluated by the user in a daily stand up meeting. However, it should be noted agile is a very flexible methodology and thus these common features are optional.

Extreme Programming (XP)

A form of agile development. XP puts an emphasis on the coding - a representative customer becomes a part of the team and provides "user stories" (requirements), devises tests and answers programmers questions. Iterations are short and it produces "working versions" - the code will be used in the final product. The order of the user stories must be decided when programming, and code is written by programmers in pairs (pair programming). One programmer codes while the other evaluates the code written, and they swap regularly. Code is refactored to make it more efficient and a clear set of standards are used during development. Programmers work no more than 40 hours a week. The final code quality is likely to be very high, however this method requires a close-knit team and the customer must constantly commit a staff member to the developers.

Summary of Development Methodologies

Model	Principles	Advantages	Disadvantages
Waterfall	Linear sequential Steps completed one after another Possible to backtrack stages	Documentation Simple to understand/manage Clear cut stages and output requirements	End user removed Not suitable for risky projects (not flexible) Problems discovered late, so expensive
Spiral	4 quadrants (objective risk develop plan) Emphasis on risk management Uses prototyping	Risk is controlled Good for large projects Allows changes to requirements	Specialist risk planners required (costly) Complex management Code efficiency is usually not prioritized
Agile	Group of methodologies Emphasis on code quality Iterative	Can deal with changing requirements Customer involvement High quality code (efficient, no bugs)	Client representative required Collaboration required Increases development costs
RAD	Prototyping Iteration Each iteration, prototype is refined	Customer involvement Can deal with changing requirements Excellent functionality in end product	Client representative required Does not scale well Code unlikely to be efficient
XP	Paired programming Code is refactored (made efficient) Testing and coding done at same time	Can deal with changing requirements Customer involvement High quality code (efficient, no bugs)	Client representative required Collaboration required Increases development costs

The Waterfall life cycle is the name given to a programming methodology Explain the advantages for programmers by following this programming methodology.

Answer:

Waterfall has a cyclical (1) model that enables back tracking (1) to the previous stages if needed. There are defined stages so providing deadlines (1) and each programmer can work on a defined stage (1).

An alternative to the Waterfall life cycle is Rapid Application Development (RAD) Describe the reasons why RAD is more applicable for a small team of two programmers*

Answer:

RAD emphasizes immediate development (1) instead of planning (1) Requirements are adjusted and prototypes are used (1). This suits a small team more as there are fewer formalities to follow (1).