Pearson BTEC Level 4

Higher Nationals Certificate

in Computing (RQF)

Unit 9 – Software Development

Lifecycles
• Discuss the suitability of software behavioural design LO4
techniques.
LO3
• Undertake a software development lifecycle.
LO2
• Explain the importance of a feasibility study.
LO1
• Describe different software development lifecycles.
By the end of this unit students will be able to:
Learning Outcomes
 LO1 - Describe different software development lifecycles
Essential Content

 Software development lifecycles:

o Lifecycle models: understanding and use of predictive
(Waterfall, Prototyping, RAD) and adaptive (Spiral, Agile,
DSDM) software development models.
o Lifecycle stage and connectivity: feasibility study, analysis,
design, implementation, testing, review or analysis, design,
implementation, maintenance, planning; requirements
traceability.
o Test and integration: building test environments; developing
test harnesses; black box/white box testing; incremental
testing; acceptance test and integration approaches;
changeover strategies, trials and Go-Live prerequisites.
 Lifecycle models
 Understanding and use of software development models.
o Predictive
• Waterfall,
• Prototyping
• RAD

o Adaptive
• Spiral
• Agile
• DSDM
 Waterfall model

 The Waterfall Model was the 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 before
the next phase can begin and there is no overlapping in the
phases.
 The Waterfall model is the earliest SDLC approach that was
used for software development.
 This means that any phase in the development process
begins only if the previous phase is complete.
Waterfall model (cont’d)
 Waterfall phases

 The sequential phases in Waterfall model are −

o Requirement Gathering and analysis − All possible
requirements of the system to be developed are captured in
this phase and documented in a requirement specification
document.

o System Design − The requirement specifications from first

phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware
and system requirements and helps in defining the overall
system architecture.
 Waterfall phases (cont’d)

 The sequential phases in Waterfall model are −

o Implementation − With inputs from the system design, the
system is first developed in small programs called units,
which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to
as Unit Testing.

o Integration and Testing − All the units developed in the

implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Waterfall phases (cont’d)

 The sequential phases in Waterfall model are −

o Deployment of system − Once the functional and non-
functional testing is done; the product is deployed in the
customer environment or released into the market.

o Maintenance − There are some issues which come up in

the client environment. To fix those issues, patches are
released. Also to enhance the product some better versions
are released. Maintenance is done to deliver these changes
in the customer environment.
 Prototyping model

 Prototype is a working model of software with some limited

functionality.
 The prototype does not always hold the exact logic used in
the actual software application and is an extra effort to be
considered under effort estimation.
 Prototyping is used to allow the users evaluate developer
proposals and try them out before implementation.
 It also helps understand the requirements which are user
specific and may not have been considered by the developer
during product design.
 Prototyping - Steps

 Following is a stepwise approach explained to design a

software prototype:
1. Developing the initial Prototype
• The initial Prototype is developed in this stage, where the very
basic requirements are showcased and user interfaces are
provided.
• These features may not exactly work in the same manner
internally in the actual software developed.
• While, the workarounds are used to give the same look and feel
to the customer in the prototype developed.
 Prototyping – Steps (cont’d)

 Following is a stepwise approach explained to design a

software prototype:
2. Review of the Prototype
• The prototype developed is then presented to the customer and
the other important stakeholders in the project.
• The feedback is collected in an organized manner and used for
further enhancements in the product under development.
 Prototyping – Steps (cont’d)

 Following is a stepwise approach explained to design a

software prototype:
3. Revise and Enhance the Prototype
• The feedback and the review comments are discussed during
this stage and some negotiations happen with the customer
based on factors like – time and budget constraints and
technical feasibility of the actual implementation.
• The changes accepted are again incorporated in the new
Prototype developed and the cycle repeats until the customer
expectations are met.
 Prototyping - Types

 There are different types of software prototypes used in the

industry. Following are the major software prototyping types
used widely:
o Throwaway/Rapid Prototyping
• Throwaway prototyping is also called as rapid or close ended
prototyping.
• This type of prototyping uses very little efforts with minimum
requirement analysis to build a prototype.
• Once the actual requirements are understood, the prototype is
discarded and the actual system is developed with a much clear
understanding of user requirements.
 Prototyping – Types (cont’d)
