Introduction to Systems Analysis and Design

Lecture 1
Courtesy
Subhasish Dasgupta

1
ISTM 280, GWU

Key Ideas

Many failed systems were abandoned

because analysts tried to build wonderful
systems without understanding the
organization.
The primarily goal is to create value for the
organization.

2
ISTM 280, GWU

Key Ideas

The systems analyst is a key person analyzing the

business, identifying opportunities for improvement,
and designing information systems to implement
these ideas.
It is important to understand and develop through
practice the skills needed to successfully design and
implement new information systems.

3
ISTM 280, GWU

The Systems Development Life Cycle: Major

Attributes of the Lifecycle

The project

Moves systematically through phases where each phase

has a standard set of outputs
Produces project deliverables
Uses deliverables in implementation
Results in actual information system
Uses gradual refinement

4
ISTM 280, GWU

Project Phases

Planning

Analysis

Who, what, when, where will the system be?

Design

Why build the system?

How will the system work?

Implementation

System delivery

5
ISTM 280, GWU

Planning

Identifying business value

Analyze feasibility
Develop work plan
Staff the project
Control and direct project

6
ISTM 280, GWU

Analysis

Analysis
Information gathering
Process modeling
Data modeling

7
ISTM 280, GWU

Design

Physical design
Architectural design
Interface design
Database and file design
Program design

8
ISTM 280, GWU

Implementation

Construction
Installation

9
ISTM 280, GWU

Processes and Deliverables

Process

Product

Planning

Project Plan

Analysis

System Proposal

Design

System
Specification

Implementation

New System and

Maintenance Plan
10
ISTM 280, GWU

Systems Development Methodology:

What Is a Methodology?

A formalized approach or series of steps

Writing code without a well-thought-out
system request may work for small programs,
but rarely works for large ones.

11
ISTM 280, GWU

Structured Design

Projects move methodically from one to the

next step
Generally, a step is finished before the next
one begins

12
ISTM 280, GWU

Waterfall Development Method

13
ISTM 280, GWU

Pros and Cons of the Waterfall Method

Pros

Cons

Identifies systems
requirements long
before programming
begins

Design must be
specified on paper
before programming
begins
Long time between
system proposal and
delivery of new
system
14

ISTM 280, GWU

Parallel Development

15
ISTM 280, GWU

Alternatives to the SDLC

Rapid Application Development (RAD)

Phased Development
Prototyping
Throw-Away Prototyping

16
ISTM 280, GWU

Rapid Application Development

Critical elements

CASE tools
JAD sessions
Fourth generation/visualization programming
languages
Code generators

17
ISTM 280, GWU

Rapid Application Development Categories

Phased development

Prototyping

System prototyping

Throw-away prototyping

A series of versions

Design prototyping

Agile Development
Extreme Development

18
ISTM 280, GWU

How Prototyping Works

19
ISTM 280, GWU

Throwaway Prototyping

20
ISTM 280, GWU

Selecting the Appropriate Methodology

Clarity of User Requirements

Familiarity with Technology
System Complexity
System Reliability
Short Time Schedules
Schedule Visibility

21
ISTM 280, GWU

Information Systems Roles

Business analyst
System analyst
Infrastructure analyst
Change management analyst
Project manager

22
ISTM 280, GWU

Object-oriented approach
Classes and Objects

Class Template to define specific instances

or objects
Object Instantiation of a class
Attributes Describes the object
Behaviors specify what object can do

23
ISTM 280, GWU

Basic Characteristics of Object Oriented

Systems

Classes and Objects

Methods and Messages
Encapsulation and Information Hiding
Inheritance
Polymorphism and Dynamic Binding

24
ISTM 280, GWU

Object Oriented Systems Analysis and

Design

Use-case driven
Architecture Centric
Iterative and Incremental
The Unified Process

25
ISTM 280, GWU

The Project Planning Phase

Project Initiation and
Project Management
Lecture 2

Courtesy to
Dr. Dasgupta

26

Objectives

The Systems Development

Lifecycle (SDLC)
SDLC Phases
The Project Management Phase

Project schedule
Project Feasibility

27

IS Development Phases

28

Project Management

People

Organizing
Directing

Planned result

Scheduling
Budgeting

29

Participants in Development Project

30

Project Management Body of

Knowledge

Scope management

Time management

Human resource
management

Communications
management

Risk management

Procurement
management

Cost management
Quality
management

31

Project Initiation

Driving forces

Respond to opportunity
Resolve problem
Conform to directive

32

Project Initiation

Long-term IS strategic plan (top-down)

Weighted Scoring

Department managers or process

managers (bottom-up)

Response to outside forces

33

Activities of the Project Planning Phase

34

Producing Project Schedule

Develop work breakdown schedule

List of tasks required for project

Like an outline

Build a PERT/CPM chart

Assists in assigning tasks

Critical path method
Tracking GANTT chart

35

Figure
Graphical diagrams that depict project plans
(a) A Gantt Chart (b) A PERT chart

36

Comparison of Gantt and

