Application Developments

and Emerging Technology

Chapter 1
Lesson 1-3
Lesson 3. Software Development Life Cycle
• Software Development Life Cycle,
SDLC for short, is a well-defined,
structured sequence of stages in
software engineering to develop
the intended software product.

The Core Stages of SDLC

Steps in SDLC
1. Communication – initiate the request
2. Requirement gathering – bringing out the
information on what the project requirement is
3. Feasibility study – the team analyzes if a
software can be made to fulfill all the
requirements of the user and if there s an
possibility of software being no more useful.
4. System analysis – decide a roadmap of their
plan and try to bring up the best software
model suitable for the project. Understanding
the software limitations and changes to be
done.
Steps in SDLC
5. Software design – the inputs from other users and
information gathered in requirement gathering
phase are the inputs of this steps. Output will be
logical design and the physical design.
6. Coding – programming phase
7. Testing – end user testing
8. Integration – integration with other entity
9. Implementation – installing the software on user
machines
10. Operation and Maintenance – maintaining the code,
the systems for patches
11. Dispositions – retirements; legacy system
Models of Software Development
Paradigms
• Agile Method
• Waterfall Model
• Iterative Model
• Spiral Model
• V- Model
• Big Bang Model
SDLC Model
Agile model
• agile focuses on short iterative
cycles and relies on the team’s
knowledge rather than exhaustive
documentation. Iterative, in
context, provides an initial
solution that is refined through
several versions or iterations
until the solution is sufficient. This
enables agile to be highly flexible
and teams to move and make
changes faster.
SDLC Model
Waterfall model
• the simplest model of software
development paradigm. It says the
all the phases of SDLC will
function one after another in
linear manner. That is, when the
first phase is finished then only
the second phase will start and so
on.
SDLC Model
Iterative Model
• This model leads the software
development process in iterations.
It projects the process of
development in cyclic manner
repeating every step after every
cycle of SDLC process.
SDLC Model
Spiral model
• a combination of both, iterative
model and one of the SDLC model.
It can be seen as if you choose
one SDLC model and combine it
with cyclic process (iterative
model).
SDLC Model
V – model
• The major drawback of waterfall
model is we move to the next
stage only when the previous one
is finished and there was no
chance to go back if something is
found wrong in later stages. V-
Model provides means of testing
of software at each stage in
reverse manner.
SDLC Model
Big Bang Model
• This model is the simplest model
in its form. It requires little
planning, lots of programming and
lots of funds. This model is
conceptualized around the big
bang of universe. As scientists
say that after big bang lots of
galaxies, planets and stars
evolved just as an event. Likewise,
if we put together lots of
programming and funds, you may
achieve the best software product.
System Implementation
System Implementation
• Refers to activities that occurs before the system is turned over to its
users. Its purpose is to:
✓Build a properly working system install it in the organization
✓Replace the old systems and work methods
✓Finalize system and user documentation
✓Train users
✓Prepare support systems to assist users
System Implementation
Implementation
• In addition, implementation involves project closedown, including
personnel evaluation, staff reassignment, project success assessment,
and all resources turnover on those who will support and maintain the
system.
• Implementation is considered to be expensive because there are a lot
people involved in the process. It is also time-consuming since all the
work must be completed. The discussion on implementation covers six
major activities and these are coding, testing, installation, documentation,
user training, and support.
System Implementation
Coding
• Coding is the process where the physical design
specifications developed by the analysis team are
converted into computer codes by the programming
team.
• This can be an involved and intensive activity that
depends on the size and complexity of the system. No
matter what development methodology is used, once
the coding has begun, the testing process can begin
and proceed in parallel.
• With each program module produced, it can be tested
individually, then as part of a larger program, and then
as part of a larger system. These different types of
testing will be discussed in the next subsections.
System Implementation
Testing
• Even though testing is done during implementation,
the planning for testing should start earlier in the
project. Planning covers determining what needs to be
tested and collecting test data.
• Testing is the process of examining a product to
ascertain what defects it contains.
• To conduct a test, programmers should have already
built the software and have in hand well-defined
standards for what composes a defect. The product
can be tested through reviewing their construction
and composition or through exercising their function
and examining the results. Software testing usually
begins early in the systems development life cycle,
although many of the actual testing activities are
carried out during implementation.
Types of Testing
• Components can be tested individually or in groups, or the
entire system can be tested as a whole. There are three testing
types and these are:

