Describe steps in SDLC model with an example

The steps in SDLC model are listed as follows

System analysis:-
It is a set of activity in which the system analyst gathers the information requirements of
the users, analyses them systematically in the form of functionality of the application system, the
input data requirement and their sources the output data and their presentation requirements.
The system analyst gathers data about the performance expectations of the users such as
expected response time the total turn around time etc. the system analyst finally prepares a
document called as system requirement specification(SRS) which documents all the agreements
reached between the users and the system analyst.

System design:-
It involves preparing the blue print of the new software system. Taking the SRS as a base
to start with it prepares various diagrammatic representations of the logical and physical artifacts
to be developed during the software development stages to follow. The major artifacts include
data models, process models and presentation model. finally the system design is documented

Coding or Construction:-
This involves programming and testing individual programs on the basis of the design
document. The developers responsible for programming also creates text data sets for inputs and
verifies that the program generate the expected output for these inputs data sets the individual
program are also reviewed to ensure that they meet programming standard as expected by the
users. This is the only face where the conceptual system is first translated into a computer
executable program sources.

Testing:-
It is to demonstrate to the development team members that the software system works
exactly to meet the user expectation of information requirements as well as the performance
expectation . it involves planning the testing creating the text data executing text runs matching
the text results with the expected results, analyzing the differences fixing the bugs and testing the
bug fixing repeatedly until a satisfactory number of mismatches are removed.

Implementation:-
It involves installing the software system on the user computer system conducting user
trained on new software system data preparations parallel running and going live as core
activities. This is the stage where the software system is first transferred to the user’s premises
and the users get a chance to work on the new software system for the first time. Also it involves
the most important step of user acceptance testing which marks the technical and commercial
milestone of the software development project

Maintenance:-
It involves maintaining the software system always up to date to ensure that it is in the
line with current information requirements considering even the latest changes in the same. It
helps keep the software system up to date thereby ensuring the user’s high return on their
investment at operational level of the business. The developer analyses the changes in the light of
the latest changes in the design identifies the new changes in the system design, verify quickly
that it works as expected.

E.G :- the library management system done as the assignment.

Systems Development Life Cycle

Model of the Systems Development Life Cycle with the Maintenance bubble highlighted.
The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in
systems engineering, information systems and software engineering, is the process of creating or
altering systems, and the models and methodologies that people use to develop these systems.
The concept generally refers to computer or information systems.
In software engineering the SDLC concept underpins many kinds of software
development methodologies. These methodologies form the framework for planning and
controlling the creation of an information system: the software development process.

Overview

