Chapter 2: Application of Software Development Approaches

List of Approaches

The Structured Approach

− Is the most formal and structured of the four approaches.

− Each stage is documented well so there is a reliable record to be used in later stages.
− Involves five steps:

1. Define the problem

2. Plan the solution
3. Build the solution.
4. Check the solution.
5. Modify the solution.
(This is often represented or referred to in a “waterfall diagram”.)

− First two phases (defining and planning) are generally the responsibility of a systems analyst.
− A system analyst develops plans and scheldules and interacts with users of the system.
− Programmers do most of the work for the other stages. They rely on system analysts to provide
detailed specifications of the required program.
− There are two types of programmers in this approach, generally; system and application
programmers.
− A system programmer writes instructions for the computer's OS.
− An application programmer writes the instructions for the computer to peform a specific task.
− During definition of problem stage, system analysts interviews users and management and
collects data about the existing (if any) system through observation, surveys and the collection
of documents.
− A key factor in the definition of problem stage is the feasibility of a planned software solution.

1. Financial feasiblity:
- Does the proposed plan make sense money wise?
- Will it profit the client?
- Can the client afford it?
- Often presented as a “cost-benefit analysis”.

2. Operational feasiblity:
- Will the client be able to operate the software?
- Does the client have the staff/means to use the proposed plan?

3. Technical feasibility:
- Does the client have the required hardware?
- Will the client be able to efficently run the proposed plan on their current systems?

4. Scheduling feasiblity:
- Can we finish this on time?
- Will the client have the proposed plan installed within a reasonable deadline?
The Prototyping Approach

− Can be used in two different ways; as an information gathering tool or as a basis for a fully
working program.
− For example a prototype can be developed and shown to a client just to give them idea of what
the final product will look like, and to get feedback from the client. This is an information
gathering approach.
− As a basis, the client is shown a prototype several times throughout the development process,
and the prototype is eventually refined until it is a final, polished product.
− Prototyping approach is useful for applications when there is a lot of human-computer
interaction. (eg. Multimedia and internet applications)
− Prototype is based off initial specifications from the client.
− Prototype is then shown to client, and changes are made based off their evaluation.

This is a general
BEGIN
prototyping approach.

CREATE PROTOTYPE

EVALUATE PROTOTYPE

NO
ARE CHANGES TO BE MADE?

YES

MODIFY PROTOTYPE

END
The Rapid Application Development Approach (RAD)

− Used to speed up development process.

− Useful when requirements of system are understood well and the scope of project is constrained.
− Employs the reuse of existing modules.
− Reuse of modules that are already well-tested means reduced development time.
− If a module has to be constructed, it is written as a resusable component.

End-user Development Approach

− Basic “day-to-day” approach of most computer users.

− It is simply a user finding a solution to a problem.
− Solved problems are usually small and personal ones.
− Highly informal; little-to-no documentation.
− Uses pre-existing software packages like a spreadsheet program (Excel) or a database
management program (Access).

Methods of Implementation

− Refers to the actual installation (implementation) of the new system.

− Involves conversion of old data into a compatible type for the new system.
− Four main methods are used when converting data for a new system.

Direct Cut-Over
An immediate and complete conversion to the new system.

− The most sudden and “overnight” change between systems.

− All data of old system is required for conversion to new system.
− Usually a minor job and easy approach if the new system involves compatible hardware and
new software.
− If computers are being installed for the first time, this is a bad approach.
− If new system shows problems, old system is not available as backup.

Parallel Conversion
Has complete use of both systems for a period of time, easing into the switch between systems.

− Both systems are used fully for a period of time.

− Means new system duplicates operations of old system, meaning there is a realistic comparison
between the new system.
− If new system fails, old system is available for backup with minimal data loss.
− Drawback is additional workload (two systems running at once) and the staff need to be trained
fully in both systems before it can be used.
Phased Conversion
Involves the gradual introduction of parts of the new system over a period of time.

− Gradual implentation of new system.

− New system is used for some operations while old system is used for others.
− As parts of new system are tested and staff become familiar, it is gradually implentated until the
entire new system has been installed.
− Since the new system is implentated module-by-module, if the new system fails only a certain
part of the system is affected.

Pilot Conversion
Involves the use of parts of the fully installed new system while the old one is still in use.

− New system is fully installed but is only used for some operations.
− Means the old system is still available if the new one fails.
− Allows the users to evaluate new system as a completed version.
− Allows users to train others in usage of the new system.

Current Trends

Outsourcing

− Large organizations reduce size of permanent IT staff.

− Remaining staff are in charge of maintaining a system.
− Development of systems is outsourced (left in the hands of) other organizations.
− Allows for posession of expert-quality software without the need for a full IT department.

Example: Schools rely on other companies for their software (SchoolPRO, etc) but still employ IT
staff to maintain the software.

Populuar Approaches

− The ease-of-use and easy acquisitation of software such as web-page editors has been
encouraging an evolutionary prototyping approach (the flow chart a few pages back).
− Small end-users (everyday folk) usually customize “off-the-shelf” software to solve their own
specific problems.

Employment Trends

− The move toward outsourcing means less likelihood of a development job being permanent.
− Software developers are often hired on a per-contract basis.
− Workers in the IT field are often working under a contract that lasts until the project is done, or
one that is a fixed-term within a development team.
 Use of CASE Tools and their Application

− CASE stands for “Computer-assisted-software-engineering”.

