SYSTEM DEVELOPMENT LIFE

CYCLE
SDLC
SDLC
SDLC
SDLC
SDLC
• Is used in Every Software Development Company because it is the root
of the Development Cycle, if that model would not exist in the world.
There are many specific tasks involved with system development.
• Although the arrangement and order of these tasks may vary from
organization to organization and project to project, system
development typically involves six steps or phases, which make up the
system development life cycle (SDLC)
he SDLC
• SDLC describes the development of a system from the time it is first
studied until the time it is updated or replaced.
Preliminary investigation

Documentation: Feasibility Report

• The main output of the preliminary investigation is the feasibility report, which
includes
the systems analyst’s findings on the status of the existing system, as well as the
benefits
and feasibility of changing to a new system.
• Feasibility is commonly measured using a few different perspectives, such as
whether the organization has (or can acquire) the hardware, software, and
personnel needed to implement the new system; whether the new system would
fit well with the other systems in the organization; and whether the estimated
benefits of the new system outweigh the estimated costs.
• The feasibility report also contains the systems analyst’s recommendations about
whether or not the project should move on to the next stage in the SDLC:
System Analysis and requirement

Data collection and data analysis

• System analysis is the phase of system development in which the
current system and identified problems are studied in depth and the
needs of system users are assessed.
• The principal purpose of this stage is to help the systems analyst study
the current system and then organize his or her findings in order to
draw conclusions about the adequacy of the current system and to
determine whether or not the project should move on to the system
design stage.
• The main activities conducted during system analysis are data
collection and data analysis
System Analysis and requirement

• Data Collection
• The objective of data collection is to gather useful data about the system
being studied.
• Some data-gathering tools that can be used include reviewing documents
that show how the system is intended to work.
• Collecting copies of input and output screens and available reports.
• Reviewing organizational charts to determine the people and areas of
responsibility in the part of the organization that the system is or will be
located.
• Sending questionnaires to users and interviewing and observing those who
use the system, or the information produced by it.
System Analysis and requirement

Data Analysis
• Once data about the system is gathered, it then needs to be analysed to determine
the effectiveness and efficiency of the current system and/or the requirements for
a new or modified system.
• The tools used in data analysis vary depending on the type of system being studied
and the preferences of the systems analyst; some of the most widely used data
analysis tools are:
• Entity-Relationship Diagrams (ERDs) and Data Flow Diagrams (DFDs)
• Decision Tables and Decision Trees
• Business Process Modeling Notation (BPMN)
• Data Flow Diagrams
• Class Diagrams and Use Case Diagrams
• Documentation: Models
Entity-Relationship Diagrams (ERDs) and Data
Flow Diagrams (DFDs)
• An ERD shows the logical relationships and interaction among system
entities, such as customers, employees, and orders.
• A DFD illustrates the activities that are part of a system, as well as the
data or information flowing into and out of each activity.
• In essence, it provides a visual representation of data movement in an
organization.
DFD
DFD
ERD
ERD
Decision Tables and Decision Trees
Business Process Modeling Notation (BPMN)
System Design

System design focuses on specifying what the new system will look like and how it will work.
• This phase primarily consists of developing the design and specifications for the new
system and performing a detailed analysis of the expected benefits and costs.
• When designing a system, the systems analyst must take into account a variety of factors.
• One important factor is input.
• The systems analyst needs to determine the data that will be input into the new system
and then usually creates a data dictionary (which describes the characteristics of all data
used in a system) for the new system.
• The data dictionary typically includes the type of each piece of data in a system and its
allowable size, any restrictions on its format (such as having to be within a certain
numerical range or consisting of only certain letters of the alphabet), and who has the
authority to update that piece of data.
Other factors to be considered
• Other factors to be considered when designing a new system include
the devices, processing power, and cloud services that will be required
to host and use the system; the other systems the new system must
interact with; and the type and format of information that will be
output.
• In addition, the system design should address the security features
that will be needed to ensure that data is input accurately and secured
against data loss.
• Other security considerations include restricting physical access to the
computers used in the system, adequately securing the networks used
with the new system, and the necessary backup and disaster recovery
procedures.
Designs tools
• PAPER DESIGNS
Can be sketched on paper.
• DIGITAL DESIGNS

Can be created using a variety of software programs

Cost-Benefit Analysis

• Once the new system has been designed, most organizations will
perform a cost-benefit analysis to help determine whether the
expected benefits of implementing the new system are worth its
expected cost in order to determine if the design for the new
system should be implemented.
• The cost of a new system includes the initial investment in
hardware, software, and training, as well as ongoing expenses,
such as for new personnel, cloud services, and maintenance.
Documentation: System Design/Specifications

• The system design and specifications developed during the system

design phase consist of all the documentation necessary to illustrate
the new system, including the data dictionary; DFDs, class diagrams,
and other diagrams; input and output designs; necessary security
controls; and so forth.
System Acquisition

• Once a system has been designed and the required types of hardware and
software have been specified, the systems analyst must decide where to
obtain the necessary components.
This decision lies at the heart of the system acquisition phase.
• While hardware is usually purchased from outside vendors, software
can be developed either in-house or obtained from an outside vendor,
depending on the needs of the company and whether or not the
company has the necessary staff and other resources for in-house
development.
• This decision is referred to as the make-or-buy decision.
Make-or-Buy Decision

• One of the first steps in the system acquisition phase is determining whether
the software needed
• for the new system should be created in-house or acquired from a software
vendorIf an organization decides to
• develop its own custom application software instead of acquiring software
from an outside vendor, it moves into the program development process
• This process uses the system specifications generated in the system design phase
of the SDLC and continues through writing, testing, and maintenance of the
program.
• Once the program development life cycle (PDLC) has been completed, the system
development life cycle continues, just as it would if the software had been
purchased.
System Implementation

• Once the required new hardware has been purchased and the required
software has been purchased or developed, the system
implementation phase can begin.
• This phase includes the tasks necessary to make the system
operational, including getting existing data ready to move to the new
system (called data migration) and installing the new hardware and
software.
Testing
• Before data is transferred to the new system, however, the system should be
thoroughly tested to ensure it is working properly.
• Often individual components of the system are tested alone first, and then the
complete system is tested.
• Test data that is realistic and includes incorrect data that might accidentally occur
during actual use (such as inputting a negative order quantity or leaving a required
address field blank) should be developed and used during the preliminary testing
process to ensure that input errors are detected by the new system.
• Once the system has passed the testing stage, the system conversion process can
begin.
• Typically, system conversion takes place using one or more of the strategies
system conversion and implementation
Direct conversion
• A direct conversion is when a company stops using the old system and
start using the new system at a specific point in time.
• This can be risky because even with sufficient testing, it is impossible
to make sure there are no issues with the new system.
Parallel conversion:
• Parallel conversion is when the process is run on the old and new
system for a period of time.
• This process is less risky than the direct approach because the
company still has the old system to rely on.
• One downside is that this approach duplicates the work since it’s the
work is being performed in two environments.
Phase-in conversion
• This is when the company slowly implements a system in pieces.
• This can be useful to make sure that the whole process is not
interrupted, which makes it less risky than the direct approach.
Pilot conversion:
• Pilot is when the company uses the system in a test environment for a
period of time to work out all of the bugs.
• This is less risky than the direct approach since it allows the company
to understand the issues that may become applicable with a new
system.