You are on page 1of 7

Software Life Cycle Models

The "waterfall model", documented in 1970 by Royce was the first publicly documented
life cycle model. The model was developed to help cope with the increasing complexity
of aerospace products. The waterfall model followed a documentation driven paradigm.
The next revolutionary new look at the development lifecycle was the "spiral model",
presented by Boehm in 1985. The spiral model is focused on risk management.

Life cycle models describe the interrelationships between software development phases.
The common life cycle models are:

• spiral model
• waterfall model
• throwaway prototyping model
• evolutionary prototyping model
• incremental/iterative development
• reusable software model
• automated software synthesis

Because the life cycle steps are described in very general terms, the models are adaptable
and their implementation details will vary among different organizations. The spiral
model is the most general. Most life cycle models can in fact be derived as special
instances of the spiral model. Organizations may mix and match different life cycle
models to develop a model more tailored to their products and capabilities.

A software life cycle model depicts the significant phases or activities of a software
project from conception until the product is retired. It specifies the relationships between
project phases, including transition criteria, feedback mechanisms, milestones, baselines,
reviews, and deliverables. Typically, a life cycle model addresses the following phases of
a software project: requirements phase, design phase, implementation, integration,
testing, operations and maintenance. Much of the motivation behind utilizing a life cycle
model is to provide structure to avoid the problems of the "undisciplined hacker".

Spiral Model
The spiral model is the most generic of the models. Most life cycle models can be derived
as special cases of the spiral model. The spiral uses a risk management approach to
software development. Some advantages of the spiral model are:

• defers elaboration of low risk software elements
• incorporates prototyping as a risk reduction strategy
• gives an early focus to reusable software
• accommodates life-cycle evolution, growth, and requirement changes
• incorporates software quality objectives into the product
• focus on early error detection and design flaws
• sets completion criteria for each project activity to answer the question: "How
much is enough?"
• uses identical approaches for development and maintenance
• can be used for hardware-software system development

Waterfall Model

The least flexible and most obsolete of the life cycle models. Well suited to projects that
has low risk in the areas of user interface and performance requirements, but high risk in
budget and schedule predictability and control.

Throwaway Prototyping Model

Useful in "proof of concept" or situations where requirements and user's needs are
unclear or poorly specified. The approach is to construct a quick and dirty partial
implementation of the system during or before the requirements phase.

Evolutionary Prototyping Model

Use in projects that have low risk in such areas as losing budget, schedule predictability
and control, large-system integration problems, or coping with information sclerosis, but
high risk in user interface design.

Incremental/iterative Development

The process for constructing several partial deliverables, each having incrementally more

Automated Software Synthesis

This process relies on tools to transform requirements into operational code. Formal
requirements are created and maintained using specification tools. This is an active
research area, and practical tools for this approach are yet to be developed.
Life Cycle of Testing

This article explains about Differant steps in Life Cycle of Testing Process. in Each phase of the
development process will have a specific input and a specific output. Once the project is
confirmed to start, the phases of the development of project can be divided into the following

• Software requirements phase.
• Software Design
• Implementation
• Testing
• Maintenance

In the whole development process, testing consumes highest amount of time. But
most of the developers oversee that and testing phase is generally neglected. As a
consequence, erroneous software is released. The testing team should be involved right
from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle

1. Requirements stage
2. Test Plan
3. Test Design.
4. Design Reviews
5. Code Reviews
6. Test Cases preparation.
7. Test Execution
8. Test Reports.
9. Bugs Reporting
10. Reworking on patches.
11. Release to production.

Requirements Stage

Normally in many companies, developers itself take part in the requirements stage.
Especially for product-based companies, a tester should also be involved in this stage.
Since a tester thinks from the user side whereas a developer can’t. A separate panel
should be formed for each module comprising a developer, a tester and a user. Panel
meetings should be scheduled in order to gather everyone’s view. All the requirements
should be documented properly for further use and this document is called “Software
Requirements Specifications”.

Test Plan

Without a good plan, no work is a success. A successful work always contains a good
plan. The testing process of software should also require good plan. Test plan document is
the most important document that brings in a process – oriented approach. A test plan
document should be prepared after the requirements of the project are confirmed. The test
plan document must consist of the following information:

• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design

Test Design is done based on the requirements of the project. Test has to be
designed based on whether manual or automated testing is done. For automation testing,
the different paths for testing are to be identified first. An end to end checklist has to be
prepared covering all the features of the project.

The test design is represented pictographically. The test design involves various stages.
These stages can be summarized as follows:

• The different modules of the software are identified first.
• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test
case preparation. So the test design assesses the quality of testing process.

Test Cases Preparation

Test cases should be prepared based on the following scenarios:

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

This article talks about many interesting things like what's the Case for Automated Testing,
Why Automate the Testing Process?, Using Testing Effectively, Reducing Testing Costs,
Replicating testing across different platforms, Greater Application Coverage, Results Reporting,
Understanding the Testing Process, Typical Testing Steps, Identifying Tests Requiring
Automation, Task Automation and Test Set-Up and Who Should Be Testing?.

