Compiled by: Sandip Timsina

Note: Please refer to lecture slides for change management

Characteristics of system quality

The quality of a system is measured by

• Completeness — the system meets all the performance specifications and provides all the
functions specified.

• Correctness — the system performs the required functions accurately.

• Reliability — the system can handle normal and peak loads.

• Consistency — Operations are carried out in the same manner each time they are requested.

• Efficiency — the amount of computer resources required by the system is reasonable.

• Integrity — Access to software or data by unauthorized persons can be controlled.

• Testability — the system is designed so that it can be tested to ensure it performs the intended
functions.

• User-friendliness — the system is easy to use, and users can understand the interactive
dialogue.

• Maintainability — Programming is structured and well-documented, changes can be made

easily, and errors can be corrected with relative ease.

Software Development Life Cycle

The software development life cycle (SDLC) is a framework defining tasks performed at each step in the
software development process. SDLC is a structure followed by a development team within the software
organization. It consists of a detailed plan describing how to develop, maintain and replace specific
software. The life cycle defines a methodology for improving the quality of software and the overall
development process.

There are following six phases in every Software development life cycle model:

1. Requirement gathering and analysis

2. Design
3. Coding
4. Testing
5. Implementation/Deployment

1 | System Development
Compiled by: Sandip Timsina

6. Maintenance

Requirement gathering and analysis

The requirements gathering process takes as its input the goals identified in the high-level requirements
section of the project plan. Each goal will be refined into a set of one or more requirements.

These requirements define the major functions of the intended application, define operational data
areas and reference data areas, and define the initial data entities. Major functions include critical
processes to be managed, as well as mission critical inputs, outputs and reports. A user class hierarchy is
developed and associated with these major functions, data areas, and data entities. Each of these
definitions is termed a Requirement. Requirements are identified by unique requirement identifiers and,
at minimum, contain a requirement title and textual description.

How to do requirement gatherings

1. Unstructured Interview
2. Structured Interview
3. Direct Observation
4. Questionnaire
5. Statistical sampling
6. Study of organizational policies, processes, practices and other publications

Design:
In this phase the system and software design is prepared from the requirement specifications which
were studied in the first phase. System Design helps in specifying hardware and system requirements
and also helps in defining overall system architecture. The system design specifications serve as input for
the next phase of the model.

The blueprint of the system is developed in this stage. Various tools/software can be used in this phase
and they are called CASE (Computer Aided Software Engineering ) tools.

ER diagrams, data-flow diagrams, process diagrams, class diagrams, network architecture, hardware
configurations and architecture are developed in this phase.

Coding:
On receiving system design documents, the work is divided in modules/units and actual coding is
started. Since, in this phase the code is produced so it is the main focus for the developer. This is the
longest phase of the software development life cycle. The outputs of the development stage include a
fully functional set of software that satisfies the requirements and design elements previously
documented, an online help system that describes the operation of the software, an implementation
map that identifies the primary code entry points for all major system functions, a test plan that
describes the test cases to be used to validate the correctness and completeness of the software.

2 | System Development
Compiled by: Sandip Timsina

Testing:
After the code is developed it is tested against the requirements to make sure that the product is
actually solving the needs addressed and gathered during the requirements phase. During this phase
unit testing, integration testing, system testing, acceptance testing are done. Program testing focuses on
ensuring that the programs work as intended and produce correct results in a controlled environment.
Acceptance testing focuses on the use of the system by the intended users, such as whether it continues
to work as intended when users operate it. Certain aspects of the interface design may confuse users
and lead them to misinterpret the results or misuse functions. Such errors result in an overall failure of
the system to produce the results to meet system goals, and they must be addressed before the system
is rolled out.

Program testing

The steps in program testing include unit testing, integration testing, and system testing. In unit testing,
the individual modules of the system are tested for any potential errors in the code. Because the
modules must work together, integration testing is used to check this interoperability. The modules are
grouped together gradually, with testing occurring as each module is added. In a typical top-down
approach, this testing compares the program outputs to the inputs for consistency. The goal of testing is
to ensure that modules satisfy the system requirements and goals.

The final stage of program testing is complete system testing. The goal of system testing is to see how all
the components of the new systems will work under various conditions, including normal loads and
peak loads. Most of this testing is in the form of simulations and is only a guideline, not an absolute
answer.

Acceptance testing

Acceptance testing involves the actual users of the completed system and measures how well it meets
their expectations and requirements. Alpha testing uses simulated data. During this phase, users test
system performance. Procedures for security and recovery are also tested during this time. Beta testing
uses the actual data of the completed system and is the final stage before installation.

Alpha testing is simulated or actual operational testing by potential users/customers or an independent

test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of
internal acceptance testing, before the software goes to beta testing.

Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to
a limited audience outside of the company. The software is released to groups of people so that further
testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to
the open public to increase the feedback field to a maximal number of future users

Stress testing tries to break the system by not following the established rules and procedures. What
happens if you don’t follow the correct sequence of steps or if you submit incomplete records? A system

3 | System Development
Compiled by: Sandip Timsina

that crashes when users make simple errors such as these would not be very useful. Such testing is
important to assure system performance as it relates to user volume.

Stress testing also considers the performance of the system under heavy use conditions.

