-SYSTEMS ANALYSIS

AND TECHNIQUES
Systems Development Tools And
Techniques
 Systems Development
The SDLC :
• Information Systems Planning – both enterprise-
level and project-level planning – and Feasibility
Study
• Analysis – Requirements Determination
• DESIGN – Conceptual and Physical
• Construction (Purchase) and Testing
• Implementation including Training and Conversion
• Evolution – Maintenance and Enhancement
 What is systems development?
• The process of creating and maintaining information
systems is called systems development or systems
analysis and design. This diagram shows that it
involves all five components of an information
system.
• In addition to technical knowledge, it requires
business knowledge and management skill.
What is systems development?

Systems Development vs. Program Development

 What is systems development?
• While you may be able to purchase an off-the-shelf software
program, you won’t be able to do that with information
systems.
• Here are some of the reasons why:
– You must construct or adapt procedures to fit the business and the
people who will be using the system. You can’t buy
procedures.
– People must be trained to use the information system
effectively. You can’t buy that.
– Users must take ownership of their system. That’s the
single most important criterion for the success of an
information system.
– Information system maintenance involves two things:
– Fixing a system to make it do what it should have done in
the first place, or – Adapting it to changing requirements.
How do businesses use the systems development life cycle
(SDLC) process?
• The classical systems development life cycle (SDLC)
process includes five phases as this diagram points out:
• System definition
• Requirements analysis
• Component design
• Implementation
• System maintenance (fix or enhance)
How do businesses use the systems development life cycle
(SDLC) process?
 Phase One: System Definition
Once the business-planning process determines the need for a
new system, there are four steps to defining the system:
• Define the system’s goals and scope. Will you use it to
facilitate collaboration, aid in decision-making, problem-
solving, or project management, or help the organization gain
a competitive advantage?
• Assess the feasibility of the project using four criteria: cost,
schedule, technical, and organizational.
• Form a project team that includes systems analysts and users.
• Prepare a project plan.
SDLC: System Definition Phase
 Phase Two: Requirements Analysis
The most important phase in the SDLC process is to determine
system requirements. If the requirements are wrong, the system
will be wrong. Seven activities occur in this phase as the diagram
shows.
• Users are a critical part of this phase. They must approve the
requirements before moving to the next phase.
SDLC: Requirements Analysis Phase
 Phase Three: Component Design
All five components require attention in the design phase:
• Hardware —Determine the specifications and evaluate
alternatives against the requirements.
• Programs —Decide whether to use off-the-shelf software,
off-the-shelf with alterations, or custom-developed software.
• Database —Convert the data model to a database design.
• Procedures —Design procedures for users, operations
personnel, and for normal, backup, and failure recovery tasks.
• People —Design job descriptions for users and operations
personnel. You may have to add new jobs or alter existing
jobs.
SDLC: Component Design Phase
 Phase Four: Implementation
Focuses on implementing the system and includes the tasks
of
• Building each of the five system components
• Testing the system and
• Converting users to the new system.
SDLC: Implementation Phase
 System Testing
System testing begins by creating a test plan that spells out what
actions users will take when using the new system. It includes
testing normal actions and incorrect actions.
Every line of program code should be executed to test error
messages.
– Product quality assurance (PQA) personnel can construct a
test plan with user advice and assistance. They can perform
some of the testing and supervise users as they test the system.
– Users must be part of the test team and help develop test
plans and test cases. Users must have the final say.
– Beta testing allows future system users to try the new system
on their own in the last stage of testing.
 Phase Five: System Maintenance
The last phase of the SDLC process includes three tasks:
• Recording requests for changes as a result of failures or
enhancements
• Prioritizing the requests into high- or low-priority and
• Fixing failures by issuing patches (high-priority), service packs
(low-priority), or new releases.
• Deciding to enhance a system requires that you start the
SDLC process all over, from the beginning.
SDLC: System Maintenance Phase
 Systems Development Methodologies
• How do you change the oil in your car? How do
you bake a cake? How do you study for a test?
No doubt you have an answer for all of these
questions. Assuming you were going to do one
of these three tasks (baking the cake sounds
best—yum!), you probably have "a way" of
doing it. Is your way the correct way? Is your
way the only way? Is your way the best way? If
you answered, "yes" to all three of these
questions, you are in trouble!
 Systems Development Methodologies
• When talking about methodologies, some
people refer to them as the strategy, process,
steps, directions, or actions they choose to do or
think about something. Several software
development authors refer to methodologies in
software development as a software
development process or simply a software
process
 Structured Systems
Methodologies
• Structured refers to the fact that the
techniques are step by step, with each
step building on the previous one.
• Structured methodologies are top-
down, progressing from the highest,
most abstract level to the lowest level
of detail—from the general to the
specific.
Structured Systems Methodologies
 Feasibility Study