o Evolutionary Prototyping
• Evolutionary prototyping also called as breadboard prototyping
is based on building actual functional prototypes with minimal
functionality in the beginning.
• The prototype developed forms the heart of the future
prototypes on top of which the entire system is built.
• By using evolutionary prototyping, the well-understood
requirements are included in the prototype and the requirements
are added as and when they are understood.
 Prototyping – Types (cont’d)
o Incremental Prototyping
• Incremental prototyping refers to building multiple functional
prototypes of the various sub-systems and then integrating all
the available prototypes to form a complete system.

o Extreme Prototyping
• Extreme prototyping is used in the web development domain. It
consists of three sequential phases.
• First, a basic prototype with all the existing pages is presented
in the HTML format.
• Then the data processing is simulated using a prototype
services layer.
• Finally, the services are implemented and integrated to the final
prototype.
 RAD model

 The RAD (Rapid Application Development) model is

based on prototyping and iterative development with no
specific planning involved.
 The process of writing the software itself involves the
planning required for developing the product.
 Rapid Application Development focuses on gathering
customer requirements through workshops or focus groups,
early testing of the prototypes by the customer using
iterative concept, reuse of the existing prototypes
(components), continuous integration and rapid delivery.
 RAD model (cont’d)

 Rapid application development is a software development

methodology that uses minimal planning in favor of rapid
prototyping.
 A prototype is a working model that is functionally equivalent
to a component of the product.
 In the RAD model, the functional modules are developed in
parallel as prototypes and are integrated to make the
complete product for faster product delivery.
 Since there is no detailed preplanning, it makes it easier to
incorporate the changes within the development process.
 RAD model (cont’d)

 RAD projects follow iterative and incremental model and

have small teams comprising of developers, domain experts,
customer representatives and other IT resources working
progressively on their component or prototype.
 The most important aspect for this model to be successful is
to make sure that the prototypes developed are reusable.
 RAD phases

 Following are the various phases of the RAD Model −

o Business Modeling
• The business model for the product under development is
designed in terms of flow of information and the distribution of
information between various business channels.
• A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and when
is the information processed and what are the factors driving
successful flow of information.
 RAD phases (cont’d)
o Data Modeling
• The information gathered in the Business Modeling phase is
reviewed and analyzed to form sets of data objects vital for the
business.
• The attributes of all data sets is identified and defined. The
relation between these data objects are established and defined
in detail in relevance to the business model.

o Process Modeling
• The data object sets defined in the Data Modeling phase are
converted to establish the business information flow needed to
achieve specific business objectives as per the business model.
• The process model for any changes or enhancements to the
data object sets is defined in this phase. Process descriptions
for adding, deleting, retrieving or modifying a data object are
given.
 Spiral Model

 The spiral model combines the idea of iterative development

with the systematic, controlled aspects of the waterfall
model.
 This Spiral model is a combination of iterative development
process model and sequential linear development model i.e.
the waterfall model with a very high emphasis on risk
analysis.
 It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.
 Spiral phases

 The spiral model has four phases. A software project

repeatedly passes through these phases in iterations called
Spirals.
o Identification
• This phase starts with gathering the business requirements in
the baseline spiral. In the subsequent spirals as the product
matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase.
• This phase also includes understanding the system
requirements by continuous communication between the
customer and the system analyst. At the end of the spiral, the
product is deployed in the identified market.
 Spiral phases (cont’d)
o Design
• The Design phase starts with the conceptual design in the
baseline spiral and involves architectural design, logical design
of modules, physical product design and the final design in the
subsequent spirals.

o Construct or Build
• The Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral, when the product
is just thought of and the design is being developed a POC
(Proof of Concept) is developed in this phase to get customer
feedback.
• Then in the subsequent spirals with higher clarity on
requirements and design details a working model of the
software called build is produced with a version number. These
builds are sent to the customer for feedback.
 Spiral phases (cont’d)