Systems and Development Life Cycle (SDLC) is a process used by a systems analyst to
develop an information system, including requirements, validation, training, and user
(stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds
customer expectations, reaches completion within time and cost estimates, works effectively and
efficiently in the current and planned Information Technology infrastructure, and is inexpensive
to maintain and cost-effective to enhance.
Computer systems are complex and often (especially with the recent rise of Service-
Oriented Architecture) link multiple traditional systems potentially supplied by different
software vendors. To manage this level of complexity, a number of SDLC models have been
created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and
"synchronize and stabilize".[citation needed]
SDLC models can be described along a spectrum of agile to iterative to sequential. Agile
methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid
changes along the development cycle. Iterative methodologies, such as Rational Unified Process
and Dynamic Systems Development Method, focus on limited project scopes and expanding or
improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models,
such as Waterfall, focus on complete and correct planning to guide large projects and risks to
successful and predictable results[citation needed]. Other models, such as Anamorphic Development,
tend to focus on a form of development that is guided by project scope and adaptive iterations of
feature development.
In project management a project can be defined both with a project life cycle (PLC) and
an SDLC, during which slightly different activities occur. According to Taylor (2004) "the
project life cycle encompasses all the activities of the project, while the systems development life
cycle focuses on realizing the product requirements".[3]

History
The systems development life cycle (SDLC) is a type of methodology used to describe
the process for building information systems, intended to develop information systems in a very
deliberate, structured and methodical way, reiterating each stage of the life cycle. The systems
development life cycle, according to Elliott & Strachan & Radford (2004), "originated in the
1960s to develop large scale functional business systems in an age of large scale business
conglomerates. Information systems activities revolved around heavy data processing and
number crunching routines".
Several systems development frameworks have been partly based on SDLC, such as the
Structured Systems Analysis and Design Method (SSADM) produced for the UK government
Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the
traditional life cycle approaches to systems development have been increasingly replaced with
alternative approaches and frameworks, which attempted to overcome some of the inherent
deficiencies of the traditional SDLC".[4]

Systems development phases

The System Development Life Cycle framework provides system designers and
developers to follow a sequence of activities. It consists of a set of steps or phases in which each
phase of the SDLC uses the results of the previous one.
A Systems Development Life Cycle (SDLC) adheres to important phases that are
essential for developers, such as planning, analysis, design, and implementation, and are
explained in the section below. A number of system development life cycle (SDLC) models have
been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and
synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a
sequence of stages in which the output of each stage becomes the input for the next. These stages
can be characterized and divided up in different ways, including the following[5]:

Project planning, feasibility study: Establishes a high-level view of the intended project and
determines its goals.
Systems analysis, requirements definition: Refines project goals into defined functions and
operation of the intended application. Analyzes end-user information needs.
Systems design: Describes desired features and operations in detail, including screen layouts,
business rules, process diagrams, pseudo code and other documentation.
Implementation: The real code is written here.
Integration and testing: Brings all the pieces together into a special testing environment, then
checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the
software is put into production and runs actual business.
Maintenance: What happens during the rest of the software's life: changes, correction, additions,
and moves to a different computing platform and more. This, the least glamorous and perhaps
most important step of all, goes on seemingly forever.
In the following example (see picture) these stage of the Systems Development Life Cycle are
divided in ten steps from definition to creation and modification of IT work products:

The tenth phase occurs when the system is disposed of and the task performed is either
eliminated or transferred to other systems. The tasks and work products for each phase are
described in subsequent chapters. [6]
Not every project will require that the phases be sequentially executed. However, the phases are
interdependent. Depending upon the size and complexity of the project, phases may be combined
or may overlap.[6]

System analysis
The goal of system analysis is to determine where the problem is in an attempt to fix the
system. This step involves breaking down the system in different pieces to analyze the situation,
analyzing project goals, breaking down what needs to be created and attempting to engage users
so that definite requirements can be defined. Requirements analysis sometimes requires
individuals/teams from client as well as service provider sides to get detailed and accurate
requirements....often there has to be a lot of communication to and from to understand these
requirements. Requirement gathering is the most crucial aspect as many times communication
gaps arise in this phase and this leads to validation errors and bugs in the software program.

Design
In systems design the design functions and operations are described in detail, including
screen layouts, business rules, process diagrams and other documentation. The output of this
stage will describe the new system as a collection of modules or subsystems.
The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced as a result of interviews, workshops, and/or prototype efforts.
Design elements describe the desired software features in detail, and generally include functional
hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudocode, and a complete entity-relationship diagram with a full data dictionary. These design
elements are intended to describe the software in sufficient detail that skilled programmers may
develop the software with minimal additional input design.

Implementation
Modular and subsystem programming code will be accomplished during this stage. Unit
testing and module testing are done in this stage by the developers. This stage is intermingled
with the next in that individual modules will need testing before integration to the main project.
Testing
The code is tested at various levels in software testing. Unit, system and user acceptance
testings are often performed. This is a grey area as many different opinions exist as to what the
stages of testing are and how much if any iteration occurs. Iteration is not generally part of the
waterfall model, but usually some occur at this stage.
Following are the types of testing:
 Data set testing.
 Unit testing
 System testing
 Integration testing
 Black box testing
 White box testing
 Regression testing
 Automation testing
 User acceptance testing
 Performance testing
 Production process that ensures that the program performs the intended task.

Operations and maintenance

The deployment of the system includes changes and enhancements before the
decommissioning or sunset of the system. Maintaining the system is an important aspect of
SDLC. As key personnel change positions in the organization, new changes will be
implemented, which will require system updates.
Systems development life cycle topics

Management and control

SDLC Phases Related to Management Controls.

The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to
project activity and provide a flexible but consistent way to conduct projects to a depth matching
the scope of the project. Each of the SDLC phase objectives are described in this section with
key deliverables, a description of recommended tasks, and a summary of related control
objectives for effective management. It is critical for the project manager to establish and
monitor control objectives during each SDLC phase while executing projects. Control objectives
help to provide a clear statement of the desired result or purpose and should be used throughout
the entire SDLC process. Control objectives can be grouped into major categories (Domains),
and relate to the SDLC phases as shown in the figure.[7]
To manage and control any SDLC initiative, each project will be required to establish
some degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary
to complete the project. The WBS and all programmatic material should be kept in the “Project
Description” section of the project notebook. The WBS format is mostly left to the project
manager to establish in a way that best describes the project work. There are some key areas that
must be defined in the WBS as part of the SDLC policy. The following diagram describes three
key areas that will be addressed in the WBS in a manner established by the project manager.[7]
Work breakdown structured organization
 Work Breakdown Structure.
The upper section of the Work Breakdown Structure (WBS) should identify the major
phases and milestones of the project in a summary fashion. In addition, the upper section should
provide an overview of the full scope and timeline of the project and will be part of the initial
project description effort leading to project approval. The middle section of the WBS is based on
the seven Systems Development Life Cycle (SDLC) phases as a guide for WBS task
development. The WBS elements should consist of milestones and “tasks” as opposed to
“activities” and have a definitive period (usually two weeks or more). Each task must have a
measurable output (e.g. document, decision, or analysis). A WBS task may rely on one or more
activities (e.g. software engineering, systems engineering) and may require close coordination
with other tasks, either internal or external to the project. Any part of the project needing support
from contractors should have a Statement of work (SOW) written to include the appropriate tasks
from the SDLC phases. The development of a SOW does not occur during a specific phase of
SDLC but is developed to include the work from the SDLC process that may be conducted by
external resources such as contractors and struct.[7]
Baselines in the SDLC
Baselines are an important part of the Systems Development Life Cycle (SDLC). These
baselines are established after four of the five phases of the SDLC and are critical to the iterative
nature of the model .[8] Each baseline is considered as a milestone in the SDLC.
Functional Baseline: established after the conceptual design phase.
Allocated Baseline: established after the preliminary design phase.
Product Baseline: established after the detail design and development phase.
Updated Product Baseline: established after the production construction phase.
Complementary to SDLC
Complementary Software development methods to Systems Development Life Cycle (SDLC)
are:
Software Prototyping
Joint Applications Design (JAD)
Rapid Application Development (RAD)
Extreme Programming (XP); extension of earlier work in Prototyping and RAD.
Open Source Development
End-user development
Object Oriented Programming

Comparison of Methodology Approaches (Post, & Anderson 2006)[9]

 Open
SDLC RAD Objects JAD Prototyping End User
Source
Control Formal MIS Weak Standards Joint User User
Time Frame Long Short Medium Any Medium Short Short
Users Many Few Few Varies Few One or Two One
MIS staff Many Few Hundreds Split Few One or Two None
Transaction/DSS Transaction Both Both Both DSS DSS DSS
Interface Minimal Minimal Weak Windows Crucial Crucial Crucial
Documentation
Vital Limited Internal In Objects Limited Weak None
and training
Integrity and
Vital Vital Unknown In Objects Limited Weak Weak
security
Reusability Limited Some Maybe Vital Limited Weak None

Strengths and weaknesses

Few people in the modern computing world would use a strict waterfall model for their
Systems Development Life Cycle (SDLC) as many modern methodologies have superseded this
thinking. Some will argue that the SDLC no longer applies to models like Agile computing, but
it is still a term widely in use in Technology circles. The SDLC practice has advantages in
traditional models of software development, that lends itself more to a structured environment.
The disadvantages to using the SDLC methodology is when there is need for iterative
development or (i.e. web development or e-commerce) where stakeholders need to review on a
regular basis the software being designed. Instead of viewing SDLC from a strength or weakness
perspective, it is far more important to take the best practices from the SDLC model and apply it
to whatever may be most appropriate for the software being designed.

A comparison of the strengths and weaknesses of SDLC:

Strength and Weaknesses of SDLC [9]
Strengths Weaknesses
Control. Increased development time.
Monitor Large projects. Increased development cost.
Detailed steps. Systems must be defined up front.
Evaluate costs and completion targets. Rigidity.
Documentation. Hard to estimate costs, project overruns.
Well defined user input. User input is sometimes limited.
Ease of maintenance.
Development and design standards.
Tolerates changes in MIS staffing.

An alternative to the SDLC is Rapid Application Development, which combines

prototyping, Joint Application Development and implementation of CASE tools. The advantages
of RAD are speed, reduced development cost, and active user involvement in the development
process.
 It should not be assumed that just because the waterfall model is the oldest original
SDLC model that it is the most efficient system. At one time the model was beneficial mostly to
the world of automating activities that were assigned to clerks and accountants. However, the
world of technological evolution is demanding that systems have a greater functionality that
would assist help desk technicians/administrators or information technology specialists/analysts.

A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system. DFDs can also be used for the visualization of data processing (structured
design).
On a DFD, data items flow from an external data source or an internal data store to an
internal data store or an external data sink, via an internal process.
A DFD provides no information about the timing of processes, or about whether
processes will operate in sequence or in parallel. It is therefore quite different from a flowchart,
which shows the flow of control through an algorithm, allowing a reader to determine what
operations will be performed, in what order, and under what circumstances, but not what kinds of
data will be input to and output from the system, nor where the data will come from and go to,
nor where the data will be stored (all of which are shown on a DFD).

Overview

Data flow diagram example.

Data flow diagram - Yourdon/DeMarco notation.

It is common practice to draw a context-level data flow diagram first, which shows the
interaction between the system and external agents which act as data sources and data sinks. On
the context diagram (also known as the 'Level 0 DFD') the system's interactions with the outside
world are modelled purely in terms of data flows across the system boundary. The context
diagram shows the entire system as a single process, and gives no clues as to its internal
organization.
 This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some
of the detail of the system being modeled. The Level 1 DFD shows how the system is divided
into sub-systems (processes), each of which deals with one or more of the data flows to or from
an external agent, and which together provide all of the functionality of the system as a whole. It
also identifies internal data stores that must be present in order for the system to do its job, and
shows the flow of data between the various parts of the system.
Data flow diagrams were proposed by Larry Constantine, the original developer of
structured design,[2] based on Martin and Estrin's "data flow graph" model of computation.
Data flow diagrams (DFDs) are one of the three essential perspectives of the structured-systems
analysis and design method SSADM. The sponsor of a project and the end users will need to be
briefed and consulted throughout all stages of a system's evolution. With a data flow diagram,
users are able to visualize how the system will operate, what the system will accomplish, and
how the system will be implemented. The old system's dataflow diagrams can be drawn up and
compared with the new system's data flow diagrams to draw comparisons to implement a more
efficient system. Data flow diagrams can be used to provide the end user with a physical idea of
where the data they input ultimately has an effect upon the structure of the whole system from
order to dispatch to report. How any system is developed can be determined through a data flow
diagram.
In the course of developing a set of levelled data flow diagrams the analyst/designers is
forced to address how the system may be decomposed into component sub-systems, and to
identify the transaction data in the data model.
There are different notations to draw data flow diagrams (Yourdon & Coad and Gane & Sarson),
defining different visual representations for processes, data stores, data flow, and external
entities.

Developing a data flow diagram

Event partitioning approach
Event partitioning was described by Edward Yourdon in Just Enough Structured
Analysis.[5]

A context level Data flow diagram created using Select SSADM.

This level shows the overall context of the system and its operating environment and
shows the whole system as just one process. It does not usually show data stores, unless they are
"owned" by external systems, e.g. are accessed by but not maintained by this system, however,
these are often shown as external entities.[6]

Level 1 (high level diagram)

This level (level 1) shows all processes at the first level of numbering, data stores,
external entities and the data flows between them. The purpose of this level is to show the major
and high-level processes of the system and their interrelation. A process model will have one,
and only one, level-1 diagram. A level-1 diagram must be balanced with its parent context level
diagram, i.e. there must be the same external entities and the same data flows, these can be
broken down to more detail in the level 1, example the "enquiry" data flow could be split into
"enquiry request" and "enquiry results" and still be valid.[6] This is all about using your creativity.

Level 2 (low level diagram)

A Level 2 Data flow diagram showing the "Process Enquiry" process for the same
system.
This level is a decomposition of a process shown in a level-1 diagram, as such there
should be a level-2 diagram for each and every process shown in a level-1 diagram. In this
example, processes 1.1, 1.2 & 1.3 are all children of process 1. Together they wholly and
completely describe process 1, and combined must perform the full capacity of this parent
process. As before, a level-2 diagram must be balanced with its parent level-1 diagram.