Stage 2: Defining Requirements

Stage 3: Designing the Product Architecture

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate the
code. Different high level programming languages such as C, C++, Pascal, Java and PHP are
used for coding. The programming language is chosen with respect to the type of software
being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the
testing only stage of the product where product defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of
that organization. The product may first be released in a limited segment and tested in the
real business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the market,
its maintenance is done for the existing customer base.

2
SDLC framework includes the following steps:

Communication
This is the first step where the user initiates the request for a desired software product. He
contacts

the service provider and tries to negotiate the terms. He submits his request to the service

providing organization in writing.

Feasibility Study

After requirement gathering, the team comes up with a rough plan of software process. At
this step

the team analyzes if a software can be made to fulfill all requirements of the user and if there
is

any possibility of software being no more useful. It is found out, if the project is financially,

practically and technologically feasible for the organization to take up. There are many
algorithms

available, which help the developers to conclude the feasibility of a software project.

System Analysis

Software Design

Coding

This step is also known as programming phase. The implementation of software design starts
in

terms of writing program code in the suitable programming language and developing error-
free

executable programs efficiently.

Testing

An estimate says that 50% of whole software development process should be tested. Errors
may

ruin the software from critical level to its own removal. Software testing is done while coding
by the

developers and thorough testing is conducted by testing experts at various levels of code such
as

module testing, program testing, product testing, in-house testing and testing the product at
user’s

end. Early discovery of errors and their remedy is the key to reliable software.
Integration

Software may need to be integrated with the libraries, databases and other programs. This
stage of

SDLC is involved in the integration of software with outer world entities.

Implementation

This means installing the software on user machines. At times, software needs post-
installation

configurations at user end. Software is tested for portability and adaptability and integration

related issues are solved during implementation.

Operation and Maintenance

This phase confirms the software operation in terms of more efficiency and less errors. If
required,

the users are trained on, or aided with the documentation on how to operate the software and
how

to keep the software operational. The software is maintained timely by updating the code

according to the changes taking place in user end environment or technology. This phase may

face challenges from hidden bugs and real-world unidentified problems.

Disposition

As time elapses, the software may decline on the performance front. It may go completely

obsolete or may need intense upgradation. Hence a pressing need to eliminate a major portion
of

the system arises. This phase includes archiving data and required software components,
closing

down the system, planning disposition activity and terminating system at appropriate end-of

3
SDLC has defined its phases as, Requirement gathering, Designing, Coding, Testing, and
Maintenance. It is important to adhere to the phases to provide the Product in a systematic
manner.
For Example, A software has to be developed and a team is divided to work on a feature of the
product and is allowed to work as they want. One of the developers decides to design first
whereas the other decides to code first and the other on the documentation part.
This will lead to project failure because of which it is necessary to have a good knowledge and
understanding among the team members to deliver an expected product.

SDLC Cycle
SDLC Cycle represents the process of developing software.

Below is the diagrammatic representation of the SDLC cycle:

SDLC Phases
Given below are the various phases:
 Requirement gathering and analysis
 Design
 Implementation or coding
 Testing
 Deployment
 Maintenance
#1) Requirement Gathering and Analysis
For Example, A customer wants to have an application which involves money transactions. In
this case, the requirement has to be clear like what kind of transactions will be done, how it will
be done, in which currency it will be done, etc.
Once the requirement gathering is done, an analysis is done to check the feasibility of the
development of a product. In case of any ambiguity, a call is set up for further discussion.

#2) Design
#3) Implementation or Coding
Implementation/Coding starts once the developer gets the Design document. The Software design
is translated into source code. All the components of the software are implemented in this phase.

#4) Testing
Testing starts once the coding is complete and the modules are released for testing. In this phase,
the developed software is tested thoroughly and any defects found are assigned to developers to
get them fixed.

Retesting, regression testing is done until the point at which the software is as per the customer’s
expectation. Testers refer SRS document to make sure that the software is as per the customer’s
standard.

#5) Deployment
Once the product is tested, it is deployed in the production environment or first UAT (User
Acceptance testing) is done depending on the customer expectation.
In the case of UAT, a replica of the production environment is created and the customer along
with the developers does the testing. If the customer finds the application as expected, then sign
off is provided by the customer to go live.
#6) Maintenance
After the deployment of a product on the production environment, maintenance of the product i.e.
if any issue comes up and needs to be fixed or any enhancement is to be done is taken care by the
developers.

