Activities Involved Software Development Life Cycle Model

Problem solving in software consists of these activities:

1. Understanding the problem

2. Deciding a plan for a solution
3. Coding the planned solution
4. Testing the actual program

For small problems these activities may not be done explicitly. The start end boundaries of these activities
may not be clearly defined, and not written record of the activities may be kept. However, for large
systems where the problem solving activity may last over a few years. And where many people are
involved in development, performing these activities implicitly without proper documentation and
representation will clearly not work. For any software system of a non-trival nature, each of the four
activities for problem solving listed above has to be done formally. For large systems, each activity can be
extremely complex and methodologies and procedures are needed to perform it efficiently and correctly.
Each of these activities is a major task for large software projects.

Furthermore, each of the basic activities itself may be so large that it cannot be handled in single step and
must be broken into smaller steps. For example, design of a large software system is always broken into
multiple, distinct design phases, starting from a very high level design specifying only the components in
the system to a detailed design where the logic of the components is specified. The basic activities or
phases to be performed for developing a software system are:

1. Requirement Analysis / Determination of System's Requirements

2. Design of system
3. Development (coding) of software
4. System Testing

In addition to the activities performed during software development, some activities are performed after
the main development is complete. There is often an installation (also called implementation) phase,
which is concerned with actually installing the system on the client's computer systems and then testing it.
Then, there is software maintenance. Maintenance is an activity that commences after the software is
developed. Software needs to be maintained not because some of its components "wear out" and need to
be replaced, but because there are often some residual errors remaining in the system which must be
removed later as they are discovered. Furthermore, the software often must be upgraded and enhanced
to include more "features" and provide more services. This also requires modification of the software,
Therefore, maintenance in unavoidable for software systems.

In most commercial software developments there are also some activities performed before the
requirement analysis takes place. These can be combined into a feasibility analysis phase. In this phase
the feasibility of the project is analyzed, and a business proposal is put forth with a very general plan for
the project and some cost estimates. For feasibility analysis, some understanding of the major
requirements of the system is essential. Once the business proposal is accepted or the contract is
awarded, the development activities begin starting with the requirements analysis phase.

Following topics describes the above mentioned phases:

1. Preliminary Investigation
2. Requirement Analysis / Determination of System's Requirements
3. Design of system
4. Development (coding) of software
5. System Testing
6. Software Maintenance
7. Error distribution with phases

Preliminary Investigation
Fig 2.1 shows different stages in the system's life cycle. It initiates with a project request. First stage is the
preliminary analysis. The main aim of preliminary analysis is to identify the problem. First, need for the
new or the enhanced system is established. Only after the recognition of need, for the proposed system is
done then further analysis is possible.

Suppose in an office all leave-applications are processed manually. Now this company is recruiting many
new people every year. So the number of employee in the company has increased. So manual
processing of leave application is becoming very difficult. So the management is considering the option of
automating the leave processing system. If this is the case, then the system analyst would need to
investigate the existing system, find the limitations present, and finally evaluate whether automating the
system would help the organization.

Once the initial investigation is done and the need for new or improved system is established, all possible
alternate solutions are chalked out. All these systems are known as "candidate systems". All the
candidate systems are then weighed and the best alternative of all these is selected as the solution
system, which is termed as the "proposed system". The proposed system is evaluated for its feasibility.
Feasibility for a system means whether it is practical and beneficial to build that system.

Feasibility is evaluated from developer and customer's point of view. Developer sees whether they have
the required technology or manpower to build the new system. Is building the new system really going to
benefit the customer. Does the customer have the required money to build that type of a system? All
these issues are covered in the feasibility study of the system. The feasibility of the system is evaluated
on the three main issues: technical, economical, and operational. Another issue in this regard is the legal
feasibility of the project.
 1. Technical feasibility: Can the development of the proposed system be done with current
equipment, existing software technology, and available personnel? Does it require new technology?
2. Economic feasibility: Are there sufficient benefits in creating the system to make the costs
acceptable? An important outcome of the economic feasibility study is the cost benefit analysis.
3. Legal feasibility: It checks if there are any legal hassle in developing the system.
4. Operational feasibility: Will the system be used if it is developed and implemented? Will there
be resistance from users that will undermine the possible application benefits?

The result of the feasibility study is a formal document, a report detailing the nature and scope of the
proposed solution. It consists of the following:

 Statement of the problem

 Details of findings
 Findings and recommendations in concise form

Once the feasibility study is done then the project is approved or disapproved according to the results of
the study. If the project seems feasible and desirable then the project is finally approved otherwise no
further work is done on it.

Determination Of System's Requirements: Analysis Phase In

