TOOLS OF THE SYSTEM ANALYST

System Development Life Cycle (SDLC)

- A step by step approach to solving business problems

Kendall and Kendall’s

Systems Development Life Cycle

PHASE ACTIVITIES PEOPLE INVOLVED OUTPUT

1. - observing, interviewing - system analyst - Problem
Identifying - summarizing the knowledge - users Definition
Problems, obtained - management
Opportunities - estimating the scope of
and Objectives project
- documenting the result

2. Determining - sampling, investigating hard - system analyst - the details of the

Information data / company reports - users current system
Requirement - conduct interviews / - operations functions of the
administer questionnaires manager business under
study (how?
Where? when?
What? who?)

3. Analyzing - preparation of system - system analyst - System Models

System Needs proposal that summarizes
what has been found
- provides cost / benefit
analysis of alternatives
- analyze data flow / work flow

4. Designing the - devising the user interface, - system analyst - User Interface
Recommend- files and databases that will - system designer (questions &
ed System store much of the data answers, on – screen
needed menus, graphics)

5. Developing & - coding of programs / - system analyst - Programs /

Documenting modules - programmer Modules /
Software - development of Manuals
documentation (procedural
manuals, online help, “read
me files”

6. Testing & - series of tests to pinpoint - system analyst - revised codes /

Maintaining problems with the sample - programmer / modules /
the System data first eventually with the debugger programs
actual data from the current - tester
system
- updating of programs
7. Implementing - involves training the users to - system analyst - 100% running
& Evaluating handle the new system - users system
the System - converting files from old - management
formats to new one - system trainers
- installing equipment
- evaluation of the new
system

A Modern Approach to Systems Analysis and Design

1950s: focus on efficient automation of existing processes
1960s: advent of 3GL, faster and more reliable computers
1970s: system development becomes more like an engineering discipline
1980s: major breakthrough with 4GL, CASE tools, object oriented methods
1990s: focus on system integration, GUI applications, client/server platforms, Internet
The new century: Web application development, wireless PDAs, component-based
applications

Traditional Waterfall SDLC

One phase begins when another

completes, little backtracking and
looping
 Problems with Waterfall Approach

• System requirements “locked in” after being determined (can't change)

• Limited user involvement (only in requirements phase)
• Too much focus on milestone deadlines of SDLC phases to the detriment of
sound development practices
•
Alternatives to Traditional Waterfall SDLC

1. Prototyping
Iterative development process:
 Requirements quickly converted to a working system
 System is continually revised
 Close collaboration between users and analysts

2. CASE tools
 Computer-Aided Software Engineering
 Software tools providing automated support for systems
development
 Project dictionary/workbook: system description and specifications
 Diagramming tools
 Example products: Oracle Designer, Rational Rose

3. Joint Application Design (JAD)

 Structured process involving users, analysts, and managers
 Several-day intensive workgroup sessions
 Purpose: to specify or review system requirements

4. Rapid Application Development (RAD)

 Methodology to decrease design and implementation time

 Involves: prototyping, JAD, CASE tools, and code generators
 5. Agile Methodologies
- Motivated by recognition of software development as fluid, unpredictable, and
dynamic
Three key principles:
 Adaptive rather than predictive
 Emphasize people rather than roles
 Self-adaptive processes

6. eXtreme Programming
-Short, incremental development cycles
-Automated tests
-Two-person programming teams
-Coding and testing operate together

Advantages:
 Communication between developers
 High level of productivity
 High-quality code

Structured System Analysis

- a method for describing system using figures and flow lines rather than written
narratives.

Tools of Structured Analysis

1. Modeling System Functions – ex. Data Flow Diagram
2. Modeling Stored Data – ex. Entity Relation Diagram
3. Modeling Program Structure – ex. Program Flowchart
4. Modeling Time – ex. Gantt Chart
System Model
- representation of an in – placed system or proposed system that describes the
data flow throughout the structure

Uses of System Modeling Tools

1. To focus on important system features
2. To discuss changes and corrections to the user’s requirements with low cost and
minimal risk
3. To verify that the system analyst understand the user’s environment and has
documented it for the system designers and programmers can build it.

System Modeling Tools

1. Data Flow Diagram (DFD)

- a modeling tools use to describe the transformation of inputs into outputs

- a graphic illustration that shows the flow of data and logic within the system
 Notations / Symbols Used:

a. Entity (Terminator) – a square box specifies either the source or the destination
of data

b. Process (bubbles) – represents the transformation or processing of information

within the system

c. Data Store – a point in a system where information is permanently or temporarily

stored or held.

d. Flow line / Information pipes – connect external entities, process and data store
elements
- can be one way or two ways

Notation Name Example

Entity Student

Student No,
Flow Line

Process

Data Store

1.0
Save
Record

Guidelines for Constructing a Consistent DFD

D1but no
a. Avoid infinite sinks – bubble process that has inputs Student File
outputs.

Proces
s
 b. Avoid spontaneous generation processes – processes that have outputs but no
inputs

Process

c. Beware of unlabeled flow lines and unlabeled processes and data store

d. Avoid hanging flow lines

e. Avoid connecting the entity with the data store, entity with another entity and data
store with data store

Data Store Data Store Data Store

Entity Entity Entity

Developing Data Flow Diagrams Using Top Down Approach (General to Specific)

1. Make a list of business activities and use it to determine the:

 External entities
 Data Flows
 Processes
 Data Store

2. Create a Context Diagram which shows External Entities and Data Flows to and
from the system. Do not show any detailed processes or data stores.

3. Draw a Parent Diagram, the next level. Show processes, but keep them general.
Show data stores at this level.

4. Create a Child Diagram for each of the processes in the Parent Diagram

5. Check for errors and make sure the labels you assign to each process and data
flow are meaningful

Context Diagram (Level 0)

 An overview, which includes basic input, the general system and the
output,
 Bird’s eye view of data movement on the system and the broadest
possible conceptualization of the system
  The highest level in a data flow diagram and contains one process,
representing the entire system
 The process is given the number 0 (zero).

Exploded Diagram
 More detailed than the Context Diagram by “exploding the diagrams”

a. Parent Diagram (The Next Level)

 Inputs and outputs in the first diagram remains constant,
however the rest of the original diagram is exploded into
close – ups involving 3 to 9 processes and showing data
stores and new lower level data flows
 Each process is numbered with an integer.

b. Child Diagram (More Detailed Level)

 Each process in Parent Diagram may in turn be exploded
to create a more detailed child diagram
 The processes on the child diagram are numbered using
the parent process number, a decimal point and a unique
number for each child process

*Primitive Process – a process that cannot be exploded anymore

Example of Data Flow Diagram

Summary of Business Activities for Computerized Enlistment System

A. The student encodes his student number and password which will be
verified in the Student Database.
B. The available subjects are then displayed which are located at the
Subject Schedule Database
C. The student chooses his subjects which is stored in the Enlist Database
D. The student has the option of canceling his enlisted subjects. The
cancellation is saved in the Enlist Database
E. The printed form which contains the subjects enlisted is given to the
student.

The Context Diagram

0
Student . Printed
Computerize
Student information form Student
d Enlistment
System
 The Exploded Diagram

D2 Subj. Sched
D1 Student File
File
Schedule of Subjects
Student information

2.0
1.0 Display
Student
Verify Availabl
Student e
information Login Valid password
Subjects

Printed form Available subjects

5.0 3.0
4.0 Enlisted
Print subjects Enlist
Form Cancel Subje
Subject
ct

Enlisted subjects Cancelled subjects Enlisted subjects

D3 Enlist File

(Note: More examples on DFD will be given)

2. ENTITY RELATIONSHIP DIAGRAM (ERD)

- Depicts the relationship between data objects.

- A notation that is used to conduct data modeling activity
- The attributes of each data object noted in the ERD can be described
using data object description.

Entity - the element that makes up an organizational system

- may be a person, a place, a thing, an event.

Example: passenger on an airplane, a destination, a plane, sales period

Student

Relationship - the association that describes the interaction among the entities

teac
h
Different Types of Relationship

a. one to one

Employee
Employee has Number

b. one to many

teach
Teacher es Student

c. many to one

Is
Programmer
assign Project
ed

d. many to many

Will be
Destination visited Passenger

Different Types of Entities

a. Fundamental Entity – usually a real entity: a person, place, or thing

Fundamental
Entity

Ex.

makes a reservation
Patron Concert/Show
makes a booking for

b. Associative Entity – something created that joints two entities

Associat
ive
Entity

Ex.
Rese
r-
makes a reservation Is for a
Patron vatio Concert/Show
n
makes a booking holds
 c. Attributive Entity – something useful in describing attributes, especially
repeating groups

Attributive
Entity
Ex.

Rese
r- Performanc Concert
makes a reservation Is made for Belongs to / Show
Patron vatio e
n has
makes a booking has

3. DATA DICTIONARY
- a repository that contains description of all objects consumed or produced by
software.
- it is an organized listing of all data elements that are pertinent to the system, with
precise, definitions so that both user and system analyst will have common
understanding of inputs, outputs, component of stores and intermediate
calculations
- created by examining and describing the contents of the data flow, data stores
and processes.

Symbols used in constructing a Data Dictionary

Symbol Name Notation Meaning

Equal = Is composed of
Plus + And
Braces {} Nth Repetition
Brackets [|] Either / Or Situation
Parenthesis () Optional Element

Example:

1. Student Information = Student Number + Student Password

2. Enlisted Subject = Subject Code + Subject Description + Subject Schedule
3. Subject Schedule = Subject Time + Subject Room