o Evaluation and Risk Analysis
• Risk Analysis includes identifying, estimating and monitoring the
technical feasibility and management risks, such as schedule
slippage and cost overrun.
• After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
Spiral phases (cont’d)
 Agile Model

 Agile SDLC model is a combination of iterative and

incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of
working software product.

 Agile Methods break the product into small incremental

builds. These builds are provided in iterations. Each iteration
typically lasts from about one to three weeks.
 Agile Model (cont’d)

 Every iteration involves cross functional teams working

simultaneously on various areas like −
o Planning
o Requirements Analysis
o Design
o Coding
o Unit Testing and
o Acceptance Testing.

 At the end of the iteration, a working product is displayed to

the customer and important stakeholders.
 Agile Model (cont’d)

 Agile model believes that every project needs to be handled

differently and the existing methods need to be tailored to
best suit the project requirements.
 In Agile, the tasks are divided to time boxes (small time
frames) to deliver specific features for a release.
 Iterative approach is taken and working software build is
delivered after each iteration.
 Each build is incremental in terms of features; the final build
holds all the features required by the customer.
Agile Model (cont’d)
 DSDM

 The Dynamic Systems Development Method (DSDM) is an

agile project delivery framework, primarily used as a
software development method.
 It is a framework which embodies much of the current
knowledge about project management.
 DSDM is rooted in the software development community, but
the convergence of software development, process
engineering and hence business development projects has
changed the DSDM framework to become a general
framework for complex problem solving tasks.
 The DSDM framework can be implemented for agile and
traditional development processes.
 DSDM (cont’d)

 DSDM is a,
o Straight forward framework based on best principles to start
implementing a project structure.
o Simple
o Extendible
o But not calming to be the solution to all kind of projects.
 DSDM (cont’d)

 Why use DSDM?

o Results of development are directly and promptly visible
o Since the users are actively involved in the development
of the system, they are more likely to embrace it and take
it on.
o Basic functionality is delivered quickly, with more
functionality being delivered at regular intervals.
o Eliminates bureaucracy and breaks down the
communication barrier between interested parties.
 DSDM (cont’d)
o Because of constant feedback from the users, the system
being developed is more likely to meet the need it was
commissioned for.
o Early indicators of whether project will work or not, rather
than a nasty surprise halfway through the development
o System is delivered on time and on budget.
o Ability of the users to affect the project's direction.
DSDM (cont’d)
 DSDM (cont’d)

 There are 9 principles which are essential to any DSDM

implementation, ignoring one of them will break with the
frameworks philosophy and significantly increase project
risks.
1) Active user involvement – Imperative.
2) Teams must be empowered to make decisions.
3) Focus on frequent delivery.
4) Criterion for accepted deliverable (Fitness for Business).
5) Iterative and incremental development – Mandatory.
6) All changes during development must be reversible.
7) Requirements are base lined at high level.
8) Testing is integrated throughout the life cycle.
9) Collaborative and co-operative approach.
 Lifecycle stage and connectivity

 1. Feasibility Study
o The feasibility study is basically the test of the proposed
system in the light of its workability, meeting user’s
requirements, effective use of resources and of course, the
cost effectiveness.
o These are categorized as technical, operational,
economic, schedule and social feasibility.
o In the process of feasibility study, the cost and benefits are
estimated with greater accuracy to find the Return on
Investment (ROI).
o The result is a feasibility report submitted to the
management. This may be accepted or accepted with
modifications or rejected.
 Lifecycle stage and connectivity

 1. Feasibility Study (cont’d)

o In short, following decision are taken in different feasibility
study:
• Economic feasibility - The likely benefits outweigh the cost of
solving the problem which is generally demonstrated by a cost/
benefit analysis.
• Operational feasibility - Whether the problem can be solved in
the user’s environment with existing and proposed system
workings?
• Organizational feasibility – Whether the proposed system is
consistent with the organization’s strategic objectives?
• Technical feasibility - Whether the problem be solved using
existing technology and resources available?
• Social feasibility – Whether the problem be solved without
causing any social issues? Whether the system will be
acceptable to the society?
 Lifecycle stage and connectivity

 2. System Analysis
