System Analysis and Design · Systems Development Life Cycle (SDLC) •SDLC is the process of...
Transcript of System Analysis and Design · Systems Development Life Cycle (SDLC) •SDLC is the process of...
System Analysis and Design
INTRO
• 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