4
The Seven Phases of the SDLC
Click here to jump to the 7 Phases of the SDLC infographic.

These steps are (very) roughly the same from one methodology to another. They tend to
occur in this order, though they can also be mixed together, such that several steps occur in
parallel.

As we’ll discuss later, Agile methods tend to “wind together” all of these steps into a tight,
rapidly-repeating cycle. Waterfall methods tend to take each of these steps in turn. Outputs
from one become inputs to the following step.

1. Planning

2. Requirements

3. Design and prototyping

4. Software development

This phase produces the software under development. Depending on the methodology, this
phase may be conducted in time-boxed “sprints,” (Agile) or may proceed as a single block of
effort (Waterfall.) Regardless of methodology, development teams should produce working
software as quickly as possible. Business stakeholders should be engaged regularly, to ensure
that their expectations are being met. The output of this phase is testable, functional software.
5. Testing

The testing phase of the SDLC is arguably one of the most important. It is impossible to
deliver quality software without testing. There is a wide variety of testing necessary to
measure quality:

 Code quality
 Unit testing (functional tests)
 Integration testing
 Performance testing
 Security testing

The best way to ensure that tests are run regularly, and never skipped for expediency, is
to automate them. Tests can be automated using Continuous Integration tools, like Codeship,
for example. The output of the testing phase is functional software, ready for deployment to a
production environment.

6. Deployment

The deployment phase is, ideally, a highly automated phase. In high-maturity enterprises, this
phase is almost invisible; software is deployed the instant it is ready. Enterprises with lower
maturity, or in some highly regulated industries, the process involves some manual approvals.
However, even in those cases it is best for the deployment itself to be fully automated in
a continuous deployment model. Application Release Automation (ARA) tools are used in
medium and large-size enterprises to automate the deployment of applications to Production
environments. ARA systems are usually integrated with Continuous Integration tools. The
output of this phase is the release to Production of working software.

7. Operations and maintenance

The operations and maintenance phase is the “end of the beginning,” so to speak. The
Software Development Life Cycle doesn’t end here. Software must be monitored constantly
to ensure proper operation. Bugs and defects discovered in Production must be reported and
responded to, which often feeds work back into the process. Bug fixes may not flow through
the entire cycle, however, at least an abbreviated process is necessary to ensure that the fix
does not introduce other problems (known as a regression.)

Conclusion
All software begins as a concept, and flows through a series of phases until a release is
developed and deployed. The Software Development Life Cycle of an application or system
continues, with updates and new features, until the day it is decommissioned or replaced.
Several methods for software development have evolved over the decades.

Waterfall methods are still common, though Agile is rapidly overtaking it in companies large
and small. Whichever method you choose, use the right tools for the job. Software is difficult
to delivery reliably without them. There is no perfect method, but it’s far better to use some
method than none.

Related links:

Software intelligence

Software development tools

Solving software errors

5
SDLC Overview

CHAPTER

TUTORIALS POINT

Simply Easy Learning Page 2

The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development life cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis :

Stage 2: Defining Requirements : Once the requirement analysis is done the next step is to

clearly define and document the product requirements and get them approved from the

customer or the market analysts. This is done through ‘SRS’ – Software Requirement

Specification document which consists of all the product requirements to be designed and

developed during the project life cycle.

Stage 3: Designing the product architecture : SRS is the reference for product architects to

come out with the best architecture for the product to be developed. Based on the
requirements specified in SRS, usually more than one design approach for the product

architecture is proposed and documented in a DDS - Design Document Specification. This

DDS

is reviewed by all the important stakeholders and based on various parameters as risk

TUTORIALS POINT

Simply Easy Learning Page 3

assessment, product robustness, design modularity , budget and time constraints , the best

design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with its

communication and data flow representation with the external and third party modules (if

any). The internal design of all the modules of the proposed architecture should be clearly

defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

Stage 5: Testing the Product : This stage is usually a subset of all the stages as in the modern

SDLC models, the testing activities are mostly involved in all the stages of SDLC. However
this

stage refers to the testing only stage of the product where products defects are reported,

tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance : Once the product is tested and ready

to be deployed it is released formally in the appropriate market. Sometime product

deployment happens in stages as per the organizations’ business strategy. The product may

first be released in a limited segment and tested in the real business environment (UAT- User

acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested

enhancements in the targeting market segment. After the product is released in the market,

its maintenance is done for the existing customer base.

6
 Share this infographic on your site

Following are the seven phases of the SDLC

1. Planning
2. Systems Analysis and Requirements
3. Systems Design
.

4. Development
The fourth phase is when the real work begins—in particular, when a programmer, network
engineer and/or database developer are brought on to do the major work on the project. This work
includes using a flow chart to ensure that the process of the system is properly organized. The
development phase marks the end of the initial section of the process. Additionally, this phase
signifies the start of production. The development stage is also characterized by instillation and
change. Focusing on training can be a huge benefit during this phase.

5. Integration and Testing

The fifth phase involves systems integration and system testing (of programs and procedures)—
normally carried out by a Quality Assurance (QA) professional—to determine if the proposed
design meets the initial set of business goals. Testing may be repeated, specifically to check for
errors, bugs and interoperability. This testing will be performed until the end user finds it
acceptable. Another part of this phase is verification and validation, both of which will help
ensure the program"s successful completion.

6. Implementation
The sixth phase is when the majority of the code for the program is written. Additionally, this
phase involves the actual installation of the newly-developed system. This step puts the project
into production by moving the data and components from the old system and placing them in the
new system via a direct cutover. While this can be a risky (and complicated) move, the cutover
typically happens during off-peak hours, thus minimizing the risk. Both system analysts and end-
users should now see the realization of the project that has implemented changes.

7. Operations and Maintenance

The seventh and final phase involves maintenance and regular required updates. This step is when
end users can fine-tune the system, if they wish, to boost performance, add new capabilities or
meet additional user requirements.

8
There are currently many different methodologies employed for system development projects within
New York State agencies. Many methodologies are

driven by the application development tools, by the software architecture

within which the application will operate, or by the “build versus buy” decision. There are standard
phases and processes, however, that all system

development projects should follow, regardless of environment and tools. This

section describes the standard phases and major processes of the New York

State System Development Lifecycle (SDLC), using a common language and

in sufficient detail to enable a Project Manager to plan and manage a system

development project.

System Development Lifecycle Overview

The material in this section is organized according to a generic system development lifecycle. While
no two development efforts are exactly alike, all projects should progress through the same six
phases:

1. System Initiation

2.

3. System Design

4. System Construction – throughout which the Project Team builds and

tests the various modules of the application, including any utilities that

will be needed during System Acceptance and System Implementation.

As system components are built, they will be tested both individually and
in logically related and integrated groupings until such time as a full system test has been performed
to validate functionality. Documentation

and training materials are also developed during this phase.

5. System Acceptance – during which the focus of system validation

efforts shifts from those team members responsible for developing the

application to those who will ultimately use the system in the execution

of their daily responsibilities. In addition to confirming that the system

meets functional expectations, activities are aimed at validating all

aspects of data conversion and system deployment.

6. System Implementation – the final phase of the lifecycle, which comprises all activities associated
with the deployment of the application.

These efforts include training, installation of the system in a production

setting, and transition of ownership of the application from the Project

Team to the Performing Organization.

9
The SDLC Phases

Michigan Tech’s SDLC includes six phases, during which defined work
products and documents are

created, reviewed, refined, and approved. Not every project will require that
the phases be

subsequently executed and may be tailored to accommodate the

unique aspects of a projects. These

phases are described in more detail in the following paragraphs.

Initiation Phase

Feasibility Phase

Requirements Analysis Phase

Design Phase

.
Michigan Tech Information Technology

System Development Lifecycle Page 4

Implementation Phase

This phase is initiated after the system has been tested and
accepted by the user. In this phase, the

system is installed to support the intended business functions.

System performance is compared to

performance objectives established during the planning phase.

Implementation includes user

notification, user training, installation of hardware, installation of

software onto production

computers, and integration of the system into daily work processes.

This phase continues until the

system is operating in production in accordance with the

defined user requirements.

Operations and Maintenance

The system operation is ongoing. The system is monitored for

continued performance in accordance

with user requirements and needed system modifications are incorporated.

Operations continue as

long as the system responds to the organization’s needs. When

modifications are identified, the

system may reenter the planning phase.

10
4.2.2 Determine System Needs Phase

4.2.2.1 Purpose

The Determine System Need phase is the period in which an information system need is

identified and the decision is made whether to commit the necessary resources to solve the

deficiency.

4.2.2.2 Description

The activities of the Determine System Need Phase begin with the identification of an idea or a
need. A user or system sponsor may identify the need or it may be the result of a strategic

information architecture analysis. For a system which does not currently exist, the need is

documented in a Needs Statement (NS) document. For an existing system, the need is

documented in a Change Request (CR) document. These documents describe the need and

justify the exploration of alternative solutions.

Large-scale development and major system enhancements are described in the Needs Statement

by the project sponsoring organization and approved by the Investment Review Board. Smaller

development efforts, minor enhancements, or maintenance efforts are described in a CR and

approved at the group or division level Configuration Control Board (CCB). After the idea/need

has been documented, alternatives for solving the need are identified as necessary. Decisions are

made on whether or not to continue development of the need.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 21

Entry Process

After the Customer or Executive Sponsor has identified a need OR a CR has been submitted,

there are tasks associated with the approval of the need and the documentation of the

requirements to meet the needs.

Tasks

The activities are outlined in Appendix D.1

Exit Criteria

 A CR package has been approved for an existing system

 The Information Technology Investment Analysis Package has been submitted and approved

 Needs Statement and User Requirements Document have been approved and baselined for

both new and existing systems

 Approval by the appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as
outlined in Appendix D.1. Approvers must include the Executive Sponsor, CIO, Technical

Advisor, Business Program Manager or Business Project Manager as appropriate.

4.2.3 Define System Requirements Phase

4.2.3.1 Purpose

Entry Criteria:

 The program or project has been approved and funded

 Needs Statement and User Requirements Document have been approved and baselined for

the new or existing system

 Approval by appropriate approvers to exit the previous phase has been granted

Tasks

The activities are outlined in Appendix D.2

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 22

Exit Criteria

 The Project Plan, Quality Assurance Plan, Configuration Management Plan, Security Impact

Analysis and Test Plan (Unit & Integration) have been documented and placed under

configuration control

 The System Architecture, Software Requirements Specification, Data Specification, FIPS199,

Privacy Threshold Analysis/Privacy Impact Assessment, Requirements Traceability

Matrix and Training Plan have been approved and baselined

 The baselined requirements have been approved as meeting the acceptance criteria for this

cycle

 Approval by appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.2. Approvers must include the Technical Project Manager, Chief

Architect, Business Program Manager or Business Project Manager as appropriate.

A requirements management software tool may be used in the place of a manual matrix. In this

case, the tool would need to be updated in place of the manual matrix.
4.2.4 Design System Components Phase

4.2.4.1 Purpose

The objective of the Design System Components Phase is to transform the detailed, defined

requirements into complete, detailed specifications for the system to guide the work of the

Development Phase. The decisions made in this phase address in detail how the system will

meet the defined functional, physical, interface, and data requirements. Design Phase activities

may be conducted in an iterative fashion, producing first a general system design that

emphasizes the functional features of the system, then a more detailed system design that

expands the general design by providing all the technical detail.

4.2.4.2 Description

This procedure defines the steps required to develop the system design. It gives the user details

on what activities and steps should occur during this phase, which include developing the

Software Design Description, the Database Design Description, Information Systems Security

Plan, User Manual, and training materials. It describes the steps required to document and

baseline system design.

Entry Criteria:

 The Project Plan, Quality Assurance Plan, Configuration Management Plan, and Test Plan

(Unit & Integration) have been documented and placed under Configuration Management

(CM) control

 The System Architecture, Software Requirements Specification, Data Specification,

Requirements Traceability Matrix, IT Security Planning, and the Training Plan have been

approved and baselined

 The baselined requirements have been approved as meeting the acceptance criteria for this

cycle

 Approvals by appropriate approvers to exit the previous phase has been granted

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 23

Tasks

 The activities are outlined in Appendix D.3.

Exit Criteria:

 The Software Design Description document, Database Design Description document,

Information Systems Security Plan, User Manual, Requirements Traceability Matrix, and

Training Materials have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration) and Training Plan have been updated. (as

required)

 The baselined designs have been approved as meeting the acceptance criteria for this cycle.

 Approvals by appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.3. Approvers must include the Technical Project Manager, Business