The Case for Automated Testing

Today, rigorous application testing is a critical part of virtually all software
development projects. As more organizations develop mission – critical systems to
support their business activities, the need is greatly increased for testing methods that
support business objectives. It is necessary to ensure that these systems are reliable, built
according to specification and have the ability to support business processes. Many
internal and external factors are forcing organizations to ensure a high level of software
quality and reliability.

Why Automate the Testing Process?

In the past, most software tests were performed using manual methods. This required a
large staff of test personnel to perform expensive and time-consuming manual test
procedures. Owing to the size and complexity of today’s advanced software applications,
manual testing is no longer a viable option for most testing situations.

Using Testing Effectively

By definition, testing is a repetitive activity. The methods that are employed to carry out
testing (manual or automated) remain repetitious throughout the development life cycle.
Automation of testing processes allows machines to complete the tedious, repetitive work
while human personnel perform other tasks. Automation eliminates the required “think
time” or “read time” necessary for the manual interpretation of when or where to click
the mouse. An automated test executes the next operation in the test hierarchy at machine
speed, allowing test to be completed many times faster than the fastest individual.
Automated test also perform load/stress testing very effectively.

Reducing Testing Costs

The cost of performing manual testing is prohibitive when compared to automated
methods. The reason is that computers can execute instructions many times faster and
with fewer errors than individuals. Many automated testing tools can replicate the activity
of a large number of users (and their associated transactions) using a single computer.
Therefore, load/stress testing using automated methods requires only a fraction of the
computer hardware that would be necessary to complete a manual test.

Replicating testing across different platforms

Automation allows the testing organization to perform consistent and repeatable test.
When applications need to be deployed across different hardware or software platforms,
standard or benchmark tests can be created and repeated on target platforms to ensure that
new platforms operate consistently.

Greater Application Coverage

The productivity gains delivered by automated testing allow and encourage organization
to test more often and more completely. Greater application test coverage also reduces the
risk if exposing users to malfunctioning or non-compliant software.
Results Reporting

Full-featured automated testing systems also produce convenient test reporting and
analysis. These reports provide a standardized measure of test status and results, thus
allowing more accurate interpretation of testing outcomes. Manual methods require the
user to self-document test procedures and test results.

Usability Engineering, an empirical science has quite a simple definition. It studies the human
interaction and cognitive behavior of an individual with respect to performing as task. It could
be as simple as a driving a vehicle or using a product. Users interaction in performing a task
should be in sync with the workflow of the product. Usability Engineering as a science helps in
achieving this goal.

Usability for a Product

A Product should be usable. It means that people can use a product easily and efficiently
to accomplish their own tasks. A product, which is usable, enables workers to concentrate
on their tasks and to do real work, rather than on the tools they use to perform their tasks.

A usable product has the following characteristics:

• It’s easy to learn
• Efficient to use
• Provides quick recovery from errors
• Easy to remember
• Enjoyable to use
• Visually pleasing

Usability applies to every aspect of a product with which a person interacts (hardware,
software, menus, icons, messages, documentation, training, and on-line help). Every
design and development decision made throughout the product cycle has an impact on
that product’s usability.

As customers depend more and more on software to get their jobs done and become more
critical consumers, usability can be the critical factor that ensures that products will be

Usability Engineering Techniques

Usability engineering involves a variety of techniques that can provide important
information about how customers work with your product. Different techniques are used
at different stages of a product’s development.

For example, as processes are being engineered and requirements are being developed,
observations and interviews may be the techniques of choice. Later in the development
cycle, as the “look and feel” of a product is being designed, benchmarking, prototyping
and participatory design may be useful techniques. Once a design has been determined,
usability testing may be used more appropriately. Usability is an iterative process, just
like software development. The usability process works best if it is done in partnership
with product development.

Some usability techniques include

1. User and task observations – observing users at their jobs, identifying their typical
work tasks and procedures, analyzing their work processes, and understanding people in
the context of their work.

2. Interviews, focus groups and questionnaires – meeting with users, finding out about
their preferences, experiences and needs.

3. Benchmarking and competitive analysis – evaluating the usability of similar
products in the marketplace.

4. Participatory design - participating in design and bringing the user’s perspective to
the early stages of development.

5. Paper prototyping – including users early in the development process through
prototypes prepared on paper before coding begins.

6. Creation of guidelines - helping to assure consistency in design through development
of standards and guidelines.

7. Heuristic evaluations - evaluating software against accepted usability principles and
making recommendations to enhance usability.

8. Usability testing - observing users performing real tasks with the application,
recording what they do, analyzing the results and recommending appropriate changes.

• Overall feedback rating given by customer on execution of project / product
• Effort Variance
• Schedule Variance
• Cost of Quality
• Test Design Productivity
• Testing Productivity
• Testing efficiency
• Customer Issues
• Utilization of allocated effort
• Test design coverage
• Test execution coverage