o Systems analysis is a process of collecting factual data,
understand the processes involved, identifying problems and
recommending feasible suggestions for improving the
system functioning.
o This involves studying the business processes, gathering
operational data, understand the information flow, finding out
bottlenecks and evolving solutions for overcoming the
weaknesses of the system so as to achieve the
organizational goals.
o System Analysis also includes subdividing of complex
process involving the entire system, identification of data
store and manual processes.
 Lifecycle stage and connectivity

 2. System Analysis (cont’d)

o The major objectives of systems analysis are to find answers
for each business process:
• What is being done?
• How is it being done?
• Who is doing it?
• When is he doing it? Why is it being done?
• How can it be improved?

o The result of this process is a logical system design.

o System analysis is an iterative process that continues until a
preferred and acceptable solution emerges.
 Lifecycle stage and connectivity

 3. System Design
o Based on the user requirements and the detailed analysis of
a new system, the new system must be designed.
o This is the phase of system designing. It is the most crucial
phase in the development of a system.
o The logical system design arrived at as a result of system
analysis and is converted into physical system design.
o In the design phase the SDLC process continues to move
from the what questions of the analysis phase to the how . 
 Lifecycle stage and connectivity

 3. System Design (cont’d)

o The logical design produced during the analysis is turned
into a physical design - a detailed description of what is
needed to solve original problem.
o Input, output, databases, forms, codification schemes and
processing specifications are drawn up in detail.
o In the design stage, the programming language and the
hardware and software platform in which the new system will
run are also decided.
o Interface, documentation, training, procedures of using the
system, taking backups and staffing requirement are
decided at this stage.
 Lifecycle stage and connectivity

 3. System Design (cont’d)

o There are several tools and techniques used for describing
the system design of the system.

o These tools and techniques are:

• Flowchart,
• Data flow diagram (DFD),
• Data dictionary,
• Structured English,
• Decision table and Decision tree.
 Lifecycle stage and connectivity

 4. Implementation (cont’d)
o The system design needs to be implemented to make it a
workable system.
o This is also called the programming phase in which the
programmer converts the program specifications into
computer instructions, which we refer to as programs.
o It is an important stage where the defined procedures are
transformed into control specifications by the help of a
computer language.
o A well written code reduces the testing and maintenance
effort. The right programming language should be chosen.
 Lifecycle stage and connectivity

 5. Testing
o Before actually implementing the new system into
operations, a test run of the system is done removing all the
bugs, if any.
o It is an important phase of a successful system. After
codifying the whole programs of the system, a test plan
should be developed and run on a given set of test data.
o The output of the test run should match the expected results.
 Lifecycle stage and connectivity

 5. Testing (cont’d)
o Using the test data following test run are carried out:
• Program test :
– When the programs have been coded and compiled and
brought to working conditions, they must be individually
tested with the prepared test data.
– All verification and validation be checked and any
undesirable happening must be noted and debugged (error
corrected).
 Lifecycle stage and connectivity

 5. Testing (cont’d)
o Using the test data following test run are carried out:
• System Test : 
– After carrying out the program test for each of the programs
of the system and errors removed, then system test is done.
– At this stage the test is done on actual data. The complete
system is executed on the actual data.
– At each stage of the execution, the results or output of the
system is analyzed.
– During the result analysis, it may be found that the outputs
are not matching the expected output of the system.
– In such case, the errors in the particular programs are
identified and are fixed and further tested for the expected
output.
 Lifecycle stage and connectivity

 6. Implementation
o After having the user acceptance of the new system
developed, the implementation phase begins.

o Implementation is the stage of a project during which theory

is turned into practice.

o The major steps involved in this phase are:

• Acquisition and Installation of Hardware and Software
• Conversion
• User Training
• Documentation
 Lifecycle stage and connectivity

 6. Implementation (cont’d)
