Systems Development Life Cycle
Systems Development Life Cycle
Systems Development Life Cycle
SDLC is composed of a number of clearly defined and distinct work phases which are used by
systems engineers and systems developers to plan for, design, build, test, and deliver information
systems.
The objectives and sequence of systems development life cycle (SDLC) activities are
logical and generally accepted by experts in the systems community, and are generally
treated as “best practices” for systems development.
The first seven phases of the SDLC describe the activities that all new systems
should undergo. New systems development involves conceptual steps that can apply to
any problem-solving process:
- the chief executive officer, the chief financial officer, the chief information officer, senior
management from user areas, the internal auditor, and senior management from computer
services. External parties, such as management, consultants and the firm’s external auditors,
may also supplement the committee.
a. Strategic Systems Planning- involves allocation of systems resources at the macro level.
It usually deals with a time frame of 3-5 years. This process is similar to budgeting
resources for other strategic activities, such as product development, plant expansions,
market research, and manufacturing technology. Technically, a strategic system planning
is not part of the SDLC because the SDLC pertains to specific applications.
Project Proposal
Purposes: First, it summarizes the findings of the study conducted to this point
into a general recommendation for a new or modified system. Second, it outlines
the linkage between objectives of the proposed system and the business objectives
of the firm.
Project Schedule- represents management commitment to project and is a budget
of time and costs for all the phases of SDLC.
Systems Analysis-Phase II
It is the foundation for the rest of the SDLC and is actually a two-step process involving:
The analyst often begins the analysis by determining what elements, if any, of the current system
should be preserved as part of the new system. This involves a rather detailed system survey.
Facts pertaining to preliminary questions about the system are gathered and analyzed. When all
relevant facts have been gathered and analyzed, the analyst arrives at an assessment of the
current system.
Gathering Facts
The survey of the current system is essentially a fact-gathering activity. System facts fall into
the following broad classes.
• Data sources. These include external entities, such as customers or vendors, as well
as internal sources from other departments.
• Users. These include both managers and operations users.
• Data stores. Data stores are the files, databases, accounts, and source documents
used in the system.
• Processes. Processing tasks are manual or computer operations that represent a decision
or an action triggered by information.
• Data flows. Data flows are represented by the movement of documents and reports
between data sources, data stores, processing tasks, and users. Data flows can also be
represented in UML diagrams.
• Controls. These include both accounting and operational controls and may be manual
procedures or computer controls.
• Transaction volumes. The analyst must obtain a measure of the transaction volumes
for a specified period of time. Many systems are replaced because they have reached their
capacity. Understanding the characteristics of a systems transaction volume and its rate of
growth are important elements in assessing capacity requirements for the new system.
• Error rates. Transaction errors are closely related to transaction volume. As a system
reaches capacity, error rates increase to an intolerable level.
• Resource costs. The resources used by the current system include the costs of labor,
computer time, materials (such as invoices), and direct overhead. Any resource costs
that disappear when the current system is eliminated are called escapable costs.
Later, when we perform a cost-benefit analysis, escapable costs will be treated as
benefits of the new system.
• Bottlenecks and redundant operations. The analyst should note points where data
flows come together to form a bottleneck. At peak-load periods, these can result in
delays and promote processing errors. Likewise, delays may be caused by redundant
operations, such as unnecessary approvals or sign-offs.
Fact-Gathering Techniques
Systems analysts employ several techniques to gather the previously cited facts. Commonly
used techniques includes:
open-ended questions- allow users to elaborate on the problem as they see it and offer
suggestions and recommendations.
formal questionnaires- used to ask more specific, detailed questions and to restrict the
user’s responses.
• Organizational charts
• Job descriptions
• Accounting records
• Charts of accounts
• Policy statements
• Descriptions of procedures
• Financial statements
• Performance reports
• System flowcharts
• Source documents
• Transaction listings
• Budgets
• Forecasts
• Mission statements
The event that marks the conclusion of the systems analysis phase is the preparation of a
formal systems analysis report. This report presents to management or the steering committee
the survey findings, the problems identified with the current system, the user’s
needs, and the requirements of the new system.
The systems analysis report should establish in clear terms the data sources, users, data files,
general processes, data flows, controls and transaction volume capacity.