SDLC
Requirements Analysis is done in order to understand the problem for which the software system is to
solve. For example, the problem could be automating an existing manual process, or developing a
completely new automated system, or a combination of the two. For large systems which have a large
number of features, and that need to perform many different tasks, understanding the requirements of the
system is a major task. The emphasis in requirements Analysis is on identifying what is needed from the
system and not how the system will achieve it goals. This task is complicated by the fact that there are
often at least two parties involved in software development - a client and a developer. The developer
usually does not understand the client's problem domain, and the client often does not understand the
issues involved in software systems. This causes a communication gap, which has to be adequately
bridged during requirements Analysis.

In most software projects, the requirement phase ends with a document describing all the requirements.
In other words, the goal of the requirement specification phase is to produce the software requirement
specification document. The person responsible for the requirement analysis is often called the analyst.
There are two major activities in this phase - problem understanding or analysis and requirement
specification in problem analysis; the analyst has to understand the problem and its context. Such
analysis typically requires a thorough understanding of the existing system, the parts of which must be
automated.

Once the problem is analyzed and the essentials understood, the requirements must be specified in the
requirement specification document. For requirement specification in the form of document, some
specification language has to be selected (example: English, regular expressions, tables, or a
combination of these). The requirements documents must specify all functional and performance
requirements, the formats of inputs, outputs and any required standards, and all design constraints that
exits due to political, economic environmental, and security reasons. The phase ends with validation of
requirements specified in the document. The basic purpose of validation is to make sure that the
requirements specified in the document, actually reflect the actual requirements or needs, and that all
requirements are specified. Validation is often done through requirement review, in which a group of
people including representatives of the client, critically review the requirements specification.

Software Requirement or Role of Software Requirement Specification (SRS)

IEEE (Institute of Electrical and Electronics Engineering) defines as,

1. A condition of capability needed by a user to solve a problem or achieve an objective;

2. A condition or capability that must be met or possessed by a system to satisfy a contract,

standard, specification, or other formally imposed document.

Note that in software requirements we are dealing with the requirements of the proposed system, that is,
the capabilities that system, which is yet to be developed, should have. It is because we are dealing with
specifying a system that does not exist in any form that the problem of requirements becomes
complicated. Regardless of how the requirements phase proceeds, the Software Requirement
Specification (SRS) is a document that completely describes what the proposed software should do
without describing how the system will do it?. The basic goal of the requirement phase is to produce the
Software Requirement Specification (SRS), which describes the complete external behavior of the
proposed software.

System/Software Design Phase In SDLC

The purpose of the design phase is to plan a solution of the problem specified by the requirement
document. This phase is the first step in moving from problem domain to the solution domain. The design
of a system is perhaps the most critical factor affecting the quality of the software, and has a major impact
on the later phases, particularly testing and maintenance. The output of this phase is the design
document. This document is similar to a blue print or plan for the solution, and is used later during
implementation, testing and maintenance.

The design activity is often divided into two separate phase-system design and detailed design. System
design, which is sometimes also called top-level design, aims to identify the modules that should be in the
system, the specifications of these modules, and how they interact with each other to produce the desired
results. At the end of system design all the major data structures, file formats, output formats, as well as
the major modules in the system and their specifications are decided.

During detailed design the internal logic of each of the modules specified in system design is decided.
During this phase further details of the data structures and algorithmic design of each of the modules is
specified. The logic of a module is usually specified in a high-level design description language, which is
independent of the target language in which the software will eventually be implemented. In system
design the focus is on identifying the modules, whereas during detailed design the focus is on designing
the logic for each of the modules. In other words, in system design the attention is on what components
are needed, while in detailed design how the components can be implemented in software is the issue.

During the design phase, often two separate documents are produced. One for the system design and
one for the detailed design. Together, these documents completely specify the design of the system. That
is they specify the different modules in the system and internal logic of each of the modules.

A design methodology is a systematic approach to creating a design by application of set of techniques

and guidelines. Most methodologies focus on system design. The two basic principles used in any design
methodology are problem partitioning and abstraction. A large system cannot be handled as a whole, and
so for design it is partitioned into smaller systems. Abstraction is a concept related to problem partitioning.
When partitioning is used during design, the design activity focuses on one part of the system at a time.
Since the part being designed interacts with other parts of the system, a clear understanding of the
interaction is essential for properly designing the part. For this, abstraction is used. An abstraction of a
system or a part defines the overall behavior of the system at an abstract level without giving the internal
details.

While working with the part of a system, a designer needs to understand only the abstractions of the other
parts with which the part being designed interacts. The use of abstraction allows the designer to practice
the "divide and conquer" technique effectively by focusing one part at a time, without worrying about the
details of other parts.

