System Analysis and Design

INTRO

• Name: @class

• HP : @class (SMS/WA)

• Email: kumpultugasnilai@gmail.com

Introduction

• Make sure your Mobile Phone in silent mode

• Using dress code based on Tel-U rules

• Attendance• > 75 %

• < 15 miniutes

Class Rules!

Overview

SADBM

DM

PM

MIS

OQM

Syllabus

Week Topics

1 Introduction to SDLC, Systems Analyst’ Roles & Requirement Determination

2 System Modelling: using structured and object-oriented

3 System Requirement using Use Case Diagram and Use Case Scenario

4 Process Requirement using Activity Diagram

5 Behavior Analysis and Design using Sequence Diagram

6 Object Analysis and Design using Class Diagram

7 User Interface Design with Human Computer Interaction

8 Mid-Test

Syllabus

Week Topics

9 Project Report : Specify Problem and IS Solution

10 Project Report : Modelling Business & System Requirements with UCD & UCS

11 Project Report : Modelling Business & System Processes with AD & SD

12 Project Report : Modelling Data and Operation with CD

13 Project Report : User Interface Design

14 Final Group Presentation

15 Final Group Presentation

16 Final - Test

References

• Main • Kenneth E. Kendall, Julie E. Kendall (2014), Systems Analysis and Design, 9th

Edition, Prentice Hall

• Support• Howard Podeswa (2010), UML for IT Business Analyst, Second Edition,

Cengage Learning• Whitten & Bentley (2007) Systems Analysis and Design Methods, 7th Edition,

McGraw-Hill• Alan Dennis, Barbara H Wixom, David Tegarden (2005), System Analysis and

Design with UML Version 2.0

Tasks & ScoringTasks Description Time Score

Individual Assignment

Resuming UML : UCD, UCS, AD, SD, CD Week 3 10%

Group Assignment

Building System Model using UML for specific case Week 4 - 7 10 %

Group Project Analyzing and Designing IS Solution with UML Week 9 - 15 40 %

Mid-Test Review from SDLC to Design Week 8th 20 %

Final-Test Review Project Week 16th 20 %

System Analysis and Design

Week 1

1-11

Introduction to SDLC and System Analyst Roles

Slide 12

Need for Systems Analysis and Design

• Many failed systems were abandoned because analysts tried to build wonderful systems without understanding the organization.

• Installing a system without proper planning leads to great user dissatisfaction and frequently causes the system to fall into disuse

The primarily goal is to create value for the organization.

Slide 13

Need for Systems Analysis and Design

• A series of processes systematically undertaken to improve a business through the use of computerized information systems

• The systems analyst is a key person analyzing the business, identifying opportunities for improvement, and designing information systems to implement these ideas.

1-14

Roles of the Systems Analyst

• The analyst must be able to work with people of all descriptions and be experienced in working with computers

• Three primary roles:• Consultant

• Give a new perspective

• Supporting expert• Understand technologies used for business

• Agent of change• Develop, advocate, and facilitate change in organization

1-15

Qualities of the Systems Analyst

• Problem solver

• Communicator

• Strong personal and professional ethics

• Self-disciplined and self-motivated

1-16

Systems Development Life Cycle (SDLC)

• SDLC is the process of understanding how an information system (IS) can support business needs, designing the system, building it, and delivering it to the users.

• The lifecycle moves systematically through phases where each phase has a standard set of techniques and activities

• Produces deliverables/output at each phases• Final results is actual information system• Managed through a project

• SDLC is a process gradual refinement• Each phase refines and elaborates on the work done previously• Deliverable from analysis phase become input and can be refined in design

phase

1-17

The Seven Phases of the Systems Development Life Cycle (Figure 1.1)

Considering HCI in each phases

Kendall & Kendall (2014)

1-18

1. Identifying Problems, Opportunities, and Objectives

• Activities:• Interviewing user management

• Summarizing the knowledge obtained

• Estimating the scope of the project

• Documenting the results

• Output: • Feasibility report containing problem definition and objective summaries

from which management can make a decision on whether to proceed with the proposed project

1-19

2. Determining Human Information Requirements

• Activities:• Interviewing• Sampling and investing hard data• Questionnaires• Observe the decision maker’s behavior and environment• Prototyping• Learn the who, what, where, when, how, and why of the current system

• Outputs:• Know the business functions • The analyst understands how users accomplish their work when interacting with a computer and