− Developed to help developers in the tasks of software development and maintenance.
− Individual CASE tools designed to support activities such as problem definition, planning,
building, testing and modification.
− Use of commercial software such as Word and Photoshop (or other word processing and visual
drawing programs) can also be used to develop software. (Like when writing out
documentation, or mocking up screen designs or UI elements.)

Software Versions

− Problem with continually evolving software is management of different versions.

− To help, each release is given a name or number. (For example throughout development, Firefox
3 was referred to as “Minefield” pre-release).
− Most common system is a numbering system.
− First version is always 1.0.
− From 1.0, each major version with large, substanial changes are labelled 2.0, 3.0, etc etc. Minor
updates are given version numbers such as 1.1, 1.2, 1.3, and so on. Bug fixes for minor versions
such as 1.2 can add another number, though this presents no visible change to the user. (1.2.1,
2.3.1, etc)
− This process is known as software configuration management (SCM).
− All proposed changes and versions need to be submitted to a central body or person to avoid
conflicting changes made by different parts of development team.
− All changes in versions should be properly documentated, as they may require a new operating
procedure on behalf of the user.
− CASE tools used to track changes include Continuus, PVCS and CMF.

Data Dictionary

− A data dictionary is a centralized repository of information about data such as meaning,

relationships to other data, origin, usage, and format. It's a document that all parts of the
development team can read so that they understand each other's code.
− Use of a good CASE tool for this means that each programmer and member of the team can
access an up-to-date, networked data dictionary.
− CASE tools are useful in large, complex developments where manually managing a data
dictionary would be next-to-impossible.
Well maintained data dictionaries will include a number of entries for each data item. Some of
these are listed below:

Identifier:
the main name of the control or data item. Eg: “cost.”

Alias:
alternative names for the same item. Eg, tempoary data items used for
swapping or other such processes. Eg: “cost_temp”

Processes:
the processes that use the data item together with the way in which the data item is
used. Eg: “cost” may be calculated as “quanity” multiplied by “unit_price.

Other Information:
a generalised category which includes data type info, restrictions or limitations on the
data items and any preset values.

Test Data

− Falls into two categories: data that tests specific modules, and date that tests the system as a
whole, usually under simulated working conditions.
− Usage of a “test-data generator” can be fed conditions and syntax of data and will then output a
large set of test data.
− Program known as a “file comparator” can be used to compare outputs of two different versions
of the same program. Same input data is entered into the two versions and the output is saved.
The comparator then scans each of the output files and indicates where and what the differences
are.

Output from v1.0

Differences
File in output
comparator

Output from v2.0

Production of Documentation

− Documentation is a continiuous process.

− Programmers often make use of existing applications (eg CASE tools) to assist with the
documentation process.
− Allowing the developer to maintain documentation parrallel to the actual development means
there is less delay in the development cycle, and ensures that the documentation accurately
reflects what is in the final product.
Chapter 3: Defining and Understanding the Problem
Defining the Problem

Identifying the problem

The definition of a problem can be found through the identification of the client's needs, objectives
and bounaries.

− Includes examination of multiple factors.

− Includes needs of users, objectives that the solution needs to meet and boundaries in which the
solution must operate.
− Must take into consideration the feasiblity of the proposed solution (see a few pages back)

Needs

− Needs other than the user's own need to be considered when identifying the problem.
− Includes the need to represent various data items, need to store certain facts and the need to
output data in a particular manner.
− Human needs are easiest to identify and address as the developer can put themselves in the
position of the user.
− Activities such as surveys, interviews and observation can help identify human needs of
software.
− Needs of multiple types of users need to be addressed/considered. (The elderly, disabled, etc)
− Also includes physical needs of the user's hardware, such as graphics cards, processor speed,
RAM, and other system requirements.
− Includes specific hardware requirements, for example a speech recognition program requires a
microphone.

Objectives

− An objective is simply the criteria against which performance is measured. For example, if a
program needs to display a value that changes in real time, then the objective would be to
calculate and display the updated value every fiftieth of a second.
− Objectives can be split into categories, for example a set of objectives relating to user
interaction, or a set of objectives relating to the “background” workings of the program.
− Objectives are recorded in statements that put the user's needs into an understandable format.
For example, a company may wish to automate their production line. This initial need is then
broken down into objectives, such as the production line being able to produce a certain number
of items in a specific amount of time.

Boundaries

− When there are multiple systems within a software solution, the places where outputs leave one
of the systems and move to the next are called boundaries.
− Boundaries need to be clearly defined.
− The boundaries need to be communicated to each member of the development team.
Determining the Feasibility of the Solution

− Feasiblity has a range of factors, some obvious (is it worth solving this problem?), and some
less obvious (can we get this done in a reasonable time frame?).
− Through development, the consideration of these factors is reported on in a feasibility study.
− The factors can sometimes become a tangle of technical, scheldule and financial aspects of
feasibility. For example if a project requires a certain hardware component, the development
and installation of that hardware may become a factor technically, time-wise and financially.

Main factors of feasibility in the development of software include:

Financial feasiblity.
Can we afford to develop this? Can the client afford to run this?

Operational feasiblity.
Is the proposed solution user-friendly? Will be people be able to use it easily?

Technical feasibility.
Do the technologies and tools exist to create and run this solution?

Schelduling feasibility.
Can we develop the solution in a decent time frame? Will it still be worth using by
the time it is developed?

Is the problem worth solving?

Is there an easier, already-developed solution to this problem? Is it that big of a deal?

Constraints.
What has the client said we can/can't do? Are the client's staff capable of running the
solution?

Alternatives.
Are there existing solutions?

Social and ethic considerations.

Is the proposed plan ethically responsible?