o The hardware and the relevant software required for running
the system must be made fully operational before
implementation.
o The conversion is also one of the most critical and
expensive activities in the system development life cycle.
o The data from the old system needs to be converted to
operate in the new format of the new system. The database
needs to be setup with security and recovery procedures
fully defined.
o During this phase, all the programs of the system are loaded
onto the user’s computer.
o After loading the system, training of the user starts.
 Lifecycle stage and connectivity

 6. Implementation (cont’d)
o After the users are trained about the computerized system,
working has to shift from manual to computerized working.
The process is called Changeover.
o The following strategies are followed for changeover of the
system.
• Direct Changeover: This is the complete replacement of the
old system by the new system. It is a risky approach and
requires comprehensive system testing and training.
• Parallel run : In parallel run both the systems, i.e.,
computerized and manual, are executed simultaneously for
certain defined period. The same data is processed by both the
systems. This strategy is less risky but more expensive because
of the following facts:
 Lifecycle stage and connectivity

 6. Implementation (cont’d)
• Pilot run: In this type of run, the new system is run with the
data from one or more of the previous periods for the whole or
part of the system. The results are compared with the old
system results. It is less expensive and risky than parallel run
approach. This strategy builds the confidence and the errors are
traced easily without affecting the operations.
 Lifecycle stage and connectivity

 6. Implementation (cont’d)
o The documentation of the system is also one of the most
important activity in the system development life cycle. This
ensures the continuity of the system. Generally following two
types of documentations are prepared for any system.

• User Documentation: The user documentation is a complete

description of the system from the user’s point of view detailing
how to use or operate the system.

• System Documentation: The system documentation contains

the details of system design, programs, their coding, system
flow, data dictionary, process description, etc. This helps to
understand the system and permit changes to be made in the
existing system to satisfy new user needs.
 Lifecycle stage and connectivity

 7. Maintenance
o Maintenance is necessary to eliminate errors in the system
during its working life and to tune the system to any
variations in its working environments.
o It must meet the scope of any future enhancement, future
functionality and any other added functional features to cope
up with the latest future needs.
o It has been seen that there are always some errors found in
the systems that must be noted and corrected. It also means
the review of the system from time to time.
 Lifecycle stage and connectivity

 7. Maintenance (cont’d)
o The review of the system is done for:
• knowing the full capabilities of the system
• knowing the required changes or the additional requirements
• studying the performance.

 If a major change to a system is needed, a new project may

have to be set up to carry out the change. The new project
will then proceed through all the above life cycle phases.
 Lifecycle stage and connectivity

 Requirement Traceability
o Refers to the ability to describe and follow the life of a
requirement, in both forwards and backwards direction
• (i.e. from its origins, through its development and
specification, to its subsequent deployment and use, and
through all periods of on-going refinement and iteration in
any of these phases.)

o The concept is quite simple, really – it’s a way to tie

everything together from start to finish, and make sure that
end products align with originating goals and objectives.
 Lifecycle stage and connectivity

 Requirement Traceability (cont’d)

o Performing a requirements traceability analysis is an
important part of the software engineering process as it
ensures that all of the requirements have been adequately
considered during each phase of the project, and that there
aren't any scope 'holes' in the developed system due to
missed requirements.

o The activity also ensures that all of the requirements are

internally consistent with each other and support the
overarching business drivers, goals and objectives.
 Lifecycle stage and connectivity

 Requirement Traceability (cont’d)

o Forward Traceability
• This refers to the need to document the associations between
the functional and system requirements and the various artifacts
created during the design, development and testing of the
system.

o Backwards / Reverse Traceability

• This refers to the need to document the lineage and source of
all the requirements defined in the 
System Requirements Specification (SRS). Requirements come
from many different sources (written list from the customer
representative, interviews with stakeholders, discussions with
developers, workshop deliverables, focus groups of end-users,
etc.).
 Test and integration

 Building test environments;

o A testing environment is a setup of software and hardware
on which the testing team is going to perform the testing of
the newly built software product.
o This setup consists of the physical setup which includes
hardware, and logical setup that includes Server Operating
system, client operating system, database server, front end
running environment, browser (if web application), IIS
(version on server side) or any other software components
required to run this software product.
o This testing setup is to be built on both the ends – i.e. the
server and client.
 Test and integration

 Here let us try to understand five essentials to be adhered to

