fainal exam systems analysis and design.pdf
TRANSCRIPT
-
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)