Program Manager or Business Project Manager as appropriate.

A testing support tool may be used in the place of Test Plans (Unit & Integration). In this case,

the tool would need to be updated in place of the Test Plans.

4.2.5 Build System Components Phase

4.2.5.1 Purpose

The objective of the Build Phase is to transform the detailed, system design into complete coded

software units and eventually, into an integrated product for release. Each software unit and

subsequent integrated units are tested thoroughly. System documents that support installation

and operations are also developed in this phase.

4.2.5.2 Description

The Version Description Document, Operations Manual, Verification Validation & Test Plan,

and the Installation and Conversion Plan are created as a result of this phase. As software source

objects and system configuration items are completed, they are placed under configuration

control.

Entry Criteria:

 The Software Design Description document, Database Design Description document,

Information Systems Security Plan, User Manual, Requirements Traceability Matrix, and

Training Materials have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration) and Training Plan have been updated. (as

required)

 The baselined designs have been approved as meeting the acceptance criteria for this cycle

 Approvals by appropriate approvers to exit the previous phase has been granted

Tasks:

Follow the activities as detailed in Appendix D.4

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 24

Exit Criteria:

 Unit and integration testing has been conducted and results meet the acceptance criteria

 The Version Description Document, Verification Validation & Testing Plan, Installation &

