Nothing Special   »   [go: up one dir, main page]

Sadd Tama Na

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

Chapter 1: Introduc on to Systems Analysis and Design

Systems Development Life Cycle (SDLC)


The Planning Phase - Develop/receive a system request and conduct a feasibility analysis. Project Management
involves developing the work plan.
The Analysis Phase - Develop an analysis strategy, model the current system, formulate the new system, gather the
requirements, develop a system concept, and create a business model to represent business data and processes.
Finally, develop a system proposal.
The Design Phase - Develop a design strategy, design the architecture and interfaces, develop databases and file
specifica ons, and develop the program design to specify what programs to write and what each program will do.
The Implementa on Phase - Construct the system by building it by wri ng the programming code and tes ng it.
Install the system and train the users. Finally, support the system through maintenance.
The SDLC Process
The process consists of four phases
Each phase consists of a series of steps
Each phase is documented (deliverables)
Phases are executed sequen ally, incrementally, itera vely or in some other pa ern
Classes of Methodologies:
Structured Development - Waterfall - Parallel
Rapid Applica on Development RAD - Phased – Prototyping
Agile Development - extreme Programming - SCRUM
The Systems Analyst: Roles

The Systems Analyst: Skills


Agents Of Change - Mo vate & Train others

Characteris cs of Object Oriented Systems


Classes & Objects
Object (instance): instan a on of a class A ributes: informa on that describes the class
State: describes its values and rela onships at a point in me
Methods: the behavior of a class. Messages: informa on sent to an object to trigger a method (procedure call)
Polymorphism: the same message can have different meanings
Dynamic binding: type of object is not determined un l run me.
Contrast with sta c binding
The Unified Modeling Language, or UML, is a standard set of diagramming techniques
UNIFIED PROCESS PHASES
Incep on
Feasibility analyses performed, Workflows vary but focus is on business modeling & requirements gathering
Elabora on
Heavy focus on analysis & design, Other workflows may be included
Construc on - Focus on programming (implementa on)
Transi on--Focus on tes ng & deployment.

Feasibility analysis guides the organiza on in determining whether to proceed with a project.
Feasibility analysis also iden fies the important risks associated with the project that must be managed if the
project is approved.

Technical feasibility – Risk Assessment Analysis/Table (answer the ques on: “Can we build it?”)
Economic feasibility – Cost benefit analysis (answer the ques on: “Should we build the system?”)
Organiza onal feasibility – Organiza onal Structure/5 year strat or dev plan
(answer the ques on “If we build it, will they come?”)
Schedule Feasibility – GANTT or Project Schedule or WBS – PERT diagram (PM)
Ways to classify a project
Size, cost, purpose, length, risk, scope, economic value
The project sponsor(locale) is a key person proposing development or adop on of the new informa on
technology.
The approval commi ee reviews proposals from various groups and units in the organiza on and decides which
project to commit to developing.

Return on Investment: ra o of cash receipts divided by cash outlays; Money would earn if invested in other
opportuni es.
Break-Even Analysis: Use the figures for the year with the first posi ve overall NPV cash flow (the first year where
benefits exceed costs).
Project ini a on involves crea ng and assessing goals and expecta ons for a new system

Chapter 3: Requirements Determina on


Requirement: A statement of what the system must do or a characteris c it must have.
TYPES: Func onal: relates to a process or data
Non-func onal: relates to performance or usability
Both define the scope of the system.

Determining Requirements: Requirements are determined by systems analysts and business people together
Techniques for iden fying requirements: Interviews, Ques onnaires, Observa on, Joint applica on development
(JAD), Document analysis

REQUIREMENTS ANALYSIS STRATEGIES:

PROBLEM ANALYSIS ROOT CAUSE ANALYSIS


ask users to iden fy problems with the current system focus is on the cause of a problem, not its solu on
ask users how they would solve these problems create a priori zed list of problems
good for improving efficiency or ease-of-use try to determine their causes, then solu ons can be
develop.

Interview Strat – TOP-DOWN and BOTTOM-UP


High-level: Very general
Medium-level: Moderately Specific
Low-level: Very Specific
Joint Applica on Development:
Hosted by the facilitator: 10-20 users
1-2 scribes: prepared room
Ques onnaires/Survey-Instrument
The set of wri en ques ons May be paper-based or electronic
Document Analysis
Forms, Reports, and Policy Manuals

Observa on/Necessity
- Users/managers o en don’t remember everything they do.
- Behaviors may change when people are watched

Determining Requirements:
Done by systems analysts and business people
Techniques: Interviews, ques onnaires, observa on, JAD, document analysis

Requirements Analysis Strategies:


Problem analysis: iden fy and solve problems, improve efficiency/ease-of-use
Root cause analysis: focus on cause of the problem, priori ze, and develop solu ons

Alterna ve Techniques:
Concept Maps: show rela onships between concepts
User Stories, Story Cards & Task Lists: for agile development, capture func onal and non-func onal
requirements, low tech and easily updatable.

SUMMARY:
Func onal and non-func onal requirements determina on
Requirements analysis strategies: problem analysis, root cause analysis, dura on analysis, ac vity-based
cos ng analysis, informal benchmarking analysis, outcome analysis, technology analysis, and ac vity
elimina on
Requirements gathering techniques: interviews, joint applica on development, ques onnaires,
document analysis, and observa on
Alterna ve requirements documenta on techniques: concept maps, story cards, and task lists
The system proposal

You might also like