while building a test environment for software testing:
o 1. Customer’s Environments: 
• Understand clearly the environment in which the
customer is going to run this software.
• This has to be checked not only for server but also for
the user’s machines.
• The environments factors could be the hardware, OS,
Database, Front end tools, browsers etc.
• Take care of all the versions of OS, browser the
customer machines that are going to run this
application.
 Test and integration
o 2. Test Server:
• Build your test environment as much as possible a
replica of customer environment. This is to be
applicable to Server and client machines as well.

o 3. Separate Test Server:

• Build the test environment on a separate server free
from development and dedicated exclusively for testing
purposes.
 Test and integration
o 4. Understand business requirements well:
• The testers and test lead should be very much clear
about the customer requirements based on which the
test cases are to be built. More understanding, more
coverage. Much clearer understanding, wider coverage.

5. Documentation: 
• Aesthetically document each and every test that the
testers perform for a unit, module or integration testing
of the product.
 Test and integration

 What is Test Harness?

o Test harness enables the automation of tests. It refers to the
system test drivers and other supporting tools that requires
to execute tests.
o It provides stubs and drivers which are small programs that
interact with the software under test.
o Test harness execute tests, by using a test library and
generates a report.
o It requires that your test scripts are designed to handle
different test scenarios and test data.
Test and integration
 Test and integration

 Why use Test Harness?

o Automate the testing process
o Execute test suites of test cases
o Generate associated test reports
o Support for debugging
o To record the test results for each one of the tests
o Helps the developers to measure code coverage at code
level
o Increase the productivity of the system thorough automation
o Enhance the quality of software components and application
o To handle the complex condition that testers are finding
difficult to simulate
 Test and integration

 There are two context where Test Harness is used

o Automation testing: It contains the test scripts, parameters
necessary to run these scripts and gather results to analyze
it
o Integration testing: It is used to put together two units of
code or module that interact with each other to check
whether or not the combined behavior is as expected or not

 Test Harness Tools

o Junit: Tool used while using Java
o Nunit: Tool used for using .Net framework
 Test and integration

 Black Box Testing

o BLACK BOX TESTING, also known as Behavioral Testing,
is a software testing method in which the internal
structure/design/implementation of the item being tested is
not known to the tester. These tests can be functional or
non-functional, though usually functional.
 Test and integration

 Black Box Testing

o This method is named so because the software program, in
the eyes of the tester, is like a black box; inside which one
cannot see. 

o This method attempts to find errors in the following

categories:
• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors
 Test and integration

 White Box Testing

o Also known as Clear Box Testing, Open Box Testing, Glass
Box Testing, Transparent Box Testing, Code-Based Testing
or Structural Testing)
o Is a software testing method in which the internal
structure/design/implementation of the item being tested is
known to the tester.
o The tester chooses inputs to exercise paths through the
code and determines the appropriate outputs.
 Test and integration

 White Box Testing

o This method is named so because the software program, in
the eyes of the tester, is like a white/transparent box; inside
which one clearly sees.
 Test and integration

 What is Incremental Testing?

o Incremental testing is a way of integration testing. In this
type of testing method, you first test each module of the
software individually and then continue testing by appending
other module to it then another and so on.

o Incremental integration is the contrast of the big bang

approach. The program is constructed and tested in small
segments, where errors are easier to isolate and correct.
Interfaces are more likely to be tested completely, and a
systematic test approach may be applied.
 Test and integration

 There are two types of Incremental testing

o Top down approach
• In this type of approach, individual start by testing only the user
interface, with the underlying functionality simulated by stubs,
then you move downwards integrating lower and lower layers as
shown in the image below.

o Bottom down approach

• Bottom-up integration begins construction and testing with
modules at the lowest level in the program structure. In this
process, the modules are integrated from the bottom to the top.
• In this approach processing required for the modules
subordinate to a given level is always available and the need for
the stubs is eliminated.
 Test and integration

 Acceptance Testing