Like every other phase, the design phase ends with verification of the design. If the design is not specified
in some executable language, the verification has to be done by evaluating the design documents. One
way of doing this is thorough reviews. Typically, at least two design reviews are held-one for the system
design and one for the detailed and one for the detailed design.

Development Of Software - Coding Stage/Phase In SDLC

Once the design is complete, most of the major decisions about the system have been made. The goal of
the coding phase is to translate the design of the system into code in a given programming language. For
a given design, the aim of this phase is to implement the design in the best possible manner. The coding
phase affects both testing and maintenance profoundly. A well written code reduces the testing and
maintenance effort. Since the testing and maintenance cost of software are much higher than the coding
cost, the goal of coding should be to reduce the testing and maintenance effort. Hence, during coding the
focus should be on developing programs that are easy to write. Simplicity and clarity should be strived for,
during the coding phase.

An important concept that helps the understandability of programs is structured programming. The goal of
structured programming is to arrange the control flow in the program. That is, program text should be
organized as a sequence of statements, and during execution, the statements are executed in the
sequence in the program.

For structured programming, a few single-entry-single-exit constructs should be used. These constructs
includes selection (if-then-else), and iteration (while - do, repeat - until etc). With these constructs it is
possible to construct a program as sequence of single - entry - single - exit constructs. There are many
methods available for verifying the code. Some methods are static in nature that is, that is they do not
involve execution of the code. Examples of such methods are data flow analysis, code reading, code
reviews, testing (a method that involves executing the code, which is used very heavily). In the coding
phase, the entire system is not tested together. Rather, the different modules are tested separately. This
testing of modules is called "unit testing". Consequently, this phase is often referred to as "coding and unit
testing". The output of this phase is the verified and unit tested code of the different modules.

System Testing
Testing is the major quality control measure employed during software development. Its basic function is
to detect errors in the software. During requirement analysis and design, the output is a document that is
usually textual and non-executable. After the coding phase, computer programs are available that can be
executed for testing phases. This implies that testing not only has to uncover errors introduced during
coding, but also errors introduced during the previous phases. Thus, the goal of testing is to uncover
requirement, design or coding errors in the programs.

Consequently, different levels of testing are employed. The starting point of testing is unit testing. In this a
module is tested separately and is often performed by the coder himself simultaneously with the coding of
the module. The purpose is to execute the different parts of the module code to detect coding errors. After
this the modules are gradually integrated into subsystem, which are then integrated themselves
eventually form the entire system. During integration of modules, integration testing is performed. The
goal of this testing is to detect design errors, while focusing on testing the interconnection between
modules. After the system is put together, system testing is performed. Here the system is tested against
tech system requirements to see if all the requirements are met and the system performs as specified by
the requirements. Finally, acceptance testing is performed to demonstrate to the client, on the real life
data of the client, the separation of the system.

For testing to be successful, proper selection of test cases is essential. There are two different
approaches to selecting test cases-functional testing and structural testing. In functional testing the
software for the module to be tested is treated as black box, and then test cases are decided based on
the specifications of the system or module. For this reason, this form of testing is also called "black box
testing". The focus is on testing the external behavior of the system. In structural testing the test cases
are decided based on the logic of the module to be tested. Structural testing is sometimes called "glass
box testing". Structural testing is used for lower levels of testing and functional testing is used for higher
levels.

Testing is an extremely critical and time-consuming activity. It requires proper planning of the overall
testing process. Frequently the testing process starts with the test plan. This plan identifies all the testing
related activities that must be performed and specifies the schedule, allocates the resources, and specify
guidelines for testing. The test plan specifies manner in which the modules will integrate together. Then
for different test units, a test case specification document is produced, which lists all the different test
cases, together with the expected outputs, that will be used for testing. During the testing of the unit, the
specified test cases are executed and actual result is compared with the expected output. The final output
of the testing phases is to the text report and the error report, or set of such reports (one of each unit is
tested). Each test report contains the set of such test cases and the result of executing the code with
these test cases The error report describes the errors encountered and action taken to remove those
errors.

SDLC - Implementation And Maintenance In Software Life Cycle

Maintenance includes all the activity after the installation of software that is performed to keep the system
operational. As we have mentioned earlier, software often has design faults. The two major forms of
maintenance activities are adaptive maintenance and corrective maintenance.

It is generally agreed that for large systems, removing all the faults before delivery is extremely difficult
and faults will be discovered long after the system is installed. As these faults are detected, they have to
be removed. Maintenance activities related to fixing of errors fall under corrective maintenance.