how to make the new system more useful and usable (Functional & Non Functional Requirement)• Have complete information on the:

• People, Goals, Data, Process (Procedure) involved

1-20

3. Analyzing System Needs

• Activities:• Create data flow, activity, or sequence diagrams

• Complete the data dictionary

• Analyze the structured decisions made

• Prepare and present the system proposal

• Output: • Data and process model for ‘as-is’ system

• System Proposal containing recommendation on what, if anything, should be done (model for ‘to-be system’)

1-21

4. Designing the Recommended System

• Activities:• Design procedures for data entry

• Design the human-computer interface

• Design system controls

• Design database and/or files

• Design backup procedures

• Output• Database, program, and interface design

• System specification (hardware and software)

1-22

5. Developing and Documenting Software

• Activities:• System analyst works with programmers to develop any original software

• Works with users to develop effective documentation

• Programmers design, code, and remove syntactical errors from computer programs

• Document software with help files, procedure manuals, and Web sites with Frequently Asked Questions

• Output:• Computer programs

• System documentation

1-23

6. Testing and Maintaining the System

• Activities:• Test the information system

• System maintenance

• Maintenance documentation

• Output:• Problems, if any

• Updated programs

• Documentation

1-24

7. Implementing and Evaluating the System

• Activity:• Train users

• Analyst plans smooth conversion from old system to new system

• Review and evaluate system

• Output:• Trained personnel

• Installed system

System Development Methodologies

What Is a Methodology?

• A methodology is a formalized approach or series of steps to implementing the SDLC.

• The methodology will vary depending on whether the emphasis is on businesses processes or on the data that supports the business.

• Process-centered (system concept as a set of process with information flowing into and out of the process)

• Data centered (system concept as data models)

• Object-oriented (balance emphasis on data and proses)

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

Development Methodology Category

• Structured Design• Waterfall

• Parallel

• Rapid Application Development (RAD)• Phased Development

• Prototyping

• Throw-Away Prototyping

• Agile Development• Extreme Programming

• Scrum

Structured Design

• Projects move methodically from one to the next step

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

• This design methodology introduces the use of formal modeling or diagramming techniques to describe a system’s basic business processes and follows a basic approach of two structured design categories.

Waterfall Development Method

With waterfall

development-

based

methodologies, the

analysts and users

proceed

sequentially from

one phase to the

next.

Slide 30

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

Parallel Development

• A general design for the entire system is performed and then the project is divided into a series of distinct subprojects.

Rapid Application Development (RAD)

• RAD-based methodologies adjust the SDLC phases to get some part of system developed quickly and into the hands of the users.

• Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, such as CASE (computer-aided software engineering) tools.

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

RAD

• RAD Categories:

• Phased development• A series of versions

• Prototyping• System prototyping

• Throw-away prototyping• Design prototyping

Phased Development• This methodology breaks the overall

system into a series of versions that are

developed sequentially.

• The team categorizes the requirements

into a series of versions, then the most

important and fundamental requirements

are bundled into the first version of the

system.

• The analysis phase then leads into design

and implementation; however, only with

the set of requirements identified for

version 1.

Prototyping

• Prototyping-based methodologies perform the analysis, design and implementation phases concurrently.

• All three phases are performed repeatedly in a cycle until the system is completed.

• A prototype is a smaller version of the system with a minimal amount of features.

Throwaway Prototyping

• Throwaway prototyping methodologies are similar to prototyping based methodologies.

• The main difference is that throwaway prototyping IS completed during a different point in the SDLC.

• Has relatively thorough analysis phase.

Agile Development

• This category focuses on streamlining the SDLC by eliminating much of the modeling and documentation overhead and the time spent on those tasks.

• Projects emphasize simple, iterative application development.

• This category uses extreme programming, which is described next.

CORE PRACTICES :• Short releases• 40-hour workweek• Hosting on onsite customer• Using pair programming

Extreme Programming (XP)• Extreme Programming (XP)

was founded on four core values:

• Communication

• Simplicity

• Feedback

• Courage

• Key principles of XP include:

• Continuous testing

• Simple coding

• Close interaction with the end users to build systems very quickly

Scrum

Slide 40

Criteria for Selecting a Methodology

1-41

Object-Oriented (O-O) Systems Analysis and Design

• Alternate approach to the structured approach of the SDLC that is intended to facilitate the development of systems that change rapidly in response to dynamic business environments