Performance testing examines the use of the system in different environments. Suppose an
organization has multiple networks and workstations running different operating systems

Deployment:
After successful testing the product is delivered / deployed to the customer for their use.

Deployment Strategies

Direct cutover/abrupt cutover

In a direct cutover conversion, the old system is discarded and the new system takes over all at once.
Also known as the plunge, abrupt cut-over, or the "big bang" approach, it is essentially turning the old
system off and turning the new system on. This approach can be the least expensive of the different
methods and can occur in the quickest time.

Phased conversion

In a phased conversion, a new information system is broken down into smaller functional components
that can be brought into operation one at a time, with each one adding more improvements and
functionality to the overall system. A phased installation is gradual, incremental, and easier to manage
than the other installation approaches. A phased approach keeps the risk fairly low by spreading the
conversion out over time.

Parallel conversion

In a parallel conversion, the old system continues to be used at the same time as the new system is
introduced. Both systems run in parallel for a predetermined amount of time. People use both systems
but increase the amount of time that they use the new system until it is in use the majority of the time.
Then the old system is discontinued. A parallel conversion allows for a comparison of the new system to
the old so that you can benchmark and quantify its effectiveness. A parallel conversion also minimizes
the risks of operational and data-processing failures because the old system continues to function with
the new system.

Pilot conversion

In a pilot conversion, the new system is introduced in a single unit or location for a set period before it is
installed in other parts of the organization. The pilot conversion allows an organization to test out a new
system in a controlled way. It limits the amount of disruption and harm a new system can produce in an
organization. By concentrating on one site or department, you can work out all of the details and
potential problems before the new system is introduced to the organization as a whole.

4 | System Development
Compiled by: Sandip Timsina

Systems maintenance or support

Systems maintenance or support is the process of fixing errors and adapting the system to the changing
requirements. In a well-designed system, the systems analyst has considered ease of maintenance and,
to a certain extent, designed the system to adapt to the changing needs of the business. Some people
distinguish between corrective action (bug fixing) and adapting to new requirements, calling the former
systems maintenance and the latter systems enhancement. Maintenance, excluding enhancement
activities, includes a broad range of corrections to

● program bugs
● Design bugs
● DocumentaƟon errors
● operaƟng-procedure errors
● test-data errors

For example, if a point-of-sale system was built before a provincial sales tax was implemented, it would
need to be modified to handle this new tax. In this case, the process is systems enhancement. However,
if an error is found with the calculation of provincial sales tax for sales returns (and the error was not
detected during testing), the modifications required would be classified as systems maintenance.

Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase
must be completed fully before the next phase can begin. At the end of each phase, a review takes
place to determine if the project is on the right path and whether or not to continue or discard the
project. In waterfall model phases do not overlap.
Diagram of Waterfall-model:

Advantages of waterfall model:

5 | System Development
Compiled by: Sandip Timsina

Simple and easy to understand and use.

Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review
process.

Phases are processed and completed one at a time.

Works well for smaller projects where requirements are very well understood.

Disadvantages of waterfall model:

Once an application is in the testing stage, it is very difficult to go back and change something that
was not well-thought out in the concept stage.

No working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Not a good model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Not suitable for the projects where requirements are at a moderate to high risk of changing.

RAPID APPLICATION DEVELOPMENT (RAD) / PROTOTYPING LIFECYCLE

RAD is, in essence, the “try before you buy” approach to software development. The theory is that end
users can produce better feedback when examining a live system, as opposed to working strictly with
documentation. RAD-based development cycles have resulted in a lower level of rejection when the
application is placed into production, but this success most often comes at the expense of a dramatic
overruns in project costs and schedule. The RAD approach was made possible with significant advances
in software development environments to allow rapid generation and change of screens and other user
interface features. The end user is allowed to work with the screens online, as if in a production
environment. This leaves little to the imagination, and a significant number of errors are caught using
this process.

The down side to RAD is the propensity of the end user to force scope creep into the development
effort. Since it seems so easy for the developer to produce the basic screen, it must be just as easy to
add a widget or two. In most RAD lifecycle failures, the end users and developers were caught in an
unending cycle of enhancements, with the users asking for more and more and the developers trying to
satisfy them. The participants lost sight of the goal of producing a basic, useful system in favor of the
siren song of glittering perfection.

Incremental Model
In incremental model the whole requirement is divided into various builds. Multiple development cycles
take place here, making the life cycle a“multi-waterfall” cycle. Cycles are divided up into smaller, more
easily managed modules. Each module passes through the requirements, design, implementation

6 | System Development
Compiled by: Sandip Timsina

and testing phases. A working version of software is produced during the first module, so you have
working software early on during the software life cycle. Each subsequent release of the module adds
function to the previous release. The process continues till the complete system is achieved.

Diagram of Incremental model:

Advantages of Incremental model:

Generates working software quickly and early during the software life cycle.

More flexible – less costly to change scope and requirements.

Easier to test and debug during a smaller iteration.

Customer can respond to each built.

Lowers initial delivery cost.

Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages of Incremental model:

Needs good planning and design.

Needs a clear and complete definition of the whole system before it can be broken down and built
incrementally.

Total cost is higher than waterfall.

7 | System Development