0 Feasibility
• Prepare for the feasibility study
• Define the problem
• Select feasibility options
• Create feasibility report
 Requirements Analysis

1 Investigation of Current Environment

• Establish analysis framework
• Investigate and define requirements
• Investigate current processing
• Investigate current data
• Derive logical view of current services
• Assemble investigate results

2 Business system options

• Define business system options
• Select business system options
• Define requirements
 Requirements Specification

3 Definition of Requirements
• Define required system processing
• Develop required data model
• Derive system functions
• Enhance required data model
• Develop specification prototypes
• Develop processing specification
• Confirm system objectives
• Assemble requirements specification
 Logical System Specification

4 Technical system options

• Define technical system options
• Select technical system options
• Define physical design module

5 Logical Design
• Define user dialogues
• Define update processes
• Define enquiry process
• Assemble logical design
 Physical Design
6 Physical design
• Prepare for physical design
• Create physical data design
• Create function component implementation map
• Optimise physical data design
• Complete function specification
• Consolidate process data interface
• Assemble physical design
• Structured development methods are
process-oriented, focusing primarily
on modeling the processes, or actions
that capture, store, manipulate, and
distribute data as the data flow
through a system.
• The primary tool for representing a system’s
component processes and the flow of data
between them is the data flow diagram (DFD).
• The data flow diagram offers a logical graphic
model of information flow, partitioning a system
into modules that show manageable levels of
detail. It rigorously specifies the processes or
transformations that occur within each module
and the interfaces that exist between them.
• Figure 13-6 shows a simple data flow
diagram for a mail-in university course
registration system.
• The rounded boxes represent processes,
which portray the transformation of data.
• The square box represents an external
entity, which is an originator or receiver of
information located outside the
boundaries of the system being modeled.
• The open rectangles represent data
stores, which are either manual or
automated inventories of data.
• The arrows represent data flows, which
show the movement between processes,
external entities, and data stores. They
contain packets of data with the name or
content of each data flow listed beside the
arrow.
• This data flow diagram shows that
students submit registration forms with
their name, identification number, and the
numbers of the courses they wish to take.
• In process 1.0, the system verifies that
each course selected is still open by
referencing the university’s course file.
• The file distinguishes courses that are
open from those that have been canceled
or filled.
• Process 1.0 then determines which
of the student’s selections can be
accepted or rejected.
• Process 2.0 enrolls the student in the
courses for which he or she has been
accepted.
• It updates the university’s course file with the
student’s name and identification number and
recalculates the class size. If maximum
enrollment has been reached, the course
number is flagged as closed.
• Process 2.0 also updates the university’s
student master file with information about
new students or changes in address.
• Process 3.0 then sends each student applicant
a confirmation-of-registration letter listing the
courses for which he or she is registered and
noting the course selections that could not be
fulfilled.
 Another tool for structured analysis is a data
dictionary, which contains information about
individual pieces of data and data groupings
within a system.
• The data dictionary defines the contents of
data flows and data stores so that systems
builders understand exactly what pieces of
data they contain.
• Process specifications describe the
transformation occurring within the lowest
level of the data flow diagrams. They express
the logic for each process.
 RAPID APPLICATION
DEVELOPMENT (RAD)
• Object-oriented software tools, reusable
software, prototyping, and fourth generation
language tools are helping systems builders
create working systems much more rapidly
than they could using traditional systems-
building methods and software tools.
• The term rapid application development
(RAD) is used to describe this process of
creating workable systems in a very short
period of time.
• RAD can include the use of visual
programming and other tools for building
graphical user interfaces, iterative prototyping
of key system elements, the automation of
program code generation, and close teamwork
among end users and information systems
specialists. Simple systems often can be
assembled from prebuilt components. The
process does not have to be sequential, and
key parts of development can occur
simultaneously.
• Agile development focuses on rapid
delivery of working software by breaking a
large project into a series of small
subprojects that are completed in short
periods of time using iteration and
continuous feedback.
• Each mini-project is worked on by a
team as if it were a complete project,
including planning, requirements analysis,
design, coding, testing, and
documentation. Improvement or
addition of new functionality takes place
within the next iteration as developers
clarify requirements.
• This helps to minimize the overall risk,
and allows the project to adapt to
changes more quickly. Agile methods
emphasize face-to-face communication
over written documents, encouraging
people to collaborate and make decisions
quickly and effectively.
Prototyping Techniques
 PROTOTYPING