• Analysis is performed on a small part of the system followed by design and implementation

• The cycle repeats with analysis, design, and implementation of the next part and this repeats until the project is complete

• Use UML Modelling Standard

1-42

Unified Modeling Language (UML) Phases

1-43

When to Use SDLC (Structured Design)

• Systems have been developed and documented using SLDC

• It is important to document each step

• Upper level management feels more comfortable or safe using SDLC

• There are adequate resources and time to complete the full SDLC

• Communication of how new systems work is important

1-44

When to Use Agile

• There is a project champion of agile methods in the organization

• Applications need to be developed quickly in response to a dynamic environment

• A rescue takes place (the system failed and there is no time to figure out what went wrong)

• The customer is satisfied with incremental improvements

• Executives and analysts agree with the principles of agile methodologies

1-45

When to Use Object-Oriented

• The problems modeled lend themselves to classes

• An organization supports the UML learning

• Systems can be added gradually, one subsystem at a time

• Reuse of previously written software is a possibility

• It is acceptable to tackle the difficult problems first

Requirement Determination

• A statement of what the system must do

• A statement of characteristics the system must have

• Focus is on business user needs during analysis phase

• Requirements will change over time as project moves from analysis to design to implementation

What is a Requirement?

Results of Incorrect Requirements

• The system may cost more than projected.

• The system may be delivered later than promised.

• The system may not meet the users’ expectations and they may not to use it.

• Once in production, costs of maintaining and enhancing system may be excessively high.

• The system may be unreliable and prone to errors and downtime.

• Reputation of IT staff is tarnished as failure will be perceived as a mistake by the team.

• Functional Requirements• A process the system has to perform

• Information the system must contain

• Nonfunctional Requirements• Behavioral properties the system must have

• Operational

• Performance

• Security

• Cultural and political

Requirement Types

Functional Requirements

Nonfunctional Requirements

• Requirements definition report• Text document listing requirements in outline form

• Priorities may be included

• Key purpose is to define the project scope: what is and is not to be included.

Documenting Requirements

Determining Requirements

• Participation by business users/experts and IT analyst is essential• If done only by IT analyst, may not address true business needs

• If done only by business experts, may not take advantage of technology

• Three techniques help users discover their needs for the new system:• Business Process Automation (BPA)

• Business Process Improvement (BPI)

• Business Process Reengineering (BPR)

• Understand the “As-Is” system, identify improvement opportunities, and develop the “To-Be” system concept

Slide 54

Requirements Analysis Techniques

• Business process automation (BPA) • Doesn’t change basic operations

• Automates some operations

• BPA Techniques• Problem Analysis

• Root Cause AnalysisGoal:

Efficiency

for users

Slide 55

Requirements Analysis Techniques

• Business process improvement (BPI) • How an organization operates

• Changes operation with new techniques

• Can improve efficiency and effectiveness

Goal:

Efficiency

and

effectiveness

for users

• Components: • Duration Analysis

• Time to perform each process

• Activity-Based Costing• Examines major process costs

• Informal Benchmarking• Studies how other organizations

perform business processes

Slide 56

Requirements Analysis Techniques

Business Process Reengineering (BPR)

• Changes how the organization does certain operations

• Consists of• Outcome Analysis

• Technology analysis

• Activity Elimination

Goal:

Radical

redesign of

business

processes

Slide 57

Analysis Characteristics

Requirements Gathering

• Interactive Methods• Interviewing

• Joint Application Design (JAD)

• Questionnaires

• Unobtrusive Methods• Document analysis (Quantitative & Qualitative)

• Observation (STROBE - a technique for observing the decision-maker’s physical environment)

Slide 58

Slide 59

Interviews -- Five Basic Steps

1. Selecting interviewees

2. Designing interview questions

3. Preparing for the interview

4. Conducting the interview

5. Post-interview follow-up

Slide 60

1. Selecting Interviewees

• Based on information needed

• Often good to get different perspectives• Managers

• Users

• Ideally, all key stakeholders

Slide 61

2. Designing Interview Questions

• Unstructured interview• Broad, roughly defined

information

• Structured interview• More specific

information

Questioning Strategies

2. Designing interview questions

Slide 62

Types of Questions Examples

Closed-Ended Questions * How many telephone

orders are received per day?

* How do customers place orders?* What additional information