1. Unit testing
2. Integration testing
3. System testing
Unit Testing
• Each of this type correlated to a specific phase of the SDLC. Unit Testing
Sometimes called module testing, unit testing is the process of testing
individual code modules before they are integrated with other modules.
• The objective of unit testing is to identify and fix as many errors as
possible before modules are combined into larger software units (such as
programs, classes, and subsystems). Unit testing is often automated but
it can also be done manually. Unit testing can be tedious and time
consuming. It requires patience and meticulousness on the part of the
development team.
• Unit testing should be done with an awareness that it may not be possible
to test a module for every input scenario that will occur when the
program is run in a real-world environment. Once all of the modules in a
program have been found to be working in the most efficient and error-
free manner possible, larger components of the program can be
assessed by means of integration testing.
Integration testing
• Combining modules and testing them is called integration testing. The use of this
is to identify errors that were not or could not be detected by unit testing
individual modules. Such errors could result from several problems, including:
• Interface incompatibility – an example is a caller module that passes a variable
of the wrong data type to a subordinate module.
• Parameter values – a module passed or returns a value that was unexpected
(such as negative number for a price).
• Run-time exceptions – a module generates an error such as “out of memory” of
“file already in use” due to conflicting resource needs.
• Unexpected state interactions – the conditions of two or more modules interacts
to cause complex failures (such as an order class method that operates
correctly for all possible customer object conditions except one).
System testing
• Functionality testing - Tests all functionalities of the software against the
requirement.
• Performance testing - This test proves how efficient the software is. It
tests the effectiveness and average time taken by the software to do
desired task. Performance testing is done by means of load testing and
stress testing where the software is put under high user and data load
under various environment conditions.
• Security & Portability - These tests are done when the software is meant
to work on various platforms and accessed by number of persons.
Acceptance testing
• After the system test are complete, the system is ready for acceptance testing.
This is testing the system in the environment where it will eventually be used.
• Acceptance means that users normally sign off on the system and “accept” it
once they are satisfied with it. In other words, acceptance testing is a way for
users to verify if the system meets its requirements. Usually, acceptance testing
is the last round of testing before the system handed over to its user.
There are two types of acceptance testing and these are:
1. Alpha testing – user testing of a completed information system using
simulated data
2. Beta testing – user testing of a completed information system using real data
in the real user environment
Alpha Testing
In alpha testing, the whole system is implemented in a test environment to find out
whether the system is openly destructive to itself or to the rest of the
environment. These are several types of tests done during alpha testing and these
are as follows:
• Recovery testing – forces the software (or environment) to fail in order to verify
that recovery is properly performed.
• Security testing – verifies that the protection mechanisms built into the system
will protect it from improper penetrations
• Stress testing – tries to break the system
• Performance testing – determines how the system performs in the range of
possible environments in which it may be used; often the goal is to have the
system with similar response time and other performance measures in each
environment
Beta testing
• The purpose of beta testing is to ascertain whether the software,
documentation, technical support, and training activities work as planned.
• Beta testing can be considered as a preparation of the installation phase.
• Problems not covered in alpha and beta testing in any of these areas
should be fixed before users can accept the system.
Regression testing
• Whenever a software product is updated with new code, feature or
functionality, it is tested thoroughly to detect if there is any negative
impact of the added code. This is known as regression testing.
 Testing Documentation
Before Testing
Testing starts with test cases generation. Following documents are needed
for reference
• SRS document - Functional Requirements document
• Test Policy document - This describes how far testing should take place
before releasing the product.
• Test Strategy document - This mentions detail aspects of test team,
responsibility matrix and rights/responsibility of test manager and test
engineer.
• Traceability Matrix document - This is SDLC document, which is related
to requirement gathering process. As new requirements come, they are
added to this matrix. These matrices help testers know the source of
requirement. They can be traced forward and backward.
 Testing Documentation
While Being Tested
The following documents may be required while testing is started and is
being done:
• Test Case document - This document contains list of tests required to be
conducted. It includes Unit test plan, Integration test plan, System test plan and
Acceptance test plan.
• Test description - This document is a detailed description of all test cases and
procedures to execute them.
• Test case report - This document contains test case report as a result of the test.
• Test logs - This document contains test logs for every test case report.
 Testing Documentation