Conversion Plan, Requirements Traceability Matrix and Operations Manual have been

approved and baselined

 The Project Plan, Test Plan (Unit & Integration), Training Plan and Training Materials have

been updated (as required)

 Approvals by appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.4. Approvers must include the Technical Project Manager, Business

Program Manager or Business Project Manager as appropriate.

4.2.6 Evaluate System Readiness Phase

4.2.6.1 Purpose

This objective of the Evaluate Phase is to ensure that the system as designed and built satisfies

the requirements of the user. Whenever possible, independent testers measure the system's

ability to perform the functions that are required by the customer and ensure an acceptable level

of quality and performance. Once the phase is complete, it will be evident whether or not the
system is ready for operation. This function shall be the responsibility of the system testers and

will be heavily supported by the user participants.

4.2.6.2 Description

The Verification, Validation & Testing Plan, Test Results & Evaluation Report, Installation &

Conversion Plan, User Manual, and Training Materials are updated, tested (if applicable), and

finalized in this phase. The Systems Assessment and Authorization package is created in this

phase. As work products are created they are placed under configuration control.

Entry Criteria:

 Unit and integration (including regression) testing has been conducted and results meet the

acceptance criteria

 The Verification, Validation, & Testing Plan, Installation & Conversion Plan, Requirements

Traceability Matrix, and Operations Manual have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration), Training Plan, and Training Materials have

been updated. (as required)

 Technical Project Manager approval with Business Program Manager or Business Project

Manager concurrent approval to exit the previous phase has been granted

Tasks:

Follow the activities as detailed in Appendix D.5

Exit Criteria:

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 25

 The System Assessment and Authorization has been approved by the Authorizing Official

 The Customer, Business Program Manager or Business Project Manager and IT Project

Manager has approved the baselined testing results as meeting the acceptance criteria for this

cycle

 Business Program Manager or Business Project Manager, IT Project Manager, Software

Quality Assurance and the Customer have approved the Test Results and Evaluation Report,
Version Description Document, Installation & Conversion Plan, User Manual, updated

Requirements Traceability Matrix, and the applicable Training Materials

 The Project Plan has been updated to reflect activities of this phase and has been placed

under CM control

 The Phase Exit Review meeting has occurred and Technical Project Manager approval along

with IPT members, Business Program Manager or Business Project Manager concurrent

approval to proceed to the next phase has been granted as outlined in Appendix D.5.

4.2.7 Deploy the System Phase

4.2.7.1 Purpose

Deploy the System Phase is the final phase of the development life cycle, when the system is

released initially to a pilot site and then into the production environment. All necessary training

for using the system is accomplished.

4.2.7.2 Description

