SYSTEM

DEVELOPMENT
AND

METHODOLOGI
System Development Life Cycle (SDLC)


ES
System Methodologies
THE SYSTEM DEVELOPMENT
LIFE CYCLE (SDLC)
-is a structured step-by-step approach for developing
information systems.
The System Development Life Cycle (SDLC) has four
fundamental phases:
PLANNING
ANALYSIS
DESIGN
IMPLEMENTATION
PLANNING
-INVOLVES DETERMINING A SOLID PLAN FOR DEVELOPING YOUR INFORMATION
The planning phase is the fundamental SYSTEM
process of understanding why an information
system should be built and determining how the project team will go about building it. It
has two steps:
1. During project initiation, the system’s business value to the organization is identified—
how will it lower costs or increase revenues? Most ideas for new systems come from outside
the IS area usually in the form of a system request. A system request presents a brief
summary of a business needs, and it explains how a system that supports the need will
create business value. The IS department works together with the person or department
that generated the request (called the project sponsor) to conduct a feasibility
analysis. The feasibility analysis examines key aspects of the proposed project:
 The technical feasibility (Can we build it?)
 The economic feasibility (Will it provide business value?)
 The organizational feasibility (If we build it, will it be used?)

The system request and feasibility analysis are presented to an information systems
approval committee (sometimes called a steering committee), which decides whether
the project should be accepted.
PLANNING
-INVOLVES DETERMINING A SOLID PLAN FOR DEVELOPING YOUR INFORMATION
SYSTEM
2. Once the project is approved, it enters—PROJECT MANAGEMENT.
During project management, the project manager creates a workplan,
staffs the project, and puts techniques in place to help the project team
control and direct the project through the entire SDLC. The deliverable or
presentation for project management is a project plan that describes how
the project team will go about developing the system.
 Project plan - defines the what, when, and who questions of
system development
 Project manager - an individual who is an expert in project
planning and management, defines and develops the project
plan and tracks the plan to ensure all key project milestones are
completed on time.
 Project milestones - represent key dates for which you need a
certain group of activities performed.
ANALYSIS
The analysis phase answers the questions of who will use the system, what the
system will do, and where and when it will be used. It involves end users and IT
specialists working together to gather, understand, and document the business
requirements for the proposed system.
During this phase, the project team investigates any current system(s), identifies
improvement opportunities, and develops a concept for the new system. This phase has
three steps:
1. An analysis strategy is developed to guide the project team’s efforts. Such a
strategy usually includes an analysis of the current system (called the as-is system) and
its problems, and then ways to design a new system (called the to-be system).
2. The next step is requirements gathering (e.g., through interviews or
questionnaires). The analysis of this information—in conjunction with input from project
sponsor and many other people—leads to the development of a concept for a new system.
3. The analysis, system concept, and models are combined into a document called the
system proposal, which is presented to the project sponsor and other key decision makers
(e.g., members of the approval committee) that decide whether the project should
continue to move forward.
The system proposal is the initial deliverable that describes what business requirements
the new system should meet. Because it is really the first step in the design of the new
system.
DESIGN
-Build a technical blueprint of how the proposed system will work.
The design phase decides how the system will operate, in terms of the hardware, software, and
network infrastructure; the user interface, forms and reports; and the specific programs,
databases, and files that will be needed. Although most of the strategic decisions about the
system were made in the development of the system concept during the analysis phase, the
steps in the design phase determine exactly how the system will operate. The design phase has
four steps:
1. The design strategy must be developed. This clarifies whether the system will be
developed by the company’s own programmers, whether it will be outsourced to another firm
(usually a consulting firm), or whether the company will buy an existing software package.
2. This leads to the development of the basic architecture design for the system that describes
the hardware, software, and network infrastructure that will be used. The interface design
specifies how the users will move through the system (e.g., navigation methods such as menus
and on-screen buttons) and the forms and reports that the system will use.
3. The database and file specifications are developed. These define exactly what data will be
stored and where they will be stored.
4. The analyst team develops the program design, which defines the programs that need to be
written and exactly what each program will do.
This collection of deliverables (architecture design, interface design, database and file
specifications, and program design) is the system specification that is handed to the
programming team for implementation.
 IMPLEMENTATION
The final phase in the SDLC is the implementation phase, during which the system is
actually built (or purchased, in the case of a packaged software design). This is the phase
that usually gets the most attention, because for most systems it is longest and most
expensive single part of the development process. This phase has three steps:
1. System construction is the first step. The system is built and tested to ensure it
performs as designed. Since the cost of bugs can be huge, testing is one of the most
critical steps in implementation. Most organizations spend more time and attention on
testing than on writing the programs in the first place.
 Alpha Testing- The researchers or proponents conducted the testing themselves first.
 Beta Testing- The researchers or proponents invited other groups to test their system.
 Pilot Testing- In Pilot Testing, the researchers or proponents went to the beneficiary of the system and