o Is a level of software testing where a system is tested for
acceptability. The purpose of this test is to evaluate the
system’s compliance with the business requirements and
assess whether it is acceptable for delivery
o Formal testing with respect to user needs, requirements, and
business processes conducted to determine whether or not
a system satisfies the acceptance criteria and to enable the
user, customers or other authorized entity to determine
whether or not to accept the system..
 Test and integration

 Changeover strategies
o System changeover is concerned with the smooth shift from
one way of doing things to another and the mitigation of
disruption to business activities during the changeover.

o There are three main methods used:

• phased implementation,
• direct changeover
• parallel running.
 Test and integration

 Phased implementation: 
o A staged method whereby one part of the overall system
that need changing is changed. If any problems arise,
they are limited in scope and therefore non-critical.
o Once the system has been successfully changed in one
area, the other areas can follow suit, with any lessons
learned during the initial changeover used to ensure the
success of the changeover as a whole.
 Test and integration

 Parallel running: 
o Both the old and the new systems run side-by-side, using
live data, so that project managers can compare the
efficiency and reliability of the new system.
o Once they’re satisfied, the old system is taken offline and
the new system becomes fully active and utilised across
the organisation.
 Test and integration

 Direct changeover: 
o there’s a single, fixed point where one system stops
being used and the new one becomes live.
o This is the cheapest, quickest and easiest form of
system changeover but is also the riskiest – if the
system is broken or inefficient, the whole
organisation suffers.
 Test and integration

 Go-Live prerequisites
o The following 10 points should be part of your readiness
assessment before management gives its blessing to
convert and go live:

• Modification process: All testing of modifications need

to be done first by IT and then by department
management.

• Testing: Complete end-to-end testing and conference

room pilot testing from origination of orders, returns,
receipts and shipping through to systems processes.
 Test and integration
• File conversion: Have the necessary files been successfully
converted on a test basis and visually spot checked to the files
on the current system

• More testing: Do volume testing with website and call center

phone orders to get a feel for how the system will respond when
processing actual transaction volumes.

• Check the interfaces: Have you tested all the interfaces with

vendors, ASN and EDI services, marketing services, credit
processors, etc.?

• Training: Have all the employees in various departments been

trained? Are new standard operating procedures in place?
 Test and integration
• IT readiness: Is IT ready to support the company with
knowledge of the daily processes, and is all equipment installed
in IT and user departments?

• Who does what: Have agreement on the conversion process

and everyone’s go live responsibilities.

• OK from the top: Senior management and department

management should sign off only after they’ve reviewed their
respective processes and testing results and agree that all
critical processes are ready.
 Test and integration
• Allow critical feedback from the rank and file: Most
importantly, create an open communication environment where
your employees are empowered and have the courage to say,
“No, we’re not ready.”

 For sure, there is intense pressure when you miss a go live

date, as this means incurring additional project costs and
taxing limited resources.

 But the situation becomes much worse when the switch is

flipped before you’re ready, in the process risking the
company’s profitability, reputation and customer
relationships.
 References
 https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
 https://www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm
 https://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm
 https://www.tutorialspoint.com/sdlc/sdlc_spiral_model.htm
 https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm
 http://www.selectbs.com/process-maturity/what-is-dsdm
 http://infolab.stanford.edu/~burback/watersluice/node4.html
 https://www.umsl.edu/~sauterv/analysis/F08papers/Katimuneetorn_Feas
ibility_Study.html
 http://oer.nios.ac.in/wiki/index.php/Phases_of_System_Development_Lif
e_Cycle
 https://www.inflectra.com/ideas/topic/requirements-traceability.aspx
 References
 http://itknowledgeexchange.techtarget.com/quality-assurance/5-essential
s-while-building-test-environment-for-software-testing
/
 https://www.guru99.com/what-is-test-harness-comparison.html
 http://softwaretestingfundamentals.com/black-box-testing/
 http://softwaretestingfundamentals.com/white-box-testing/
 http://hackingig.com/what-is-incremental-testing/
 http://softwaretestingfundamentals.com/acceptance-testing/
 http://multichannelmerchant.com/blog/assess-true-readiness-system-go-l
ive-date
/