This phase is to install the system in a production environment for use by the intended user. The

production environment is prepared for system installation, which includes the physical

environment as well as hardware and software components. Once the system is installed, a

thorough test of the system installation is conducted. User training is also conducted to prepare

the user for new system functionality or system changes. The Business Program Manager or

Business Project Manager and Technical Project Manager verify that the installed system meets

all requirements, all specifications and all deliverables have been received.

Entry Criteria:

 Test Results & Evaluation Report, and Requirements Traceability Matrix have been

approved and baselined

 System Assessment and Authorization have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration), Training Plan, Training Materials, User

Manual, Installation & Conversion Plan, Operations Manual, Version Description Document

have been updated (as required)

 Established Service Level Agreements (SLA) or Operating Level Agreements (OLA) for the
project have been signed by all parties and ready for implementation

 Technical Project Manager approval along with IPT members, Business Program Manager or

Business Project Manager concurrent approval to exit the previous phase and deploy the

system has been granted.

Tasks:

Follow the activities as detailed in Appendix D.6

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 26

Exit Criteria:

 System has been installed and is operational

 System Sign-off Package has been approved by Technical Project Manager approval along

with Business Program Manager or Business Project Manager concurrent approval

 Project Plan has been updated. (as required)

4.2.8 Decommission the System Phase

4.2.8.1 Purpose

The Decommissioning a System phase is the period in which a system is completely taken off

line, or a portion of a system’s functionality (due to duplication in another system) is removed.

This phase is conducted to retire a system.

4.2.8.2 Description

Once the decision to decommission a system has been made, the activities of the

Decommissioning a System Phase begin with the completion of the decommission form. This

form documents the information and coordination necessary to end the target systems life cycle.

The system is decommissioned following the steps in the Decommissioning procedure. Systems

that have interfaces to the targeted system are checked to verify the decommissioning does not

adversely affect them. As a result of the system being decommissioned, affected business

processes and policies are updated. Once the system has been decommissioned, a formal system

close out meeting is conducted.

Entry Criteria:

 User/Executive Sponsor has identified a need OR a CR has been submitted

 Business Program Manager or Business Project Manager approval as well as CIO approval to

decommission a system

Tasks:

Follow the activities as detailed in Appendix D.7

Exit Criteria:

 A system, or part of a system, is decommissioned.

 System components and artifacts have been archived or disposed of.

 Completed Decommission Form with input and approval from the IT Security Team and

approved by CIO and Business Program Manager or Business Project Manager.

 Affected/interfacing systems continue to operate.

 Meeting Minutes which document that all parties are aware of decommission requirements

11
4.2 Planning

4.4 Hardware and software requirements

The hardware and software requirements are as follow.

4.4.1 Hardware requirements

 Laptop, Pc

4.4.2 Software requirements

 Smart phone

 Bluetooth connection

 Visual Studio

 Firebase
4.5 Implementing

In this phase the data gathered in the first step is implemented by using the software
requirements to develop the Android App. After effective building the Android App needs
which are supposed to attain the main objective we move forward to final phase.

4.6 Analysis

This is the final phase, in this phase after being implement all the required data to
successfully build the Web App its need a conclusion to identify that project are built with the
right methodologies. Finally, in the Analysis phase the project is successfully completing its
functions as testing. In this project we are doing work on net that achieving the goal in
different way. In there is a built-in methodology that is widely in used for web application to
provide a very realistic opponent experience with best interface and platform. The
methodology that is being used in this project is Agile methodology.

Stage 2: Defining Requirements :

Stage 4: Stage 5: Testing the Product : This stage is usually a subset of all the stages as in the
modern SDLC models, the testing activities are mostly involved in all the stages of SDLC.
However this stage refers to the testing only stage of the product where products defects are
reported, tracked, fixed and retested, until the product reaches the quality standards defined in
the SRS.

Stage 6: Deployment in the Market and Maintenance : Once the product is tested and ready to
be deployed it is released formally in the appropriate market. Sometime product deployment
happens in stages as per the organizations’ business strategy. The product may first be
released in a limited segment and tested in the real business environment (UAT- User
acceptance testing). Then based on the feedback, the product may be released as it is or with
suggested enhancements in the targeting market segment. After the product is released in the
market, its maintenance is done for the existing customer base.