present the in charge or the staff to test the system.
2. The system is installed. Installation is the process by which the old system is turned
off and the new one is turned on. One of the most important aspects of conversion is the
development of a training plan to teach users how to use the new system and help
manage the changes caused by the new system.
3. The analyst team establishes a support plan for the system. This plan usually
includes a formal or informal post-implementation review, as well as a systematic way for
identifying major and minor changes needed for the system.
SYSTEMS DEVELOPMENT METHODOLOGIES
A methodology is a formalized approach to implementing
the SDLC (i.e., it is a list of steps and deliverables).
A system development methodology refers to the
framework that is used to structure, plan, and control the
process of developing an information system. A wide
variety of such frameworks have evolved over the years,
each with its own recognized strengths and weaknesses.
Two categories of System Development Methodologies:

Structured Design
Rapid Application Development (RAD)
 STRUCTURED DESIGN
The first category of systems development methodologies is called
structured design. Structured design methodologies adopt a formal step-
by-step approach to the SDLC that moves logically from one phase to the
next.

1. WATERFALL DEVELOPMENT METHODOLOGY

With waterfall development–based methodologies, the analysts and users
proceed in sequence from one phase to the next. Once the sponsor approves
the work that was conducted for a phase, the phase ends and the next one
begins. This methodology is referred to as waterfall development because it
moves forward from phase to phase in the same manner as a waterfall.
WATERFALL DEVELOPMENT-BASED
METHODOLOGY
The two key advantages of the
structured design waterfall approach
are that it identifies system
requirements long before programming
begins and it minimizes changes to the
requirements as the project proceeds.

The two key disadvantages are that the design

must be completely specified before programming
begins and that a long time elapses between the
completion of the system proposal in the analysis
phase and the delivery of the system
 STRUCTURED DESIGN
2. PARALLEL DEVELOPMENT METHODOLOGY
The parallel development methodology attempts to address the
problem of long delays between the analysis phase and the delivery
of the system. Instead of doing design and implementation in
sequence, it performs a general design for the whole system and
then divides the project into a series of distinct subprojects that can
be designed and implemented in parallel. Once all subprojects are
complete, there is a final integration of the separate pieces, and the
system is delivered.

The primary advantage of this methodology is that it can reduce

the schedule time to deliver a system; thus, there is less chance of
changes in the business environment causing rework.
PARALLEL DEVELOPMENT METHODOLOGY
 RAPID APPLICATION DEVELOPMENT (RAD)
A second category of methodologies. RAD-based methodologies attempt to address
both weaknesses of structured design methodologies by adjusting the SDLC phases to
get some part of the system developed quickly and into the hands of the users. In this
way, the users can better understand the system and suggest revisions that bring the
system closer to what is needed.
1. PHASED DEVELOPMENT
A phased development–based methodology breaks the overall system into a
series of versions that are developed sequentially. The analysis phase identifies the
overall system concept, and the project team, users, and system sponsor then
categorize the requirements into a series of versions. The most important and
fundamental requirements are bundled into the first version of the system. The
analysis phase then leads into design and implementation, but only with the set of
requirements identified for version
Once version 1 is implemented, work begins on version 2. Additional analysis is per-
formed based on the previously identified requirements and combined with new ideas
and issues that arose from the users’ experience with version 1. Version 2 then is
designed and implemented, and work immediately begins on the next version. This
process continues until the system is complete or is no longer in use.
PHASED DEVELOPMENT
METHODOLOGY
PROTOTYPING-BASED METHODOLOGY
A prototyping-based methodology performs the analysis, design, and implementation
phases concurrently, and all three phases are performed repeatedly in a cycle until the
system is completed. With these methodologies, the basics of analysis and design are
performed, and work immediately begins on a system prototype, a “quick-and- dirty”
program that provides a minimal amount of features. The first prototype is usually the
first part of the system that the user will use. This process continues in a cycle until the
analysts, users, and sponsor agree that the prototype provides enough functionality to be
installed and used in the organization. After the prototype (now called the system) is
installed,
The refinement
key advantage of occurs until it is accepted as the new system
a prototyping-based
methodology is that it very quickly provides
a system for the users to interact with,
even if it is not ready for widespread
organizational use at first. Prototyping
reassures the users that the project team is
working on the system (there are no long
delays in which the users see little
progress), and prototyping helps to more
quickly refine real requirements. Rather
than attempting to understand a system
specification on paper, the users can
interact with the prototype to better
THROWAWAY PROTOTYPING-BASED METHODOLOGIES
The throwaway prototyping-based methodologies have a relatively thorough analysis phase
that is used to gather information and to develop ideas for the system concept. Each of
these issues is examined by analyzing, designing, and building a design prototype. A
design prototype is not a working system; it is a product that represents a part of the system
that needs additional refinement or improvement, and it only contains enough detail to
enable users to understand the issues under consideration. A system that is developed using
this type of methodology probably relies on several design prototypes during the analysis
and design phases. Each of the prototypes is used to minimize the risk associated with the
system by confirming that important issues are understood before the real system is built.
Once the issues are resolved, the project moves into design and implementation. At this
point, the design prototypes are thrown away, which is an important difference between
these methodologies and prototyping methodologies, in which the prototypes evolve into the
final system.