ISTM 280, GWU

1

Introduction to Systems Analysis and Design

Lecture 1 Courtesy Subhasish Dasgupta

ISTM 280, GWU

2

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.

ISTM 280, GWU

3

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.

ISTM 280, GWU

4

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

ISTM 280, GWU

5

Project Phases

Planning Why build the system?

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

Design How will the system work?

Implementation System delivery

ISTM 280, GWU

6

Identifying business value Analyze feasibility Develop work plan Staff the project Control and direct project

Planning

ISTM 280, GWU

7

Analysis Information gathering Process modeling Data modeling

Analysis

ISTM 280, GWU

8

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

Design

ISTM 280, GWU

9

Construction Installation

Implementation

ISTM 280, GWU

10

Processes and Deliverables

Process Product

Planning

Analysis

Design

Implementation

Project Plan

System Proposal

System Specification

New System and Maintenance Plan

ISTM 280, GWU

11

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.

ISTM 280, GWU

12

Structured Design

Projects move methodically from one to the next step

Generally, a step is finished before the next one begins

ISTM 280, GWU

13

Waterfall Development Method

ISTM 280, GWU

14

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

ISTM 280, GWU

15

Parallel Development

ISTM 280, GWU

16

Alternatives to the SDLC

Rapid Application Development (RAD) Phased Development Prototyping Throw-Away Prototyping

ISTM 280, GWU

17

Rapid Application Development

Critical elements CASE tools JAD sessions Fourth generation/visualization programming

languages Code generators

ISTM 280, GWU

18

Rapid Application Development Categories

Phased development A series of versions

Prototyping System prototyping

Throw-away prototyping Design prototyping

Agile Development Extreme Development

ISTM 280, GWU

19

How Prototyping Works

ISTM 280, GWU

20

Throwaway Prototyping

ISTM 280, GWU

21

Selecting the Appropriate Methodology

Clarity of User Requirements Familiarity with Technology System Complexity System Reliability Short Time Schedules Schedule Visibility

ISTM 280, GWU

22

Information Systems Roles

Business analyst System analyst Infrastructure analyst Change management analyst Project manager

ISTM 280, GWU

23

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

ISTM 280, GWU

24

Basic Characteristics of Object Oriented Systems Classes and Objects Methods and Messages Encapsulation and Information Hiding Inheritance Polymorphism and Dynamic Binding

ISTM 280, GWU

25

Object Oriented Systems Analysis and Design Use-case driven Architecture Centric Iterative and Incremental The Unified Process

The Project Planning Phase Project Initiation and

Project ManagementLecture 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

Cost management

Quality management

Human resource management

Communications management

Risk management

Procurement 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

38

Requirements Determination (Analysis)

Lecture 3 Courtesy to

Dr.Subhasish Dasgupta

39

The Analysis Phase

40

Activities of the Analysis Phase and Key Questions

41

Requirement

A requirement is simply a statement of what the system must do or what characteristics it must have

42

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

43

Stakeholders

People with interest in system success

Three primary groups Users (use system) Clients (pay for system) Technical staff (ensure system operation)

44

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

45

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

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

External trigger some from outside the system Temporal triggers time-based occurrences

Viewpoint of the use cases should be consistent Major inputs and outputs

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 ModelingLecture 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

Enables inheritance of attributes and operations Aggregation

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 object-oriented 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 Diagram1. 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)