• Prototyping consists of building
an experimental system rapidly
and inexpensively for end users to
evaluate. By interacting with the
prototype, users can get a better idea
of their information requirements.
The prototype endorsed by the users
can be used as a template to create
the final system.
• The prototype is a working version of an
information system or part of the system,
but it is meant to be only a preliminary
model. Once operational, the prototype will
be further refined until it conforms precisely
to users’ requirements. Once the design has
been finalized, the prototype can be
converted to a polished production system.
• The process of building a preliminary
design, trying it out, refining it, and trying
again has been called an iterative process
of systems development because the steps
required to build a system can be repeated
over and over again.
• Prototyping is more explicitly iterative
than the conventional life cycle, and it
actively promotes system design changes.
It has been said that prototyping replaces
unplanned rework with planned
iteration, with each version more
accurately reflecting users’ requirements.
 STEPS IN PROTOTYPING
• Step 1: Identify the user’s basic
requirements. The system designer
(usually an information systems
specialist) works with the user only long
enough to capture the user’s basic
information needs.
• Step 2: Develop an initial prototype.
The system designer creates a working
prototype quickly, using tools for
rapidly generating software.
 STEPS IN PROTOTYPING
• Step 3: Use the prototype. The user is
encouraged to work with the system to
determine how well the prototype meets his
or her needs and to make suggestions for
improving the prototype.
• Step 4: Revise and enhance the prototype.
The system builder notes all changes the user
requests and refines the prototype
accordingly. After the prototype has been
revised, the cycle returns to Step 3. Steps 3
and 4 are repeated until the user is satisfied.
 What are the principal methodologies for
modeling and designing systems?

• The two principal methodologies for

modeling and designing information
systems are:
1. structured methodologies and
2. object-oriented development.
• Structured methodologies focus on
modeling processes and data
separately.
• The data flow diagram is the principal
tool for structured analysis, and the
structure chart is the principal tool
for representing structured software
design. (See figure 3.7)
• Object-oriented development
models a system as a collection of
objects that combine processes and
data. Object-oriented modeling is
based on the concepts of class and
inheritance.
 Object-Oriented Modeling
• Structured methods are useful for
modeling processes, but do not handle
the modeling of data well. They also treat
data and processes as logically separate
entities, whereas in the real world such
separation seems unnatural. Different
modeling conventions are used for
analysis (the data flow diagram) and for
design (the structure chart) (See figure
3.7).
 Object-Oriented Modeling
• Object-oriented development uses the
object as the basic unit of systems
analysis and design.
• An object combines data and the
specific processes that operate on those
data. Data encapsulated in an object can
be accessed and modified only by the
operations, or methods, associated with
that object.
 Object-Oriented Modeling
• Instead of passing data to procedures,
programs send a message for an object to
perform an operation that is already
embedded in it. The system is modeled as
a collection of objects and the
relationships among them. Because
processing logic resides within objects
rather that in separate software programs,
objects must collaborate with each other
to make the system work.
 Object-Oriented Modeling
• Object-oriented modeling is based on the
concepts of class and inheritance. Objects
belonging to a certain class, or general
categories of similar objects, have the features
of that class. Classes of objects in turn can
inherit all the structure and behaviors of a
more general class and then add variables and
behaviors unique to each object. New classes
of objects are created by choosing an existing
class and specifying how the new class differs
from the existing class, instead of starting
from scratch each time.
 Object-Oriented Modeling
• We can see how class and inheritance work in
Figure 13-8, which illustrates the relationships
among classes concerning employees and how
they are paid.
Class Inheritance
 Object-Oriented Modeling
• Employee is the common ancestor, or
superclass, for the other three classes. Salaried,
Hourly, and Temporary are subclasses of
Employee.
• The class name is in the top compartment, the
attributes for each class are in the middle
portion of each box, and the list of operations
is in the bottom portion of each box.
 Object-Oriented Modeling
• The features that are shared by all employees
(id, name, address, date hired, position, and pay)
are stored in the Employee superclass, whereas
each subclass stores features that are specific to
that particular type of employee. Specific to
hourly employees, for example, are their hourly
rates and overtime rates. A solid line from the
subclass to the superclass is a generalization path
showing that the subclasses Salaried, Hourly, and
Temporary have common features that can be
generalized into the superclass Employee.
• REVIEW
What are the alternative methods for
building information systems?
• Prototyping -

• Prototyping consists of building an

experimental system rapidly and
inexpensively for end users to interact
with and evaluate.
• Prototyping encourages end-user
involvement in systems development and
iteration of design until specifications are
captured accurately. The rapid creation of
prototypes can result in systems that have
not been completely tested or
documented or that are technically
inadequate for a production
environment.
What are the core activities in the
systems development process?
• The core activities in systems
development are systems analysis,
systems design, programming, testing,
conversion, production, and
maintenance.
• Systems analysis is the study and analysis
of problems of existing systems and the
identification of requirements for their
solutions.
 Cont’d

• Systems design provides the

specifications for an information system
solution, showing how its technical and
organizational components fit together.