PERT Charts

Gantt

Visually shows
duration of tasks
Visually shows time
overlap between
tasks
Visually shows slack
time

PERT

Visually shows
dependencies
between tasks
Visually shows
which tasks can be
done in parallel
Shows slack time by
data in rectangles
37

Requirements Determination
(Analysis)
Lecture 3
Courtesy to
Dr.Subhasish Dasgupta

38

The Analysis Phase

39

Activities of the Analysis Phase

and Key Questions

40

Requirement

A requirement is simply a statement of what

the system must do or what characteristics it
must have

41

Functional and Technical Requirements

System requirements all capabilities and

constraints

Functional requirements
Activities the system must perform
Based on procedures and business functions
Documented in analysis models

Nonfunctional or Technical requirements

Describes operating environment or performance
objectives
Documented in narrative descriptions of technical
requirements
42

Stakeholders

People with interest in system success

Three primary groups

Users (use system)

Clients (pay for system)
Technical staff (ensure system operation)

43

Users as Stakeholders

User roles
Horizontal - information flow across departments
Vertical - information needs of clerical staff, middle
management, and senior executives

Business users
Information users
Management users
Executive users
External users
Client stakeholders
Technical stakeholders

44

Techniques for Information Gathering

Objective of analysis phase is to understand

business functions and develop requirements

Original approach involved modeling of existing

system

Current approach involves identifying logical

requirements for new system

45

Use Cases Descriptions

Role of Use Cases

A use case is a set of activities that produce

some output result
Describes how the system reacts to an
event that triggers the system
Trigger -- event that causes the use case to
be executed
Event-driven modeling everything in the
system is a response to some triggering
event

Role of Use Cases

All possible responses to the event are

documented
Use cases are helpful when the situation is
complicated

Elements of a Use Case

Basic information

Name, number and brief description

Trigger event that causes the use case to being

Viewpoint of the use cases should be consistent

Major inputs and outputs

External trigger some from outside the system

Temporal triggers time-based occurrences

Sources and destinations

Goal is to be all inclusive

Details

Steps performed and the data inputs and outputs

Sample Use Case

Building Use Cases

Process of Developing Use

Cases

Identify the major use cases

Identify the major steps within each use
case
Identify elements within steps
Confirm the use case
Cycle through the above steps
iteratively

USE-CASE DIAGRAM

Use-Case Diagram Concepts

Summarizes all use cases (for the part

of the system being modeled) together
in one picture
Typically drawn early in the SDLC
Shows the associations between actors
and use cases

Integration of four UML

Diagrams

Use Case Diagram for

Appointment System

Syntax for Use-Case Diagram

Use-Case Diagram for

Specialized Actor

Extends or Uses Associations

Steps in Creating the Use

Case Diagram
1. Identify use cases
2. Draw the system boundary
3. Place use cases on the diagram
Group use cases into packages
Add special use case associations

4. Identify the actors

5. Add associations

Structural Modeling
Lecture 5
Courtesy to
Dr.Dasgupta

Purpose of Structural Models

Reduce the semantic gap between the real world

and the world of software
Create a vocabulary for analysts and users
Represent things, ideas, and concepts of importance
in the application domain

Classes

Templates for creating instances or objects

Concrete
Abstract
Typical examples:
Application domain, user interface, data structure, file structure,
operating environment, document, and multimedia classes

Attributes

Units of information relevant to the description

of the class
Only attributes important to the task should be
included

Operations

Action that instances/objects can take

Focus on relevant problem-specific operations
(at this point)

Relationships

Generalization

Aggregation

Enables inheritance of attributes and operations

Relates parts to wholes

Association

Miscellaneous relationships between classes

Responsibilities and
Collaborations

Responsibilities

Knowing
Doing

Collaboration

Objects working together to service a request

The Class Symbol

for the Class Diagram

Bank Account System Class Diagram

Enrollment Class Diagram

with Association Class

Class Diagram

Provides definition of system components

Contains important structural information for the

new system

Provides details describing database and objectoriented program

Consists of problem domain classes and

implementation classes

Class Diagram Concepts

A static model that shows the classes and

relationships among classes that remain
constant in the system over time
Resembles the ERD, but depicts classes
which include both behaviors and states,
while entities in the ERD include only
attributes
Scope not system wide, but pertaining to a
single use-case

Class Diagram for Managing

Appointments

Class Diagram Syntax

Method Types

Constructor methods create new instances of a class

Query methods determine the state of an object and
make information about that state available to the
system
Update methods will change the value of some or all
of the objects attributes, resulting in a change of
state

Multiplicity

Association Class

Aggregation and
Generalization Associations

Aggregation or Whole-Part Relationships

A Generalization/Specialization
Hierarchy for Motor Vehicles

Steps in Creating a Class

Diagram
1. Identify classes
2. Identify attributes and operations
3. Draw relationships between classes

Class Diagram for Customer

Places Order (1)

Class Diagram for Customer

Places Order (2)

Class Diagram for Customer

Places Order (3)