Test Summary
The following documents may be generated after testing :
• Test summary - This test summary is collective analysis of all test
reports and logs. It summarizes and concludes if the software is ready
to be launched. The software is released under version control system
if it is ready to launch.
Installation
After the new system has been developed and tested, it must be installed
and placed into operation. Installation is the process of moving from the
current information system to the new one. There are many constraints
when installing a new system and making it operational. These includes
cost, customer relations, employee relations, logistical complexity, and
overall exposure to risk.
Some other important issues to consider when planning installation are as
follows:
• Incurring costs operating both systems in parallel
• Detecting and corresponding errors in the new system
• Potentially disrupting the company and its IS operations
• Training personnel and familiarizing customers with new products
Approaches to Installation
• These are different approaches to installation and the most commonly
used are:
1. Direct installation
2. Parallel installation
3. Phased installation
Direct installation
• In direct installation, the old system is turned off and the new system is turned
on. The figure below shoes the timeline for direct installation.
• In direct installation, the users use the new system. Whatever errors found from
the new system will have a direct impact on the users and how they do their
jobs. If the new system fails, considerable delay may occur until the old system
can operate again and business transactions are re-entered to make the
database updated.
• The main advantage of direct installation is its simplicity. There are fewer
logistical issues to manage fewer logistical issues to manage fewer resources
required because the old and new systems are not operated in parallel.
However, the drawback of direct installation is its risk. There is no backup when
the new system fails because older systems are not operated in parallel.
Moreover, direct installation requires a complete installation of the whole
system.
Direct installation
In general, direct installation is used in
one or both of the following conditions:
• The new system is not replacing an
older system (automated or manual)
• Downtime of days or weeks can be
tolerated
If neither of the condition applies, then
parallel or phased installation is used to
minimize the risk of the system
unavailability.
Parallel installation
• In parallel installation, the old system continues to
operate along with the new system until the users
and management are satisfied with the
performance of the new system and has been
thoroughly tested and determined to be error-free
and ready to operate independently. All of the work
done by the old system is performed in parallel by
the new system.
• The time allotted for the parallel operation is often
determined ahead and limited to minimize the cost
of dual operation.
• The figure below illustrates the timeline for parallel
installation
Parallel installation
• An advantage of parallel installation is its low risk of system failure and
the negative consequences that may result from that failure. If both
systems are operated completely, then the old system serves as a backup
for the new system. Any failures in the new system can be mitigated by
relying on the old system.
• A parallel installation can be very expensive. Since two systems are
running, it implies employing and paying two staffs to operate and
maintain them. In addition, parallel installation can be confusing to users
because they are dealing with both systems.
• A parallel approach may not be possible or feasible if the users of the
system(such as customers) cannot tolerate redundant effort or if the size
of the system is large.
Phased installation
• In phased installation, the new system is installed and brought into
operation in a series of steps or phases. Components or functions are
added to the operational system on each phase. The system is tested in
each phase to make sure that is ready for the next phased.
• Phased installation can be combined with the parallel installation,
especially when the new system will take over the operation of multiple
existing systems.
• The main benefit of phased installation is that it reduced risks because
failure or a single phase is less problematic than failure of an entire
system. However, its drawback is that is increased complexity. Dividing
the installation into phased makes more activities and milestones, hence
making the whole process more complex.
Phased installation
• Though each individual phase includes a
smaller and more manageable set of
activities.
• Phased installation is useful mainly when a
system is large, complex, and composed of
relatively independent subsystems. If these
subsystems are not substantially
independent, then it is hard or impossible to
define separate installation phases.
Software Maintenance
Software maintenance is widely accepted part of SDLC now a days. It stands for all the
modifications and updations done after the delivery of software product. There are
number of reasons, why modifications are required, some of them are briefly
mentioned below:
• Market Conditions - Policies, which changes over the time, such as taxation and
newly introduced constraints like, how to maintain bookkeeping, may trigger need for
modification.
• Client Requirements - Over the time, customer may ask for new features or functions
in the software.
• Host Modifications - If any of the hardware and/or platform (such as operating
system) of the target host changes, software changes are needed to keep
adaptability.
• Organization Changes - If there is any business level change at client end, such as
reduction of organization strength, acquiring another company, organization
venturing into new business, need to modify in the original software may arise.
Types of Maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may
be just a routine maintenance tasks as some bug discovered by some user or it
may be a large event in itself based on maintenance size or nature.
• Corrective Maintenance - Fixes errors and problems found by users or
through error reports.
• Adaptive Maintenance - Updates the software to stay compatible with
changing technology and business environments.
• Perfective Maintenance - Adds improvements, new features, and refinements
to enhance performance and usability over time.
• Preventive Maintenance - Makes changes to prevent potential future issues
before they become serious problems.