Removing errors is one of the activities of maintenance. Maintenance also needed due to a change in the
environment or the requirements of the system. The introduction of a software system affects the work
environment. This change in environment often changes what is desired from the system. Furthermore,
often after the system is installed and the users have had a chance to work with it for sometime,
requirements that are not identified during requirement analysis phase will be uncovered. This occurs,
since the experience with the software helps the user to define the needs more precisely. There might
also be changes in the input data, the system environment and output formats. All these require
modification of the software. The maintenance activities related to such modification fall under adaptive
maintenance.

Maintenance work is based on existing software, as compared to development work, which creates new
software. Consequently maintenance resolves around understanding the existing software and spares
most of their time trying to understand the software that they have to modify. Understanding the software
involves not only understanding the code, but also the related documents. During the modification of the
software, the effects of the change have to be clearly understood by the maintainer since introducing
undesired side effects in the system during modification is easier.

To test whether those aspects in the system that are not supposed to be modified are operating as they
were before modification, regression testing is done. Regression testing involves executing old test cases
to test that no new errors have been introduced. Thus, maintenance involves understanding the existing
software (code and related documents), understanding the effects of change, making the changes - both
to the code and documents, testing the new parts (changes), and resetting of the old parts that were not
changed.

Since often during development, needs of the maintainers are not kept in mind, little support documents
are produced during development to aid the maintainer. The complexity of the maintenance task is
coupled with the neglect of maintenance concerns during development which makes maintenance the
most cost effective activity in the life of a software product.

Error Distribution With Phases In Software Development Life

Cycles
A typical software product may take months to a few years for development, and is in operation for five to
twenty years before it is withdrawn. For software, the cost of development is the incurred during
requirement analysis, design, coding and testing. Therefore, the development cost is the total cost
incurred before the product delivery. The cost of maintenance is the cost of modifying the software due to
residual faults in the software, for enhancing or for updating the software. This cost is spread over the
operational years of the software. Software engineers generally agree that the total cost of maintenance
is more than the cost of development of software. The ratio of development to maintenance cost has been
variously suggested as 40/60, 30/70 or even lower. However, it is generally accepted that the cost of
maintenance is likely to be higher than the development cost, and are often not at all concerned with the
maintenance.

Since maintenance depends critically on the software characteristics that are decided during
development, maintenance cost can be reduced if maintenance concerns are kept in forefront during
development. One of the reasons why this is often not done is that the development cost is done by the
developers while maintenance is often done by the users. Hence, the developers do not have much
incentive for increasing the development effort in order to reduce the maintenance cost. However, for
reduction in overall cost of software, it is imperative that the software be developed so the maintenance is
easy.

The development cost, a typical distribution of effort with the different phases is

Requirement - 10%
Design - 20%
Coding - 20%
Testing - 50%

The exact number will differ with organization and the type of the project. There are some observation we
can make from the data given above. The first is that the goal of design and coding should reduce the
cost of design and coding, but should be to reduce the cost of testing and maintenance, at the expense of
increasing design and coding cost. Both testing and maintenance depend heavily in the design and
coding of the software. And these costs can be considerably reduced if the software is designed and
coded to make testing and maintenance easier. Therefore, during design and implementation, the issues
in our minds should be "can the design be easily tested", and "can it be easily modified". These require
alternate designs and may increase the cost of the design and coding. But this additional costs pay
dividends in the later phases.

Error Distribution
The notion that programming is the central of activity during software development is largely because
normally programming has been considered to be difficult task and sometimes an "art". Another
consequence of this kind of thinking is the belief that errors largely occur during programming, as it is the
oldest activity in software development and offers many opportunities for commiting errors. It is now
realized that errors can occur at any stage during development. A typical distribution of error occurrences
by is

Requirement Analysis - 20%

Design - 30%
Coding - 50%

As we can see, errors occur throughout the development process. However the cost of correcting
different phases is not the same and depends on when the error is detected and correceted. As one old
expect, the greater the delay in detecting an error after it occurs, the more expensive it is to correct it.
Error that occur during the requirements phase, if corrected after coding is completed, can cost many
times more than correcting the error during the requirements phase itself. The reason for this is fairly
obvious. If there is an error in the requirements, then the design and the code will get affected.
To correct the error, the coding that is done would require both the design and the code to be changed
there by increasing the correction. So we should attempt to detect errors in the previous phase and
should not wait until testing to detect errors. This is not often practiced. In reality, sometimes testing is the
sole point where errors are detected. Besides the cost factor, reliance on testing as the primary source for
error detection, due to the limitations of testing, will also result in unreliable software. Error detection and
correction should be a continous proces that is done throughout software development. In terms of the
development phases what this means is that we should try to validate each phase before starting with the
next.