would you like the new systemto provide?

Open-Ended Questions * What do you think about the current system?

* What are some of the problemsyou face on a daily basis?

* How do you decide what types ofmarketing campaign to run?

Probing Questions * Why?

* Can you give me an example?* Can you explain that in a bit

more detail?

Slide 63

3. Interview Preparation Steps

• Prepare general interview plan

• List of question

• Anticipated answers and follow-ups

• Confirm areas of knowledge

• Set priorities in case of time shortage

• Prepare the interviewee

• Schedule

• Inform of reason for interview

• Inform of areas of discussion

Slide 64

4. Conducting the Interview

• Appear professional and unbiased

• Record all information

• Check on organizational policy regarding tape recording

• Be sure you understand all issues and terms

• Separate facts from opinions

• Give interviewee time to ask questions

• Be sure to thank the interviewee

• End on time

PRACTICAL TIPSDon’t worry, be happyPay attentionSummarize key pointsBe honestWatch body language

Slide 65

5. Post-Interview Follow-Up

• Prepare interview notes

• Prepare interview report

• Look for gaps and new questions

Slide 66

Interview Report

INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________

Interviewer _______________

Date _______________

Primary Purpose:

Summary of Interview:

Open Items:

Detailed Notes:

Slide 67

JAD Key Ideas

• Allows project managers, users, and developers to work together

• May reduce scope creep by 50%

• Avoids requirements being too specific or too vague

Slide 68

Joint Application Design (JAD) Important Roles• Facilitator

• sets the meeting agenda and guides the discussion

• Scribe• assist the facilitator by recording notes, making copies, etc.

• Project team, users, and management

Slide 69

Joint Application Design (JAD) Setting

• U-Shaped seating

• Away from distractions

• Whiteboard/flip chart

• Prototyping tools

• e-JAD

Slide 70

The JAD Session

• Tend to last 5 to 10 days over a three week period

• Prepare questions as with interviews

• Formal agenda and groundrules

• Facilitator activities

• Keep session on track

• Help with technical terms and jargon

• Record group input

• Help resolve issues

• Post-session follow-up

Slide 71

Managing Problems in JAD Sessions

• Reducing domination

• Encouraging non-contributors

• Side discussions

• Agenda merry-go-round

• Violent agreement

• Unresolved conflict

• True conflict

• Use humor

Slide 72

Questionnaire Steps

• Selecting participants

• Using samples of the population

• Designing the questionnaire

• Careful question selection

• Administering the questionnaire

• Working to get good response rate

• Questionnaire follow-up

• Send results to participants

Slide 73

Good Questionaire Design

• Begin with nonthreatening and interesting questions.

• Group items into logically coherent sections.

• Do not put important items at the very end of the questionnaire.

• Do not crowd a page with too many items.

• Avoid abbreviations.

• Avoid biased or suggestive items or terms.

• Number questions to avoid confusion.

• Pretest the questionnaire to identify confusing questions.

• Provide anonymity to respondents.

Slide 74

Document Analysis

• Provides clues about existing “as-is” system

• Typical documents• Quantitative

• Qualitative

• Look for user additions to forms

• Look for unused form elements

5-75Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Analyzing Quantitative Documents

• Reports used for decision making

• Performance reports

• Records

• Data capture forms

• Ecommerce and other transactions

5-76Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Analyzing Qualitative Documents

• Key or guiding metaphors

• Insiders vs. outsiders mentality

• What is considered good vs. evil

• Graphics, logos, and icons in common areas or web pages

• A sense of humor

• Email messages and memos

• Signs or posters on bulletin boards

• Corporate websites

• Manuals

• Policy handbooks

Slide 77

Observation

• Users/managers often don’t remember everything they do

• Checks validity of information gathered other ways

• Behaviors change when people are watched

• Careful not to ignore periodic activities

• Weekly … Monthly … Annual

Selecting the Appropriate Techniques

Slide 78

Summary

• There are three primary roles of system analyst; consultant, supporting expert, and agent of change

• There are seven phases of SDLC; Identifying problems, requirement gathering, system analysis, system design, development, testing, implementation and evaluation

• There are three major development methodologies: the waterfall method (structured approach), Agile approach, and the Object-Oriented approach

• There are three technique for requirement analysis; BPA, BPI, BPR

• There are five information gathering technique; interview, JAD, questionnaire, document analysis, and observation