itec 3010 all slides

1

1

ITEC 3010: Systems Analysis and Design I

Instructor: Dr. Luiz Marcio Cysneiros

Class site: http://www.math.yorku.ca/~cysneiro/courses.htm

Office: TEL Building 3053

Email: [email protected]

http://www.math.yorku.ca/~cysneiro/courses.htm

2

General Info.

• Text: “Systems Analysis and Design in a Changing World” by John Satzinger, Robert Jackson and Stephen Burd 3rd / 4th / 5th edition

– Current available 6th edition. Not the best one to use

– Best Editions to use : 5th and 3rd

• Office Hours: Tuesday: 4:00 PM to 6:00 PM and Wednesday 2:00 PM to 3:30 PM

Phone: 416-736-2100, ext. 33886 Email: [email protected]


2

6Th Edition – Lecture x Chapter correlation

Lecture Chapter

1 1

2 8/9

3 8/9

4 2 + Online Chapter B

5 2/3/4 + Online Chapter B

6 8

7 3/4/5

8 N/A

9 11

10/11 6/7

3 http://www.math.yorku.ca/~cysneiro/courses.htm

4

Marking Scheme

• Midterm (in class): 40% • 2 Assignments ( 1st 5%, 2nd 5%) : 10%

• Final: 50%

• Midterm and Final will be closed book

• If a student gets less than 38% in the Final he/she fails the course regardless the average

• Rounding Policy : For example : • 49.4 goes to 49 • 49.5 or higher goes to 50

Lecture notes will be made available at: http://www.math.yorku.ca/~cysneiro/courses.html


3



4



5



6

11

Course Objectives

• To provide you with new ways of looking at information in the world in order to solve business problems

• To introduce you to concepts and methods of System Analysis and design (SAD)

• To describe the systems development life cycle (SDLC)

• To teach you effective methods for gathering essential information during system analysis

• To teach you effective methods for designing systems to solve problems effectively using technology


12

Denys Lasdun – “Our job is to give the client, on time and on cost, not what he wants, but what he never dreamed he wanted; and when he gets it, he recognizes it as something he wanted all the time”


7

13

Course Topics

• Introduction to systems analysis and design – the analyst as problem solver

– required skills of systems analysts

– types of jobs and the analyst’s role

– Example: Rocky mountain outfitters

• The analyst as project manager – the systems development life cycle (SDLC)

• planning phase

• analysis phase

• design phase

• implementation phase

• support phase

– the project team


14

Topics (continued)

• Approaches to Systems Development – Methodologies and Models

– 2 approaches:

• structured approach

• object-oriented approach

– Waterfall Models for SDLC

– other variations

– computer-aided software engineering (CASE)


8

15

Topics (continued)

• Identifying System Requirements – stakeholders

– Methods - e.g. questionnaires, interviews, observation, build prototypes, others

• Modelling System Requirements – types of models - e.g. mathematical, descriptive, graphical

– identifying and modeling events

– identifying and modeling “things” in the world

– traditional and object-oriented methods


16

Topics (continued)

• System Design – going from requirements to design

– elements of design

– approaches

• structured approach

• object-oriented approach

– design of inputs and outputs

– designing databases

– designing user interfaces


9

17

The World of the Modern System Analyst

• System Analysis: the process of understanding and specifying in detail what the information system should do

• System Design: the process of specifying in detail how the many component parts of the information system should be implemented

• System Analyst: A professional who used analysis and design techniques to solve business problems (involving information technology)

• A theme of the course: developing effective information systems is much more than just writing computer programs (involves cognitive skills in understanding problems and knowing where computer technology best “fits in”)


18

Research and understand the problem

Verify that the benefits of solving the problem outweigh the costs

Develop a set of possible solutions (alternatives)

Decide which solution is best, and make a recommendation

Design the details of the chosen solution

Implement the solution

Monitor to make sure the you Obtain the desired results

The Analysts’ Approach to Problem Solving (Figure 1-1 in the text)

10

19

Thinking in terms of “Systems”

• What is a system?

A system is a collection of interrelated components (subsystems) that function together to achieve some outcome (e.g. biological system, computer system, social system)

An information system is a collection of interrelated components that collect, process, store and provide as output the information needed to complete business tasks (e.g. payroll system)

http://www.math.yorku.ca/~cysneiro/

courses.htm

20

Characteristics of Systems

• Systems are made up of interrelated subsystems (e.g. a nuclear reactor is composed of boilers, reactor components etc.)

• Functional decomposition – dividing a system into components based on subsystems (which are in turn further divided into subsystems)

• System boundary – the separation between a system and its environment (where inputs and outputs cross)

• Automation boundary – separation between the automated part of system and the manual part


11

21

General Depiction of a System

input

output

boundary

interrelationship

subsystem

output


input

subsystem subsystem

subsystem

subsystem

22

Overall production system (supersystem) (figure 1-2 in the text)


12

23

Figure 1-4: The system boundary and the automation boundary


24

“Systems” Thinking

• Being able to identify something as a system

• Involves being able to identify subsystems

• Identifying system characteristics and functions

• Identifying where the boundaries are (or should be)

• Identifying inputs and outputs to systems

• Identifying relationships among subsystems


13

25

Information Systems and Component Parts

Figure 1-3

Systems Analysis and Design in a Changing World, 5th Edition 25

26

Types of Information Systems

• Transaction processing systems (TPS)

– Capture and record information about the transactions that affect the organization (e.g. the sale of an item, a withdrawal from an ATM etc.)

• Management Information Systems (MIS)

– Take information captured by the transaction processing system and produce reports management needs for planning and controlling business

http://www.math.yorku.ca/~cysneiro/

courses.htm

14

27

• Executive Information Systems (EIS)

– Provide information for executives to use in strategic planning (could be from organizational database, or outside sources like stock market reports)

• Decision Support Systems (DSS)

– Support human decision making and allows users to explore the potential impact of available options or decisions (e.g. can ask “what if”)

– Closely related to “expert systems” or “knowledge-based” systems


28

Required Skills of the Systems Analyst

• Technical Knowledge and Skills

• Computers and how they work in general

• Programming languages

• Devices that interact with computers

• Communications networks

• Database and database management systems

• Operating systems and utilities

Tools: software products used to help develop analysis and design specifications and completed system components • e.g. Microsoft Access, Integrated development

environments, computer-supported system engineering (CASE) tools


15

29

• Business Knowledge and Skills • What activities and processes do organizations

perform?

• How are organizations structured?

• How are organizations managed?

• What type of work (activity) is done in the organization? (e.g. hospital, bank etc.)

• Who are the “actors” doing the activities

About the organization (e.g. company) the system analyst needs to know: • What the specific organization does

• What makes it successful

• What its strategies and plans are

• What its tradition (“culture”) and values are


30

• People Knowledge and Skills

• Single most important interpersonal skill: • To communicate clearly and effectively with others!

• Since analysts work on teams with others (e.g. team members, clients etc.) must understand about people: • How people think

• How people learn

• How people react to change

• How people communicate

• How people work (“activities” and “actors”)

• Other areas: • Skill in interviewing, listening and observing

• Good written and oral presentation

• Being able to work in a team


16

31

Typical Job Titles

• Programmer/analyst

• Business systems analyst

• System liaison

• End-user analyst

• Business consultant

• Systems consultant

• System support analyst

• System designer

• Software engineer

• System architect http://www.math.yorku.ca/~cysneiro/

courses.htm

32

Typical Job Ad: Systems Analyst – Distribution Center

We are the world’s leading manufacturer of women’s apparel products. Our organization in the Far East has openings for a Systems Analyst

Requirements:

• Bachelor’s degree in Computer Science, Business Administration or closely related field with 5 (+) years of working experience

• In-depth understanding of Distribution and Manufacturing concepts (Allocation, Replenishment, Floor Control, Production Scheduling)

• Working knowledge of project management and all phases of the software development life cycle

• Experience with CASE tools, PC and Bar Code equipment

• Working knowledge of AS/400 and/or UNIX environment with the languages C++, Java and/or COBOL are desirable


17

33

Components of an Information Systems

Strategic Plan

Figure 1-7


34

Rocky Mountain Outfitters (RMO) and Its Strategic

Information Systems Plan • RMO sports clothing manufacturer and distributor

about to begin customer support system project

• Need to understand the nature of the business, approach to strategic planning, and objectives for customer support system

• RMO system development project used to demonstrate analysis and design concepts

34 http://www.math.yorku.ca/~cysneiro/

courses.htm

18

35

Introduction to Rocky Mountain Outfitters (RMO) Business

• Began in Park City, Utah supplying winter sports clothes to local ski shops

• Expanded into direct mail-order sales with small catalog—as catalog interest increased, opened retail store in Park City

• Became large, regional sports clothing distributor by early 2000s in Rocky Mountain and Western states

• Currently $180 million in annual sales and 600 employees and two retail stores

• Mail-order revenue is $90 million; phone-order revenue is $50 million 35

36

Early RMO Catalog Cover (Fall 1978)

Figure 1-8


courses.htm

19

37

Current RMO Catalog Cover (Fall 2010)

Figure 1-9


courses.htm

38

RMO Strategic Issues • Innovative clothing distributor; featured products

on Web site ahead of competitors

• Original Web site now underperforming

– Slow, poor coordination with in-house, poor supply chain management, poor technical support

• Market analysis showed alarming trends

– Sales growth too slow, age of customers increasing, Web sales small percentage of total


courses.htm

20

39

RMO Strategic Issues (continued)

• Enhanced Web site functions

– Add specific product information, weekly specials, and all product offerings

• Detailed IS strategic plan

– Supply chain management

– Customer relationship management


courses.htm

40

RMO Current Organization

Figure 1-10


courses.htm

21

41

RMO Locations

Figure 1-11


42

Existing RMO Systems

• Small server cluster system

– Supports inventory, mail-order, accounting, and human resources

– High capacity network connects distribution and mail-order sites

• LANs and file servers

– Supports central office functions, distribution centers, and manufacturing centers


22

43

Existing RMO Systems (continued)

• Supply Chain Management System

– Client/Server system in C++ and DB2

• Mail Order System

– Mainframe COBOL/CICS. Unable to handle phone orders

• Phone order system

– Oracle and Visual Basic system built 6 years ago

• Retail store systems

– Eight-year-old point-of-sale and batch inventory package, overnight update with mainframe


44

Existing RMO Systems (continued)

• Office systems

– LAN with office software, Internet, e-mail

• Human resources system

– Thirteen-year-old mainframe-based payroll and benefits

• Accounting/finance system

– Mainframe package bought from leading vendor

• Web Catalog and Order System

– Outside company until 2011. Irregular performance

44

23

45

The Information Systems Strategic Plan

• Supports RMO strategic objectives

– Build more direct customer relationships

– Expand marketing beyond Western states

• Plan calls for a series of information system development and integration projects over several years

• Project launch: New customer support system to integrate phone orders, mail orders, and direct customer orders via Internet

45

46

RMO Technology Architecture Plan

• Distribute business applications

– Across multiple locations and systems

– Reserve data center for Web server, database, and telecommunications

• Strategic business processes via Internet

– Supply chain management (SCM)

– Direct customer ordering via dynamic Web site

– Customer relationship management (CRM)

• Web-based intranet for business functions


courses.htm

24

47

RMO Application Architecture Plan

• Supply chain management (SCM)

– Product development, product acquisition, manufacturing, inventory management

• Customer support system (CSS)

– Integrate order-processing and fulfillment system with SCM

– Support customer orders (mail, phone, Web)

• Strategic information management system – Extract and analyze SCM and CSS information for

strategic and operational decision making and control


courses.htm

48

RMO Application Architecture Plan (continued)

• Retail store system (RSS)

– Replace existing retail store system with system integrated with CSS

• Accounting/finance system

– Purchase intranet application to maximize employee access to financial data for planning and control

• Human resources (HR) system

– Purchase intranet application to maximize employee access to human resources forms, procedures, and benefits information


courses.htm

25

49

Timetable for RMO Strategic Plan

Figure 1-13

49

50

System Development

• Project: a planned undertaking that has a beginning and an end, and which produces a predetermined result or product

• Information System development project: planned undertaking that produces a system

• Basic activities in development of any new system: – Analysis – to understand information needs

– Design – define the system architecture (based on needs)

– Implementation – the actual construction of the system


1

1

ITEC 3010

Lecture 2

2

Approaches to System Development

• System Development Methodology

– Comprehensive guidelines to follow for completing every activity in the system development life cycle, including specific models, tools and techniques

– May contain instructions about how to use models, tools and techniques

– We will examine a number of different methodologies for system development

2

3

• Models – Model: A representation of some important aspect of the real

world

– Models used in system development include representations of inputs, outputs, processes, data, objects, object interactions, locations, networks, and devices etc.

– Most models are graphical – diagrams and charts

– Models of system components

• Flow chart

• Data flow diagram (DFD)

• Entity-relationship diagram (ERD)

• Structure chart

• Use case diagram

• Class diagram

• Sequence diagram

– Models to manage the development process

• PERT chart

• Gantt chart

• Organizational hierarchy chart

4

• Tools

– Tool: Supportive software that helps create models or other components required in the project

– Examples of tools • Project management application

• Drawing/graphics application

• Word processor/text editor

• Computer-aided system engineering (CASE) tools

• Integrated development environment (IDE)

• Database management application

• Reverse-engineering tool

• Code generator tool

3

5

• Techniques

– Technique: a collection of guidelines that help the analyst complete a system development activity or task

– Examples of techniques • Strategic planning techniques

• Project management techniques

• User interviewing techniques

• Data-modeling techniques

• Relational database design techniques

• Structured analysis technique

• Structured programming technique

• Software-testing techniques (e.g. usability testing)

• Object-oriented analysis and design techniques

6

4

7

Two Approaches to System Development

• the basis of virtually all methodologies

• Approaches

– The structured approach

• System development using structured programming, structured analysis, and structured design techniques

– Object-oriented approach

• An approach to systems development that views an information system as a collection of interacting objects that work together to accomplish tasks

8

The Structured Approach

• The structured approach is made up of:

1. Structured programming

2. Structured design

3. Structured analysis

• Also known as SADT (Structured Analysis and Design Techniques)

• Before late 90’s you’d probably learn “structured programming” in your first programming course

• “structured analysis” evolved in the 1980’s (for stage prior to programming)

5

9

Structured Programming

• Structured program – A program or program module that has one beginning

and one ending, and each step in the program execution consists of one of the following

• Sequence (of program statements)

• Decision (where one set of statements or another executes)

• Repetition (of a set of statements)

– Related to concept of top-down programming • Division of complex problems into a hierarchy of smaller, (more

manageable) program modules

• Top program “calls” lower-level modules

• Lower level modules deal with lower-level detail

• Makes programs much easier to write and understand

• Module: collection of instructions to accomplish some logical function or task (“modular programming”) – e.g. Procedures/functions in a programming language

10

6

11

12

Structured Design

• Structured design – A technique providing guidelines for deciding what the

set of programs should be, what each program should accomplish, and how the programs should be organized into a hierarchy

– Related to (similar principles) as structured programming, but here looking at a larger level of how program modules themselves are organized

– Top-down approach again • start with highest level functions – top-level and break down

into lower level program modules (lower level details goes below)

– Use of a structure chart helps • A graphical model showing the hierarchy of program modules

produced in a structured design

7

13

14

Notes on structured design

• By breaking a complex problem down into sub-problems one can program very complex systems (e.g. space shuttle launch)

– Can hand off modules to other teams (at other locations)

– Specify what want to go as input to the module and what want the module to return

– The other team takes care of the details of their module(s)

8

15

Structured Analysis

• Structured analysis – a techniques to help define – What the system needs to do (processing requirements)

– What data the system needs to store and use (data requirements)

– What inputs and outputs are needed

– How the functions work together to accomplish tasks

• Key graphical model used – data flow diagram (DFD) – Shows inputs, processes, storage and outputs and how

they function together

– Based on activities (processes) and data that flow in and out of them

16

BOOK DATA

HANDLE ORDER

CUSTOMER DATA CUST.

Square

Example of a data flow diagram

Source or destination of data

Arrow Flow of data

Rounded Rectangle

Process which Transforms flows of data

Open-ended rectangle Store of data

Orders

Invoices (with books)

Credit status

DFD symbols

9

17

18

• Another key graphical model – the Entity-relationship diagram (ER diagram)

– Focuses on identifying types of “things” (entities) which the system needs to store information about (e.g. customers, items and details)

– Specifies relationships between these things or entities

– Used a lot for design of databases – you “carve up” your business application into entities you will store data about

10

19

20

Weaknesses of the Structured Approach

• Techniques address some but not all of the activities of analysis and design

• Critics want a more comprehensive set of techniques

• Many thought data modelling using structure chart and ER diagram were more important than modelling processes (using dataflow diagrams)

• However, the structured approach overall still made processes rather than data the central focus

• Many felt a strategic planning technique needed to be included as well

11

21

22

The Object-Oriented Approach

• Structured approach referred to in text as “traditional approaches”

• Newer approach is object-oriented

– Really has swept through computer industry

– Application in many areas • Object-oriented programming (OOP)

• Object-oriented database management system (OODBMS)

• Object-oriented analysis (OOA)

• Object-oriented design (OOD)

12

23

Object-Oriented Approach

• Based on notion of “objects” – things in the computer system (and the world) which have behaviours and respond to “messages”

• Objects can be anything – A menu bar, or window on the screen

– A car

– A house

– A number etc.!

• Can send a message to an object – E.g. to a window to draw itself on the computer screen

– E.g. to a number to square itself!

• Can model very complex systems (e.g. a reactor)

24

13

25

History of Object Orientation

• Object-oriented approach began with development of Simula in the 1960’s

• In 1970, Smalltalk was developed – Allowed for development of graphical user interfaces

(with menu, button, window etc. objects)

• More recently led to other object-oriented programming languages – C++, Java

• Also to Object-oriented databases and “intelligent” databases

26

Object Oriented Terms

• Class Diagram – A graphical model that shows all the classes of objects in the

system

– For every class (grouping of related objects) there may be specialized subclasses

– Sublcasses “inherit” properties of classes above them

– Allows for reusability

Class Car

Subclass Ford

Subclass GM

Mustang

CLASS

SUBCLASS

INSTANCE

ISA

14

27

28

System Development Life Cycle (SDLC) Variations

• Traditional approach: “Waterfall method” – only when one phase is finished does the project team drop down (fall) to the next phase – Fairly rigid approach – decisions at each phase get

frozen

– Can’t easily go back to previous phases (each phase would get “signed off”)

– Good for traditional type of projects, e.g. payroll system or system with clearly definable requirements

– Not as good for many of the new types of interactive and highly complex applications

• applications where it is hard to specify all requirements once and for all

15

29

30

16

31

Differences in Approaches

• Traditional approach include feasibility study at beginning, with system investigation and systems analysis as the Analysis phase

• The objectory model includes only four phases

• Despite differences, the same overall tasks need to be carried out – e.g. planning, analysis, design and implementation

32

SDLC Variations

• The pure waterfall approach is less used now

• The activities are still planning, analysis, design and implementation

• However, many activities are done now in an overlapping or concurrent manner

• Done for efficiency – when activities are not dependent on the outcome of others they can also be carried out

17

33

Iteration

• Iteration assumes no one gets the right results the first time

• Do some analysis, then some design, then do some further analysis, until you get it right

• Idea: not always realistic to complete analysis before starting design

• Waterfall no longer applies - Phases become blurred

• Decisions are not frozen at the end of each phase

• Good for projects where requirement specifications are hard to arrive at

• However, can lead to ambiguity – Harder to know how far you are along in the project

– Could be hard to manage

34

Rational Unified Process

18

35

The “Classic” Waterfall Life Cycle

Analysis

Design

Implementation

Project planning

36

19

37

Prototyping tool requirements

• Flexibility and power needed for fast development

• WYSIWYG (what you see is what you get) development of interface components

• Generation of complete programs, program skeletons etc.

• Rapid customization of software libraries or components

• Sophisticated error-checking and debugging capabilities

• In example on next slide you can easily “draw” the interface, by selecting buttons, menus etc. and dragging onto the screen (e.g. Visual Basic)

38

20

39

Spiral life cycle

• Project starts out small, handling few risks

• Project expands in next iteration to address more risks

• Eventually the system is completed (all risks addressed)

• At the middle (start of the project) there is low risk and project is still small easy to manage

• You work out from the middle, expanding out your project

40

21

41

Variations based on an emphasis on people

• Sociotechnical systems

– Systems that include both social and technical subsystems

– Both social and technical subsystems must be considered

– User-centered design/Participatory design

– Example in text: Multiview

• Main idea: Human activity must be studied in detail (as well as technical aspects) – often forgotten!!

– Example – study of activity in intensive care unit as basis for system design (versus “expert system” approach)

42

22

43

Variations based on speed of development

• RAD – Rapid Application Development

• Try to speed up activities in each phase

– E.g. scheduling intensive meetings of key participants to get decisions fast

– Iterative development

– Building working prototypes fast to get feedback (can then be directly expanded to finished system)

– If not managed right can be risky

44

Computer-Aided System Engineering (CASE)

• CASE tools: Software tools designed to help system analyst complete development tasks

• The CASE tool contains a database of information called a repository – Information about models

– Descriptions

– Data definitions

– References that link models together

• Case tools can check the models to make sure they are complete and follow diagramming rules

• Also can check if the models are consistent

• Adds a number of capabilities around the repository

23

45

46

Types of CASE tools • Upper CASE tools

– Support analyst during the analysis and design phases

• Lower CASE tools – Support for implementation – eg. generating programs

• Tools may be general, or designed for specific methodology (like for information engineering – TIs’ IEF, CoolTools)

• Examples of CASE tools – Visual Analyst for creating traditional models

• Called “integrated application development tool”

– Rational Rose for object-oriented modelling • Based on UML standard for object orientation

• Allows for reverse-engineering and code generation (can integrate with other tools like Visual C++ etc.)

• “Round trip engineering” – synchronized updating

24

47

48

25

49

Background: The case for CASE

• Why need CASE? – As software systems get large and more complex they

have become prone to unpredictable behaviour and bugs

– Problem of systems that are not reliable, do not meet requirements or that just plain don’t work!

– CASE tries to eliminate or reduce design and development problems

– Ultimate goal of CASE is to separate the application program’s design (and analysis) from the program’s code implementation

• Generally, the more detached the design process is from actual coding, the better

• Traditional software development emphasized programming and debugging, CASE focuses on good analysis and design

50

Causes of failure (and symptoms) in software development

• Requirements Analysis – No written requirements

– Incompletely specified requirements

– No user interface mock-up

– No end –user involvement (can happen – may have talked to clients BUT not users!)

• Design – Lack of, or insufficient, design documents

– Poorly specified data structures and file formats

– Infrequent or no design reviews

26

51

• Implementation

– Lack of, or insufficient coding standards

– Infrequent or no code reviews

– Poor in-line code documentation

• Unit test and Integration

– Insufficient module testing

– Lack of proper or complete testing

– Lack of an independent quality assurance group

52

• Beta Test Release

– Complete lack of a beta test

– Insufficient duration for beta test

– Insufficient number of beta testers

– Wrong beta testers selected

• Maintenance

– Too many bug reports

– Fixing one bug introduces new bugs

27

53

Stats on Software Errors (large systems)

• Most software errors originate in the Analysis and Design phases (65%)

• Unfortunately, less than one-third of these errors are caught before acceptance testing begins

• About 35% of errors occur during coding

• Cost of fixing an error goes up the later it is caught!

• This is basis for emphasis in CASE on Analysis and Design

54

Cost to Repair

Analysis Design Code Unit Test

Integration Test

Maintenance

Stage when the Error is found

200 x

28

55

What CASE can do to help

• Help to make analysis and design process more rigorous and complete, to reduce bugs later

• Examples of functions in tools: • Provide support for diagramming (for analysis and design)

• Provide support for checking consistency of design

• Provide graphing support to help users visualize an existing or proposed information system (eg. Data flow diagrams)

• Detail the processes of your system in a hierarchical structure

• Produce executable applications based on your data flow diagrams (which can be made from point and click placements of icons)

• Integrate specific methodologies into windowing environments

56

Assemblers

Compilers

Debuggers

CASE- Analysis + Design

CASE- Code generators

Evolution of Software Tools

sophistication

29

57

Current Status of CASE

• A number of commercial products

• Some aspects (e.g. diagramming support) are widely applicable and useful

• Other features such as code generation are more specific

– CASE tools not so successful for generic code generation

– However, specific code generation is now being used for things such as user interface design

25/02/2015

1

1

ITEC 3010

Lecture 4

Investigating System Requirements

2

Analysis Phase Activities

• Gather Information

– Involves gathering lots of information

– Can get information from people who will be using the system

• By interviewing them

• By observing them

– Can get other information by reviewing documents and policy statements (e.g. At a bank)

– Can involve the analyst actually doing some or part of the task to get a feel for what is done

• In order to automate order-entry you may need to become an “expert” on the task (knowing how orders are processed)

– Need to understand current and future users, locations, system interfaces, possible solutions, etc.

25/02/2015

2

3

• Define System Requirements

– Involves modelling

• Logical Model – Any model that shows what the system is required to do

without committing to any one technology – requirements model is logical

• Physical Model – Any model that shows how the system will actually be

implemented

• Models are often graphical in nature – Data flow diagrams (DFDs)

– Entity-relationship diagrams (ERDs)

• Natural Language is ambiguous

4

25/02/2015

3

5

• Prioritize Requirements

– Important to establish which functional and technical requirements are most critical

– Why? Since resources are always limited and you want to address the most important things

– If not addressed can lead to “scope creep”, where the scope of the project just seems to expand over time

6

• Generate and Evaluate Alternatives

– Could include considering more than one method to develop system

– Could involve in-house development or outsourcing to to a consulting firm

– Might be able to use “off the shelf” software package

– Each alternative has costs and benefits to be considered

– Also must consider technical feasibility

25/02/2015

4

7

• Review Recommendations with Management – Usually done when all the above are completed

– Must decide if project should continue at all

– Must decide on which alternative is best (if you are going ahead with the project)

– NOTE – at this point should include CANCELLATION of project as an option

• May have found costs were too high

• May have found benefits were lower than thought

• Maybe the business environment suddenly changed making the project obsolete

– Detailed documentation has been collected • System requirements

• Proposed solution

8

25/02/2015

5

9

Requirements Specification

• Requirement specification results from Analysis phase

• What is a requirement?

– A feature of the system or description of something the system is capable of doing to fulfill the system’s purpose

– It addresses the purpose of the system (i.e. What it is supposed to do) and not how it will be implemented (However, Non-Functional requirements might require the analyst to look closer to how it will be implemented)

10

Functional and Technical Requirements

• Functional Requirements – A system requirement that describes a function or

process that the system must support

– E.g. “system will calculate tax amounts, report year end tax deductions”

• Non-Functional Requirements / Technical Requirements – A system requirement that describes an operating

environment or performance objective. Describe constraints on functional requirements

– E.g. Tax amounts should be accurate, Calculate Tax amount should be easy to use

– Security

– Safety

– Privacy

25/02/2015

6

11

Summary of Types of Requirements

Requirements

PHYSICAL ENVIRONMENT

INTERFACES USER AND HUMAN FACTORS

FUNCTIONALITY

DOCUMENTATION DATA RESOURCES

SECURITY

QUALITY ASSURANCE

12

Types of Requirements/Questions Asked

• Physical Environment – Where is the equipment to function?

– Is there one location or several?

– Are there any environmental restrictions such as temperature, humidity or magnetic interference?

• Interfaces – Is the input coming from one or more systems?

– Is the output going to one or more systems?

– Is there a prescribed way in which the data must be formatted?

– Is there a prescribed medium that the data must use?

25/02/2015

7

13

• Users and Human Factors

– Who will use the system?

– Will there be several types of users?

– What is the skill level of each type of user?

– What kind of training will be required for each type of user?

– How easy will it be for a user to understand the system?

– How difficult will it be for a user to misuse the system?

14

• Functionality

– What will the system do?

– When will the system do it?

– How and when can the system be changed or enhanced?

– Are there constraints on execution speed, response time, or throughput? (Non-Functional Req. frequently associated with FR)

• Documentation

– How much documentation is required?

– To what audience is the documentation addressed?

25/02/2015

8

15

• Data – For both input and output, what should be the format of

the data?

– How often will it be received or sent?

– How accurate must it be?

– To what degree of precision must the calculations be made?

– How much data flows through the system?

– Must the data be retained for any period of time?

• Resources – What materials, personnel or other resources are

required to build, use and maintain the system?

– What hardware is required?

– What software is required? (eg. Databases?)

16

• Resources (continued)

– What skills must the developers have?

– How much physical space will be taken up by the system?

– Is there a prescribed timetable for development?

– Is there a limit on the amount of money to be spent on development or on hardware and software?

25/02/2015

9

17

• Security

– Must access to the system or to information be controlled?

– How will one user’s data be isolated from other’s?

– How will user programs be isolated from other programs and from the operating system?

– How often will the system be backed up?

– Must the backup copies be stored at a different location?

– Should precautions be taken against fire or theft?

18

• Quality Assurance – What are the requirements for reliability?

– How the characteristics of the system must be demonstrated to others?

– Must the system detect and isolate faults?

– What is the prescribed mean time between failures?

– Is there a maximum time allowed for restarting the system after a failure?

– How can the system incorporate changes to the design?

– Will maintenance merely correct errors, or will it also include improving the system?

– What efficiency measures will apply to resource usage and response time?

– How easy should it be to move the system from one location to another or from one type of computer to another?

25/02/2015

10

19

Stakeholders – The source of system requirements

• Stakeholders: People who have an interest in the success of the new system

– The users: who actually use the system

– The clients: who pay for and own the system

– The technical staff: who ensure the system runs

• Must identify stakeholders

• Cannot forget an important group – e.g. users!

20

User Stakeholders

• Can identify users horizontally – i.e. Across departments

• Can also identify users vertically – i.e. Hierarchy within a department (e.g. lower, middle and upper managers)

• Type of users – Business operations users – use the system daily to

perform operations (transactions – a piece of work)

– Query users – could be business people or customers – request info

– Management users – want reports, performance stats, want to know volumes of transactions etc.

– Executive users – want information to help with strategic issues, e.g. compare improvements in resource utilization

25/02/2015

11

21

22

25/02/2015

12

23

Stakeholders at Rocky Mountain Outfitters

• Operational users of the new order system – Inside sales representatives (who take orders)

– Clerks (who process order)

– Warehouse workers

• Each type of user has their own needs and preferences – Need usability testing to get at this! (text doesn’t mention)

• Project funded from internal cash flow

• Since the system involves new technology (Internet) need involvement from technical staff

24

Identifying System Requirements

• Main Objective of Analysis Phase – To understand the business functions and develop

system requirements

– Question of studying existing systems first or not

– Using structured approach, analyst first documents the existing system then extrapolates the requirements of the new system

– Approach 1. Develop current system physical models

2. Extract the current system logical models

3. Develop new system logical model

4. Develop new system physical model

25/02/2015

13

25

• Faster approach

– Identify current system procedures immediately (as much as need to, don’t necessarily define specific processes)

– Develop requirements and models for new system (ie. develop logical model)

• In either approach, need to balance investigation of old procedures with need to focus on requirements of the new system

26

Questions asked (overall)

• What are the current business processes and operations? – Ask the users, “What do you do ?”

– Assess what current functions can remain and which should be eliminated by technology

• How should the business processes be performed? – Ask the user “How can it be done?”, “What steps should

be followed? (using the new system)”. How else ?

• What information is needed? – Specific information requirements, e.g. Databases needed

25/02/2015

14

27

Skills Needed and Methods Used

• Understanding of user needs

• Ability to analyze and solve business problems – Being able to identify and capture business rules

• Methods – Distribute questionnaires to stakeholders

– Review existing reports, forms and procedure descriptions

– Conduct interviews and discussion with users

– Observe business processes and workflows in real life (can video or audio record activities, do usability testing etc.)

– Build prototypes

– Conduct joint application design (JAD) sessions

28

Distribute and Collect Questionnaires

• Allows to collect information from large numbers of users

• Can obtain early insight into information needs

• Can be useful for collecting demographic or quantitative information

– e.g. “how many orders do you enter a day?” “What is your educational background?”

• Can collect information using scales, e.g. “On a scale of 1 to 7 how important is system speed?” – closed-ended questions which do not invite discussion

• Less useful for collecting other types of qualitative information (e.g. system usability, user-interface needs)

25/02/2015

15

29

30

• Types of Questions in Questionnaires – Closed-ended questions (to determine

quantitative information (Part I in figure 4-5)

– Opinion questions (Part II in figure 4-5)

– Requests for explanation or problems (Part III in figure 4-5)

• Note – some current use of questionnaires – Deployment over the WWW is easy

– Can use text entry boxes for explanation or problems

– Can automatically summarize questionnaire results

25/02/2015

16

31

Limitations of Questionnaires

• Not well suited for learning about processes, workflows or techniques (e.g. to answer “How do you do this process?” - better to interview or observe)

• Questions that encourage elaboration are called “open-ended” – can be put in a questionnaire but if there are too many of these, questionnaires tend not to get returned!

• Relies in user’s memory of their use of systems (researches show this differs from what they actually do in many cases!)

32

Review Existing Reports, Forms and Procedure Descriptions

• Review of existing documents very useful

– Can help you get a preliminary understanding of processes involved in a company

– Can be used in conjunction with interviews • Can be used to develop interview questions

• Can be used in interviews themselves

– As visual aids

– Working documents for discussion

– Review of forms helps to identify business rules

– Helps to discover discrepancies and redundancies

– Can be extended to looking at other types of documents like emails, memos etc.!

25/02/2015

17

33

34

Conducting Interviews and Discussions with Users

• Interviewing stakeholders is one of the most effective ways to understand business functions

• Can be time-consuming and resource expensive

• A number of members of the project team meet with individuals (or groups of users)

• List of detailed questions is prepared and discussion continues until all the processing requirements are understood

• May involve multiple sessions (often does)

• Can involve new approaches (Protocol analysis, Ethnography etc – ITEC 4040)

25/02/2015

18

35

Prepare

Carry out

Follow up

36

Preparing for the Interview

• Must establish objective – what do you want to get out of it?

• Determining users – Could interview users with different levels of

experience, computer expertise, bank expertise…

• Good to have at least two project team members at the interview, but not more than three – Can compare notes

– I like to audiotape interview (when allowed!)

• Prepare detailed questions – Good to structure the questions

– Can include both open-ended (e.g. “how do you do this function?”) and closed-ended questions (“how many times a day do you do this?”)

25/02/2015

19

37

• Last step in preparing: make the interview arrangements (where to meet and when – good to pick a quiet room)

Conducting the Interview

• See text for variety of tips, like dress well, be polite and arrive on time!

• Have to limit time of interview – Avoid “marathon” interviews

• Look for error or exception conditions – e.g. get them to describe when things go wrong – In critical incident method can ask to describe an easy case, as

well as a “scenario from hell”

– What “ifs” can be explored as well as probing about real incidents

38

• Probe for details – In addition to looking for exception conditions, the

analyst must probe to get a complete understanding of procedures and rules

• Take careful notes – Text says tape recorders make people nervous, but

notes and taping is good combo!

– Privacy.

• Try to follow some logical agenda during the interview

• Semi-structured interviews often most useful (unstructured interviews can often get out of control)

25/02/2015

20

39

40

Following Up the Interview

• Have to absorb, understand and document the information collected from the interview

• Can write it up as text and also document by constructing diagrammatic models

• Review with others who attended the interviews

• Make a list of questions that need further elaboration (see figure 4-9 for an example of a sample “Open-items” list)

25/02/2015

21

41

Observing Business Procedures and Workflows

• Early (but not too early) in the investigation should observe the activities in the organization as they really occur

• Excellent way to learn – how people do their jobs

– what problems they may have

– how to improve any systems they are using

• Can consist of – Quick walkthrough of the office or plant

– Scheduling several hours to observe a user doing a real task (“day in the life”)

– More involved methods – e.g. Videotaping the workplace and using methods from social science to analyze

42

• When observing

– Should attempt to be unobtrusive, so you don’t change the users’ behaviour because you are watching them!

– May require consent to do this (e.g. videotaping intensive care unit in a hospital)

– May require repeated or extended observation periods to really understand what is going on

– If you are observing (and not recording) then best to have more than one observer go along

– As text mentions, common sense and sensitivity to needs and feelings of the users is VERY important!

25/02/2015

22

43

Observing Activities: some notes

• Decide what is to be observed

• Decide what level of detail should be looked at (how concrete the observation should be)

• Create categories that capture key activities

• Prepare materials for observation (forms to fill in for note taking)

• Decide when to observe and what tools you’ll take (e.g. camera, tape recorder, or just recording on paper)

• Decide on approach to sampling – e.g. observe three one hour periods, or by event (e.g. board meetings)

• Can be used in conjunction with other methods (e.g. interviews)

• Could use forms to structure observations (see next slide)

44

Organziation: Company: Solid Steel Shelving Analyst: Joe Smith Scenario: Quality assurance Date: 9/3/1999

Decision Maker (Actor) Observation of Information-Related Activity

Quality Assurance Manager - Asks shop floor supervisor for the day’s

production report.

Shop floor Supervisor - Prints out the daily computerized production

report.

- Discusses recurring problems in production

runs with quality assurance (QA) manger.

Quality Assurance Manager - Reads production report.

- Compares current report with other reports from

the same week.

- Observes on-screen results of QA model.

25/02/2015

23

45

Building Prototypes

• Prototype: A preliminary working model of a larger system

• Uses: – To test feasibility

– To help identify processing requirements

– To compare different design and interface alternatives

• Different names – Throwaway prototypes

– Discovery prototypes – used in analysis phase

– Design prototypes – used in design

– Evolving prototypes • Prototypes that grow and eventually may end up becoming the

final system

46

Prototypes as tools during Analysis

• During analysis a discovery prototype – E.g. use of a prototype to determine screen formats and

processing sequences (then thrown away)

– Can show users or clients ideas early on to refine requirements (also used later on in design phase a lot)

• Characteristics of Prototypes – Operative: a prototype should be a working model, with

some real functionality

– Focused: a prototype should be focused on a single objective

– Quick: the prototype should be built and modified quickly (so can validate an approach, and if it is wrong fix it fast in an iterative process)

25/02/2015

24

47

Joint Application Design (JAD) Sessions

• JAD: a technique to define requirements or design a system in a single session by having all the necessary people participating together

• Normal interviews take lots of time and effort – May require many meetings (months)

• JAD idea: why not compress all these activities into a shorter series of meetings with users and team members – JAD session may last a day to a week

– Try to have all the stakeholders present to make decisions

– All fact-finding, model-building etc. done in the JAD session

48

JAD Participants

• JAD session leader – Trained in group dynamics and facilitating group

discussion

– Must ensure agenda and objectives are met

– Often system analyst appointed as leader but better if someone actually trained to lead group decision making

– May not be the expert in the business area though

• Users – Managers are good to have at the meeting since

important decisions have to be made

– If executives cannot be at the meeting, they at least should be contactable (or visit once a day)

25/02/2015

25

49

JAD Participants - continued

• Technical staff – A representative from the technical support group

should be present (e.g. for info. regarding things like networks, operating environments etc.)

• Project team members – System analysts

– User experts

– Assist in discussion, clarify points, build models and document the results

– Members of the project team are the experts on ensuring the objectives are met

50

Setting for JAD sessions

• Usually conducted in special rooms

• Off-site location may be good

• But need access (phone etc.) to executives and technical staff not present

• Resources – Overhead projector

– Black or white board

– Flip chart

– Adequate work space

25/02/2015

26

51

52

Advances to Support JAD sessions

• Electronic support – Participants may have laptops connected in network

– That way models and descriptions can be shown to everyone (could be done using a CASE tool)

– Group Support Systems (GSSs) • System that enables multiple people to participate with

comments at the same time, each on his or her computer

• Allow for sharing of information and collaborative work

• Runs on networked computers

• Can include “chat” features to allow posting to participants

• Allows inclusion of “shy” participants

• Can store results of discussion and decisions made

• Also allows for connection with participants at distant locations – end up with a “virtual” meeting (could include video hookup)

25/02/2015

27

53

• Other forms of electronic support

– Electronic white boards

– Computer support for collaborative work (CSCW) software

– Would allow for participation at remote sites who could work on documents at same time (shared files etc.)

54

25/02/2015

28

55

Limitations of JAD

• Can be risky

• Since done very fast may end up with suboptimal decisions

• Details may be inappropriately defined or missed

• However, JAD can be effective if done carefully with the result of shortening the schedule

56

Business Process Reengineering (BPR)

• Popular buzzword over last ten years

• Due to global competition many companies have had to completely rethink their assumptions about how to do business

• Old rule of business: “If it isn’t broken, don’t fix it”

• Newer way of thinking: “There is always a better way to do it, lets improve it”

• Business process reengineering approach: “Let’s question basic assumptions to find a completely

new way to do it that will bring dramatic and profound improvement”

25/02/2015

29

57

Business Process Reengineering (cont.)

• Objective: to use IT in novel ways to achieve dramatic improvements in efficiencies and level of service

• BPR and IT are closely aligned

– Many systems analysts must also become business analysts

– To assist in the process of rebuilding all internal business procedures based on new in innovative information technology

25/02/2015

1

1

ITEC 2010A

2

Models and Modeling

• A model: a representation of some aspect of the system being built

• A variety of models – Many are graphical (e.g. Data flow diagram, ER diagram)

– Can show different levels of detail

– Some focus on data

– Some focus on processing

• Purpose: creating a model can help clarify and refine the design – Developing the model raises questions that need to be

considered

– Models help to simplify complex aspects of systems

25/02/2015

2

3

Reasons for Modeling

• Learning from the modeling process – New pieces are found to be needed

– New questions arise that need to be answered to complete the model

• Reducing complexity by abstraction – Systems can be complex and intangible

– Models of parts of the system help to clarify and focus on important aspects

• Remembering all of the details – Models are a way of storing information for later use in

a form that can be digested (e.g. A picture can say a lot)

4

Reasons for Modeling (cont.)

• Communicating with other development team members – Can show others aspects of the system in a succinct

way

– Support communication – e.g. someone working on inputs and outputs can use the model to communicate with someone working on processing details

• Communicating with a variety of users and stakeholders – Users need to see clear and complete models to

understand what the analyst is proposing

– Users often work with analyst to create models (this process can help users better understand what the system can do)

25/02/2015

3

5

Reasons for modeling (cont.)

• Documenting what was done for future maintenance/enhancement

– Critical development team leaves behind a record of what was created

– Need to package everything in a form future developers can understand and use when they modify and update the system

– Much of the documentation consists of models (e.g. diagrammatic) as text mentions – also much of documentation also consists of textual reports

6

Types of Models

• Mathematical model: a series of formulas that describe technical aspects of a system – Ex: R=r1, r2, ..., rn ;

S= s1, s2, ..., sn ;

there is a relation {(ri,sj) | ri є R sj є S }

– Comfortable for scientific or engineering applications

– Sometimes used in business systems – e.g. simple formula for payroll where you model gross pay as regular pay plus overtime pay

• Descriptive model: narrative memos, reports, or lists that describe some aspect of the system – E.g. might jot down notes from interviewing a user

– Users may describe what they do in reports or memos

– Analyst can then convert these descriptions to a modeling notation

25/02/2015

4

7

Types of Models (cont.)

– Sometimes narratives are the best way for recording information

– Simple lists of features, inputs, outputs, events or users are examples

– A very important form of narrative model: writing a procedure in a very precise way – structured English or pseudocode

– Pseudocode used a lot by programmers, can also be used to describe procedures during earlier phases

Example of Pseudocode description of a payroll function:

1. Input the employees payroll data

2. If hours worked is greater than 40 then calculate overtime pay

3. Calculate gross pay for the employee - Gross Pay = hourly pay times 40 plus overtime

4. Calculate tax for the employee ETC.

8

25/02/2015

5

9

Types of Models (cont.)

• Graphical Model: diagrams and schematic representations of some aspect of a system – Easy to understand complex relationships (old saying: a

picture is worth a thousand words)

– Graphical models may look similar to a real-world part of the system (e.g. a screen design or report layout)

– But often represent more abstract things, e.g. processes, data, objects, messages, connections

– Key graphical models tend to represent abstract aspects of a system during Analysis Phase

– The more concrete models (e.g. screen design) tend to appear later in the Design Phase

10

Notes on graphical models

• Many different types and formats

• Variations in notation

• However, still based on basic symbols

– Circle

– Square

– Rectangle

– line

25/02/2015

6

11

Models used in the Analysis Phase

• The analysis phase named “Define System Requirements” involves creating models

– logical models (define what is required without committing to one specific technology)

• Many different types of formalisms for defining logical models

12

25/02/2015

7

13

Models used in the Design Phase

• These are physical models – since will be implemented with a specific technology

• Some are extensions of requirements models created during systems analysis

• Some may be used during both analysis and design (e.g. object-oriented class diagram)

14

25/02/2015

8

15

Events and System Requirements

• Two key concepts to model: – Events

– Things

• Event – an occurrence at a specific time and place, that can be described and is worth remembering – E.g. customer placing an order, shipping identifies a

backorder, nuclear reactor goes to meltdown

• When defining system requirements it is useful to begin by asking what events occur that will affect the system being studied – What events will occur that the system will have to respond

to?

– Allows you to focus on external environment to keep you at high level view of system (not the workings of it)

16

Events (cont.)

– Also allows you to focus on the interfaces of the system to outside people and systems

– End users can easily describe system needs in terms of events that affect their work, very useful when working with users

– Gives a way to divide (or decompose) the system requirements so you can study each separately (complex systems need to be decomposed based on events)

25/02/2015

9

17

18

Background to Event Concept

• Structured analysis adapted to real-time systems in the early 1980’s

– E.g. process control system, reactors, aerospace etc.

– Events like “chemical vat is full”, “boiler overflowing”

– System must respond to these types of events immediately

– Extended to business applications since they have become more interactive

25/02/2015

10

19

Types of Events

• External Event

– An event that occurs outside the system

– usually initiated by an external agent or actor (a person or organization that supplies or receives data from the system) – Can also be another software !!

– Classic example of an external agent: a customer

– Possible event: the customer wants to place an order

– Naming events: • Include the external agent in the name

• E.g. events: “Customer places order”, “Management checks order status”,”Customer reports change of address”

20

• External Events Checklist

– External agent wants something resulting in a transaction

– External agent wants some information

– Data changed needs to be updated

– Management wants some information

• Temporal Events

– An event that occurs as a result of reaching a point in time

– Could be reports to management generated regularly

– System automatically produces reports etc. at right time (so no external agent needed)

– E.g. Payroll systems produce a paycheck every two week (or once a month)

25/02/2015

11

21

• Temporal Events Checklist – Internal outputs needed

• Management reports (summary or exception)

• Operational reports (detailed transactions)

• Statements, status reports (including payroll)

– External outputs needed • Statements, status reports, bills, reminders

• State Events – An event that occurs when something happens inside

the system that triggers the need for processing

– E.g. the sale of a product results in an adjustment in the inventory (event “Reorder point reached)

– This state change might occur as a result of external events or to temporal events (so could be similar to temporal event, but point in time can’t be defined)

22

Identifying Events

• Events versus conditions and responses

– Can be difficult to distinguish between an event and the sequence of conditions that lead to it (e.g. events leading to buying a shirt)

– Also may be hard to distinguish between an external event and the system’s response (e.g. customer buys shirt, system requests credit card number – the customer buying the shirt is the event)

– Way to determine if an occurrence is an event • Ask whether any long pauses or intervals occur (I.e. is the

system at rest for another transaction to complete? Once a transaction starts there are no significant stops till done

25/02/2015

12

23

• Tracing the Sequence of Events

– It is often useful to trace the sequence of events for a specific external agent or actor

24

25/02/2015

13

25

• Technology-Dependent Events and System Controls

– System controls: checks for safety procedures necessary to protect the integrity of the system

• Logging on to a system (for security reasons)

• Controls for keeping integrity of a database

– To help decide which events apply to controls we assume that technology is perfect (never the case!)

– During analysis we should focus on events that are required under “perfect” conditions -- “perfect technology assumption”

– It is during design phase that we deal with other issues and events from a “non-perfect world” point of view, e.g. events like “Time to back up the database”

26

Events Deferred Until the Design Phase

25/02/2015

14

27

External Events for the Rocky Mountain Outfitters Customer Support System

Look at all the people and organizations that want the system to do something:

• Customer wants to check on item availability

• Customer places an order

• Customer changes or cancels order

• Customer or management wants to check order status

• Shipping fulfills orders

• Shipping identifies back order

• Customer returns item

• Prospective customer requests catalog

• Customer updates account information

• Marketing wants to send promotional materials to customers

• Management adjusts customer charges (corrects errors)

• Merchandising updates catalog

• Merchandising creates special product promotion

• Merchandising creates new catalog

28

Temporal Events for the RMO Customer Support System

Look at all the regular reports and statements that the system must produce at certain times:

• Time to produce order summary reports

• Time to produce transaction summary reports

• Time to produce fulfillment summary reports

• Time to produce prospective customer activity reports

• Time to produce customer adjustments/concession reports

• Time to produce catalog activity reports

25/02/2015

15

29

Looking at Each Event

• Event Table: A table that lists events in rows and key pieces of information about each event in columns – The trigger: an occurrence that tells the system that an event has

occurred (either the arrival of data needing processing or of a point in time)

– The source: an external agent or actor that supplies data to the system

– The activity: behavior that the system performs when an event occurs

– The response: an output, produced by the system, that goes to a destination

– The destination: An external agent or actor that receives data from the system

30

25/02/2015

16

31

32

“Things”

• In addition to modeling events, we have to model the “things” that the system needs to store information about

– E.g. products, orders, invoices, customers etc.

• In traditional approach, these things make up the data which the system stores information about

• In the object-oriented approach these things are objects

25/02/2015

17

33

Types of Things

34

A way to identify “things” of interest

• The analyst can identify types of things by thinking about each event in the event list and asking what types of things are affected that the system needs to know about

– E.g. when a customer places an order we need to know about the following

• The customer

• The items ordered

• Details about the order

e.g. date and payment terms

25/02/2015

18

35

Relationships among Things

• Relationship: a naturally occurring association among specific things – An order is placed by a customer and an employee works

in a department

– “Is placed by” and “works in” are two relationships

– Relationships apply in two directions • A customer places an order

• An order is placed by a customer

– Important to know the number of associations of things – I.e. the cardinality (or multiplicity) of the relationship

• E.g. one to one, one to many

– It is also important to know the range of possible values of the cardinality

• Zero to many (optional relationship), one to one, and one to many (mandatory relationships)

36

25/02/2015

19

37

Types of relationships

• Binary relationship – Relationship between two different types of things

• E.g. between a customer and an order

• Unary (recursive) relationship – Relationship between two things of the same type

• E.g. one person being married to another person

• Ternary relationship – A relationship between three different types of things

• E.g. one order associated with a specific customer plus a specific sales representative

• n’ary relationship – A relationship between n (any number) different types

of things

38

Attributes of Things

• Attribute: one piece of specific information about a thing

– E.g. a customer has a name, phone number, credit limit etc. (these are attributes of a customer)

– Compound attribute: an attribute that contains a collection of related attributes – E.g. a full name is made up of first and last name

– Identifier (key) – an attribute that uniquely identifies a thing E.g. a person’s social insurance number (?), or an invoice or transaction number)

25/02/2015

20

39

40

Data Entities and Objects

• Data entities – For the traditional approach, are things the system

needs to store information about. Modeled as boxes in the ER diagram)

– Computer processes interact with these data entities

– Entities are things like customers and order

• Objects – the other way to look at things – Similar to data entities in traditional approach

– BUT the objects do the work in the system, they do not just store information (i.e. They have behavior)

– This difference has important effects on system modeling

25/02/2015

21

41

Objects

• Class: the type or classification to which all similar objects belong (e.g. guitar and violin objects both belong to class “stringed instruments”) – Classes, associations among classes and attributes of classes are modeled

using a class diagram

• Attribute:Store information (data) about the class, e.g. – Custumer: name:string, ID:integer,Married:boolean

• Method: the behaviours all objects of the class are capable of – A behaviour is an action that the object processes itself, when asked to do

so E.g. ask a boiler object to check its water level by sending it a message

• Encapsulation: covering or protecting each object so that it contains values for attributes and methods for operating on those attributes (making the object a self-contained and protected unit)

42

25/02/2015

22

43

The Entity-Relationship Diagram

• Used in traditional approach

– Emphasizes data storage • Data entities

• Their attributes

• Relationships among data entities

– Model used to define data storage • Entity-relationship diagram (ERD)

44

ERD Notation

• Rectangles: data entities

• Lines connecting rectangles: relationships

25/02/2015

23

45

Customer Order Place

1 0..n

46

25/02/2015

24

47

48

Order 3 March 31

Order 2 March 5

25/02/2015

25

49

Notes

• As an analyst works on a model, the ERD gets refined

• E.g. many-to-many relationship

– May lead to storing additional data

50

25/02/2015

26

51

• Problem: where is the grade each student receives for a course going to be stored?

• Other refinements may be needed

– Database normalization (more after the midterm)

52

25/02/2015

27

53

25/02/2015

1

1

ITEC 3010 Analysis - Data Flow Diagrams

2

Chapter 6 (Traditional Approach to Requirements) -- Data Flow Diagrams (DFD)

• Data Flow Diagram (DFD)

– A graphical system model that shows all of the main requirements for an information system: inputs, outputs, processes and data storage

– Everyone working on the project (and end users) can see all the aspects of the project in the diagram with minimal training (simple – only 5 symbols)

25/02/2015

2

3

4

Example of a Data Flow Diagram – fig. 6-3

• The square is an external agent – A person or organization, outside the boundary of a

system that provides data inputs or accepts data outputs

• The rectangle with rounded edges is a process – A symbol that represents an algorithm or procedure by

which data inputs are tranformed into data outputs

• The lines are data flows – Represents movement of data

• The flat three-sided rectangle are data stores (a file or part of a database) – A place where data is held

• Fig. 3-6 corresponds to event “Customer wants to check item available” (see last lecture)

25/02/2015

3

5

6

Data Flow Diagrams and Levels of Abstraction

• Levels of abstraction

– Particular to any modeling technique that breaks the system into a hierarchical set of increasingly more detailed models

– Example above – a DFD fragment – showing one process in response to one event

– Other diagrams show the processing at a higher level (more general) or lower level (a more detailed view of one process)

– Higher level processes in a DFD can be decomposed into separate lower level DFD (or some other diagram)

25/02/2015

4

7

Context Diagrams

• Context Diagram: A DFD that summarizes all processing activity within the system in single process symbol

– Describes highest level view of a system

– All external agents and all data flows into and out of a system are shown in the diagram

– The whole system is represented as one process

• Example – fig. 6-5 shows a context diagram for a university course registration system that interacts with 3 agents: academic dept., student, and faculty member

8

25/02/2015

5

9

Notes on Context Diagram

• Useful for showing system boundaries

• External agents are outside the software scope (which is represented by the single process). But not from System Analysis

• Data stores are not shown in the context diagram since they are considered to be in the software scope (i.e. the single process)

• It is the highest level DFD

• Context diagram does not show any details of what takes place within the system (i.e. that single process)

10

25/02/2015

6

11

DFD Fragments

• DFD fragment: A DFD that represents the system response to one event within a single process symbol – A fragment is created for each event in the event list – it

is a self-contained model showing how the system responds to a single event

– Created one at a time

– Fig. 6-7 shows 3 DFD fragments for a course registration system

– Each fragment represents all processing for an event within a single process symbols

– The data stores in the DFD fragment represent entities in the ERD (Entity Relationship Diagram – see last lecture) – Not Necessarily !

12

25/02/2015

7

13

14

25/02/2015

8

15

The Event-Partitioned System Model

• Event-partitioned system model: a DFD that models requirements using a single process for each event – The entire set of DFD fragments can be combined into this

single DFD called the event-partitioned system model or diagram 0

– Diagram 0 shows the entire system on a single DFD

• Figure 6-10 (next slide) shows a set of four related DFDs – The top diagram shows the Context diagram for course

registration (same as fig. 6-5 above)

– The diagram below that (Diagram 0) is the decomposition of the one process in the context diagram AND consists of the a combined version of the 3 DFD fragments in fig. 6-7 above (in fig. 6-10, DFD fragment 1 is shown below diagram 0)

– Finally, Diagram 1 is a decomposition of the process in DFD fragment 1

16

25/02/2015

9

17

Dividing the system into subsystems

• The RMO customer support system involves 20 events, therefore the event-partitioned system model (diagram 0) would contain 20 processes

– This can get to be a crowded diagram!

– Solution is to divide the system into subsystems

– Events are grouped into related subsystems based on similar:

• Interactions with external agents

• Interactions with data stores

• Required processing

• In the RMO example, we can break up the support system into 4 subsystems (see next slide)

18

25/02/2015

10

19

• Next Step: After the subsystems are defined: – A DFD is created to represent the division of

the system into subsystems – the subsystem DFD

– This subsystem DFD shows how the four RMO subsystems are connected (i.e. how they are related to all the outside sources and destinations of data)

• Note that there is a process in the diagram for each of the four subsystems that were defined for RMO

– See figure 6-13 for an example based on the 4 subsystems in the RMO example

– Note - even with only 4 subsystems (rather than one process for each of the 20 events) the diagram gets cluttered

20

25/02/2015

11

21

• Next Step: can decompose a subsystem DFD into event-partitioned models - one for each subsystem:

– In the RMO example can expand the subsystem in fig. 6-13 called “Order entry subsystem” into an event-partitioned model

• this model has 5 processes within it – see next slide

– The analyst would also create an event-partitioned model for the other 3 subsystems in the RMO example

22

25/02/2015

12

23

Summary - Relationship of all these diagrams

• Figure 6-12 shows the relationship among DFD abstraction levels when subsystems are defined

• The figure starts off with the context diagram, which breaks down to the subsystem diagram (one for each subsystem)

• The subsystem diagram is turn broken down into the event-partitioned subsystem diagrams

• ETC.

24

Layers of DFD Abstraction

25/02/2015

13

25

Decomposing Processes to see Details of One Activity

• Using this same principle of breaking down the model to more detailed level, we can take a DFD fragment (e.g. create new order fragment from the RMO example) and decompose it into sub-processes

• In figure 6-15 this is shown – Since fragment “create new order” was the second DFD

fragment defined for the RMO example (see fig. 6-8) we will label processes inside of it as processes 2.1, 2.2, 2.3 etc.

– The diagram decomposes “create new order” into 4 sub-processes (see fig. 6-15) – labeled sub-processes 2.1-2.4

26

25/02/2015

14

27

Evaluating DFD Quality

• A quality set of DFDs is

– Readable

– Internally consistent

– Accurately represents system requirements

• Minimizing complexity

– Want to avoid information overload • Occurs when too much information is presented to a user at

one time

• Two ways to avoid information overload use 7 + or – 2 rule (which limits the number of components) and interface minimization (which minimizes the number of interfaces and connections between components)

– A single DFD should have no more than 7 + or – 2 processes

– No more than 7 + or – 2 data flows into or out of a process

28

• Data Flow Consistency – Want consistency in DFDs

– Common errors:

• Differences in data flow for a process and its decomposition (want to have balancing: equivalence of data content between data flows entering and leaving a process or its decomposition)

• Black hole

– A process with data input that is never used to produce a data output

• Miracle

– A process with a data output that is created out of nothing (I.e. “miraculously appears”)

• Black hole and miracle problems apply to both processes and data stores

• Most CASE tools perform data flow consistency checking

25/02/2015

15

29

30

25/02/2015

16

31

Documenting Data Flow Diagram (DFD) Components

• Process Descriptions

– Each process on a DFD needs to be defined

– Can keep breaking down DFD to more detailed DFD but at some point have to describe the process in structured English

• Uses instructions, repetition and if-then-else logic

• Note that this is not necessarily a computer program (its an algorithm that describes the process)

32

25/02/2015

17

33

• Limitations of structured English – Good for representing processes such as those in

previous slide

– Not so good for showing complex decision logic – as shown in next slide

– Not so good if there are few or no sequential steps

• Decision Table – A tabular representation of processing logic containing

decision variables, decision variable values and actions (or formulas)

• Decision Tree – A graphical description of process logic that uses lines

organized like branches of a tree

34

25/02/2015

18

35

Making a Decision Table (from the logic on previous slide)

• Step 1

– Identify the decision variables • Year to date purchases (YTD)

• Number of items ordered

• Delivery date

• Step 2

– Put variable with fewest possible value ranges in the first row of the table

• In this example could put either YTD or number of items

36

• Table so far is just one row:

YTD Purchases > $250 YES NO

• Step 3 – put variable with next fewest possible value ranges as next row in the table, to now get:


Number of Items (N) N <=3 N>=4 N<=3 N>=4

• Step 4 – keep inserting rows as in step 3 until all decision variables are included in the table

25/02/2015

19

37

• Table now looks like:


Number of Items (N) N <=3 N>=4 N<=3 N>=4

Delivery Day Next 2nd 7th Next 2nd 7th Next 2nd 7th Next 2nd 7th

• Step 5 – Finally put as bottom row of the table the actions for each of the possible conditions – see next slide (fig. 6-22) from the text for the complete table

38

25/02/2015

20

39

Decision Tree

• A graphical description of process logic that uses lines organized like branches of a tree

• Decision table is more compact but decision tree is easier to read

• Decision tree can be developed in essentially same way as a decision table (only difference is that it runs horizontally – i.e. Rows in a decision table are columns in the tree – just flip the table sideways and you get the tree)

40

25/02/2015

21

41

• there may be several actions associated with a set of conditions in a Decision Table

– Figure 6-24 shows a table where if the customer is new and if an item is on backorder for >= 25 days then two things are done:

• (a) include detailed return instructions

• (b) expedite delivery

• See next slide for this example

42

25/02/2015

22

43

Data Flow Definitions

• Data flow – a collection of data elements

• Data flow definition – a textual description of a data flow’s content and internal structure

– Lists all the elements- eg. a “New Order” data flow consists of • Customer –Name

• Customer-Address

• Credit-Card-Information

• Item-Number

• Quantity

– Most of these are stored and correspond to the attributes of data entities

– In addition to just listing elements can use algebraic notation • Data flow “equals” one element followed by another (repeating groups

can be shown in curly brackets)

44

25/02/2015

23

45

46

25/02/2015

24

47

48

Data Element Definitions

• Describe a data type

– E.g. String, integer, floating point, or Boolean

– Lengths are usually defined for strings

– Numeric values usually have a minimum and maximum value (a valid range)

– Might define special codes (e.g. code A means ship immediately etc.)

25/02/2015

25

49

+int

9(4)

+9(6).99

String[50]

50

Data Store Definitions

• Usually, a data store on the DFD represents a data entity on the ERD

• Should look at the ERD for details on this

• If no ERD can define the data store as a collection of elements (like did for data flows)

25/02/2015

26

51

Workflow Modeling

• Workflow

– The flow of control through a processing activity as it moves among people, organizations, computer programs, and specific processing steps

– Encompasses • Trigger

• The processing steps that respond to a trigger

• Participants (or “actors”) – can be people and machines

• Flow of data

52

• Workflow models directly model the sequence of processing activities – Can develop and check with users to gain better

understanding of a system or organization

• Can also be developed during the transition between analysis and structured design

• Can be used to describe complex interactions

• Can be used to describe alternative approaches

• Uses some symbols from flow charts – DFD are good at capturing flow of data within a

workflow (but not control)

– Flow charts and activity charts can represent control flow but don’t represent data flow

25/02/2015

27

53

54

20/04/2015

1

7 Systems Analysis and Design in a

Changing World, Fifth Edition

7

2

The Unified Modeling Language and the Object Management Group

Object-oriented modeling notation is Unified Modeling Language (UML)

UML was presented to Object Management Group (OMG) as standard modeling technique

Purpose of Object Management Group

Promote theory and practice of object technology for development of distributed systems

Provide common architectural framework for OO

20/04/2015

2

7

3

Object-Oriented Requirements

Object-oriented system requirements are specified and documented through process of building models

Systems development process starts with identification of events and things

Events are business processes that new system must address

Things are problem domain objects involved in business process

7

4

Object-Oriented Approach Models

Class diagram – definition of system components

Use case diagrams and use case descriptions – What are user roles and how they use the system

Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case

Statechart diagrams – describe states of each object

Activity diagrams – describe user activities

20/04/2015

3

7

Overview

The objective of requirements definition is understanding – understanding the users’ needs, the business processes, and the systems to support business processes

Understand and define requirements for a new system using object-oriented analysis models and techniques

Line between object-oriented analysis and object-oriented design is somewhat fuzzy

Iterative approach to development

Models built in analysis are refined during design


7

6

Requirements Diagrams: Traditional and OO Models

20/04/2015

4

7

7

The Class Diagram

There are two kinds of descriptions of systems

Structural information (components of the system)

Behavioral information (logic performed by components)

Class diagram provides definition of structural components of the system

The other OO diagrams (e.g. use case, sequence, collaboration) focus on activities the system performs

NOTE – with OO Analysis, the class diagrams describes system requirements that can map very closely to the structure (i.e. classes) in the OO computer program that will be eventually created

7

8

Generalization/Specialization Hierarchies

• Hierarchies that structure or rank classes from the more general superclass to the more specialized subclasses (sometimes called inheritance hierarchies)

• Generalizations • group similar types of things like all cars share certain

features (e.g. all cars have wheels, engine etc.)

• Specializations

• are judgments that categorize different types of things (e.g. sports car is a special type of car)

• A generalization/specialization hierarchy structures things from the general down to the more special – Each class has a more general class above it – a superclass

– A class may have a more specialized class below – a subclass

20/04/2015

5

7

9

7

10

20/04/2015

6

7

•Inheritance: a concept that allows subclasses to share characteristics of their superclasses

•E.g. a sports car has everything a car has (e.g. 4 wheels and an engine, which it “inherits” from the class car which is above it)

•The sports car then specializes

E.g. has a sports option, racing wheels etc.

11

Inheritance

7

12

Aggregation (Whole-Part Hierarchies)

•Can also structure things by defining them in terms of parts •Aggregation: A relationship between and object and its parts •E.g. aggregation in the context of a computer system, a computer system is made up of: - processor, main memory, keyboard, disk storage, monitor

20/04/2015

7

7

13

7

14

Example of Class Diagram Notation

20/04/2015

8

7

15

Another Example of Class Diagram Notation

7 The System Activities—

A Use Case/Scenario View

Use case analysis used to identify and define all business processes that system must support

Use case – an activity a system carried out, usually in response to a user request

Actor

Role played by user

Outside automation boundary


20/04/2015

9

7

Use Case Diagram

Graphical UML diagram that summarizes information about actors and use cases

Simple diagram shows overview of functional requirements

Can have multiple use case diagrams

By subsystem

By actor


7

Simple Use Case with an Actor


Figure 7-2

20/04/2015

10

7 Use Case Diagram with Automation Boundary and Alternate Actor Notation


Figure 7-3

7 All Use Cases Involving Customer as Actor


Figure 7-4

20/04/2015

11

7 Use Cases of RMO Order Entry Subsystem


Figure 7-5 (partial figure)

7

<<Includes>> Relationship

Documents situation in which one use case requires the services of a common subroutine

Another use case is developed for this common subroutine

A common use case can be reused by multiple use cases


20/04/2015

12

7 Example of Order-Entry Subsystem with <<Includes>> Use Cases


Figure 7-6

7

Developing a Use Case Diagram

Underlying conditions for describing use cases

Based on automated system, e.g. users “touch” the system

Assume perfect technology condition

Iterate through these two steps

Identify actors as roles

List goals, e.g. use cases, for each actor. A goal is a unit of work.

Finalize with a CRUD analysis to ensure completeness


20/04/2015

13

7

RMO Activity-Data Matrix (CRUD)


Figure 6-34

7

Activity Diagrams

Used to document workflow of business process activities for each use case or scenario

Standard UML 2.0 diagram as seen in Chapter 4

Can support any level of use case description; a supplement to use case descriptions

Helpful in developing system sequence diagrams


20/04/2015

14

7

Activity Diagram— Telephone

Order Scenario


Figure 7-8

7

Activity Diagram— Web Order Scenario


Figure 7-9

20/04/2015

15

7 Identifying Inputs and Outputs— The System Sequence Diagram

Interaction diagram – a communication diagram or a sequence diagram

System sequence diagram (SSD) is type of UML 2.0 interaction diagram

Used to model input and output messaging requirements for a use case or scenario

Shows sequence of interactions as messages during flow of activities

System is shown as one object: a “black box”


7

SSD Notation

Lifeline or object lifeline is a vertical line under object or actor to show passage of time for object

Message is labeled on arrows to show messages sent to or received by actor or system

Actor is role interacting with the system with messages

Object is the component that interacts with actors and other objects


20/04/2015

16

7 System Sequence Diagram (SSD)

Notation


Figure 7-10

7

SSD Lifelines

Vertical line under object or actor

Shows passage of time

If vertical line dashed

Creation and destruction of thing is not important for scenario

Long narrow rectangles

Activation lifelines emphasize that object is active only during part of scenario


20/04/2015

17

7

SSD Messages

Internal events identified by the flow of objects in a scenario

Requests from one actor or object to another to do some action

Invoke a particular method


7

Repeating Message


Figure 7-11

20/04/2015

18

7 Developing a System Sequence

Diagram

Begin with detailed description of use case from fully developed form or activity diagram

Identify input messages

Describe message from external actor to system using message notation

Identify and add any special conditions on input message, including iteration and true/false conditions

Identify and add output return messages


7 Activity Diagram of the Telephone Order Scenario


Figure 7-12

20/04/2015

19

7 Resulting SSD for the Telephone Order Scenario


Figure 7-13

7

SSD of the Web Order Scenario for the Create

New Order Use case


Figure 7-14

20/04/2015

20

7 Identifying Object Behavior— The State Machine Diagram

State machine diagram is UML 2.0 diagram that models object states and transitions

Complex problem domain classes can be modeled

State of an object

A condition that occurs during its life when it satisfies some criterion, performs some action, or waits for an event

Each state has unique name and is a semipermanent condition or status

Transition

The movement of an object from one state to another state


7 Simple State Machine Diagram for a

Printer


Figure 7-15

20/04/2015

21

7 State Machine Terminology

Pseudostate – the starting point of a state machine, indicated by a black dot

Origin state – the original state of an object from which the transition occurs

Destination state – the state to which an object moves after the completion of a transition

Message event – the trigger for a transition, which causes the object to leave the origin state

Guard condition – a true/false test to see whether a transition can fire

Action expression – a description of the activities performed as part of a transition


7 Composite States and Concurrency—

States within a State


Figure 7-16

20/04/2015

22

7 Concurrent Paths for Printer in the On State


Figure 7-17

7 Rules for Developing State Machine

Diagram Review domain class diagram, select important ones,

and list all state and exit conditions

Begin building state machine diagram fragments for each class

Sequence fragments in correct order and review for independent and concurrent paths

Expand each transition with message event, guard-condition, and action-expression

Review and test each state machine diagram


20/04/2015

23

7 States and Exit Transitions for

OrderItem


Figure 7-18

7

Partial State Machine for OrderItem


Figure 7-19

20/04/2015

24

7

Final State Machine for OrderItem


Figure 7-20

7 Order Domain Class for RMO—

States and Exit Transitions


Figure 7-21

20/04/2015

25

7 First-Cut State Machine Diagram for

Order


Figure 7-22

7 Second-Cut State Machine Diagram for Order


Figure 7-23

20/04/2015

26

7

Integrating Object-Oriented Models

Complete use case diagram is needed to understand total scope of new system

Domain model class diagrams should also be as complete as possible for entire system

With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration

Development of a new diagram often helps refine and correct previous diagrams


7 Relationships Between OO

Requirements Models


Figure 7-24

20/04/2015

1

ITEC 3010

Environments, Alternatives and Decisions

Major Activities in the Analysis Phase

• Gather information

• Define system requirements

• Prototype for feasibility and discover

• Prioritize requirements

• Generate and evaluate alternatives

• Review recommendations with management

The focus of chapter 8 is on the last three activities

(the transition from analysis to solutions and design)

20/04/2015

2

The end of the Analysis Phase

• During analysis many more requirements may be determined than can be dealt with

• Must prioritize and evaluate them

• Several alternative packages of requirements may be developed

• A committee of executives and users will decide which are most important

• Must select a system scope and level of automation

• Methods of development are reviewed

Assessing the Target Processing Environment

• Target processing environment

– Configuration of computer equipment, operating systems and networks that will exist when the new system is deployed

• Must be a stable environment to support the new system

• Design and implementation of the processing environment is one of the early activities in moving from analysis to design

20/04/2015

3

Centralized Systems

• Prior to the early 1980’s there was only one environment – the mainframe computer system at a central location

• Options focused around what kind of input or output to these large systems

• Common to large-scale batch processing applications (e.g. banking, insurance, government etc.) where: – Some input transactions don’t need to be processed in real

time

– On-line data entry personnel can be centrally located

– Large numbers of periodic outputs are produced

• Often used for a subsystem of a larger, sometimes distributed information system

Single Computer Architecture

• Places all information system resources on a single computer system and its attached peripherals

• Requires all users be located near the computer

• Advantage is simplicity and ease of maintenance

• However, many systems require more computing power than one single machine can provide

20/04/2015

4

Clustered and Multicomputer Architectures

• A group of computers of the same type that have the same operating environment and share resources

• Computers from the same manufacturer are networked

• Clusters act like a single large computer system

• One may act as entry point and the others function as slave computers

Multicomputer architecture

• A group of dissimilar computers that are linked together but the hardware and operating systems are not required to be a similar as in the clustered architecture

• System still functions like one single large computer

• Can have central computer and slave computers – Main computer may execute programs and hold

database

– The front-end computer may handle all communication

20/04/2015

5

Distributed Computing

• Distributed computing

– The approach to distributing a system across several computers and locations

• E.g. corporate financial data might be stored on a centralized mainframe, linked to minicomputers in regional office and personal computers at more locations

• Relies on computer networks to connect up the systems

20/04/2015

6

Client-Server Architecture

• Currently the dominant architectural model for distributing information resources – Server computer (server): A computer that provides services

to other computers on the network

– Client computer: A computer that requests services from other computers on the network

• E.g. print server on a network, that clients (other PCs on the network) can send print jobs to

• Middleware – Computer software that implements communication

protocols on the network and helps different systems communicate

• Data layer – A layer on a client-server configuration that contains the

database

20/04/2015

7

Three Layer Client-Server Architecture

• An information system application program can be divided into the following set of client and server processes or layers

• Three-layer architecture – The data layer

• Manages stored data, implemented as one or more databases

– The business logic layer • Implements the rules and procedures of business processing

– The view layer • Accepts user input, and formats and displays processing results

• View layer acts as client of the business logic layer, which acts a a client of the data layer

20/04/2015

8

Notes on Three Layer Architecture

• Easy to distribute and replicate over a network

• Layers are relatively independent of each other

• Can be expanded into a larger number of layers

• N-layer architectures, or n-tiered architectures

– A client-server architecture that contains n layers

The Internet and Intranets

• Internet: a global collection of networks that are interconnected using a common low-level networking standard – TCP/IP (Transmission Control Protocol/Internet Protocol)

• Services provided by the Internet

– E-mail protocols (Simple Mail Transfer Protocol – SMTP)

– File transfer protocols (e.g. File Transfer Protocol – FTP)

– Remote login and process execution protocols (e.g. Telnet)

20/04/2015

9

Intranets and Extranets

• Intranet – A private network that is accessible to a limited number of

users, but which used the same TCP/IP protocol as the Internet

– Restricted access – firewalls, passwords, unadvertised

• Extranet – An intranet that has been extended outside of the

organization to facilitate the flow of information (e.g. access to suppliers, customers, and strategic partners)

– Allows organizations to exchange information and form a virtual organization

• The Web is organized as a client-server architecture – Web processes are managed by server processes that

execute on dedicated servers and clients send requests to servers using a standard web resource request protocol

The Internet as an Application Platform

• The Internet provides an alternative for implementing systems – E.g. RMO buyer can access the system while on the

road – the client portion of the application is installed on their laptop computers (uses modem/wi-fi/… to connect)

– Using the WWW for accessing the remote site, all the buyer needs is a web browser and is now accessible from any computer with Internet access

• Use of the Internet greatly expands accessibility and eliminates need to install custom client software – also cheaper to put up on the Web

20/04/2015

10

Advantages of WWW over traditional client-server approaches

• Accessibility – Web browser and Internet connections are nearly

ubiquitous and are accessible to large numbers of users

• Low-cost communication – High-capacity WAN form the Internet backbone are

funded primarily by governments (a company can use the Internet as a low-cost WAN)

• Widely implemented standards – Web standards are well known and many computer

professionals are trained in their use

– Use of intranet or extranet enjoys all the advantages of web delivery

– Really represents evolution of client-server computing to the WWW

Negative Aspects of Application

• Security – Web servers are well-defined target for security

breaches

• Reliability – Internet protocols do not guarantee a minimum level of

network through put or that a message

• Throughput – Data transfer capacity of many users limited by analog

modems to under 56 kilobits per second

• Volatile standards – Web standards change rapidly

20/04/2015

11

Development and System Software Environments

• Development environment

– Consists of standards and tools used in an organization

– E.g. CASE tools, programming standards

• System software environment

– Includes operating system, network protocols, database management systems etc.

• Important activity during analysis

– To determine the components of the environment that will control the development of the new application

Important components of the environment that will affect the project

• Language environment and expertise – Companies often have preferred languages

– Numerous languages out there – COBOL, C++, Visual Basic, to web-based languages like Java and Perl Script

– Choosing a new language requires additional work

• Existing CASE tools and methodologies – If a company has invested heavily in a CASE tool then

all new development may have to conform to it

• Required interfaces to other systems – A new system typically must provide information to

and receive it from existing systems

20/04/2015

12

• Operating System environment

– Strategic goals may exist to change the operating system

– Multiple platforms may be needed

– Legacy systems are often still there and may be linked to newer client-server applications and databases

• Database management system (DBMS)

– Many corporations have committed to a particular database vendor

– May require a distributed database environment with portions distributed over the country

Deciding on Scope and Level of Automation

• Scope of a system

– E.g. current RMO point-of-sales system’s scope includes handling mail and telephone sales but not Internet

• Level of Automation

– In the new system a very low level of automation is needed for telephone sales aspects

• “Scope creep”

– A problem with development projects where requests for additional features just keeps continuing

– To avoid we need to formalize the process of selecting which functions are critical or not

– We need to Prioritize Requirements

20/04/2015

13

Scoping Table

• Scoping table: a tabular list of all the functions to be included within a system

• It is an expanded version of the event table

• It may include events from the event table plus some identified later on

• Each business function can be prioritized – Mandatory

– Important

– Desirable

20/04/2015

14

Defining Level of Automation

• Level of automation – The kind of support the system will provide for each function

• Low, middle, high

– E.g. low level is using computer for order-entry function, high level is using computer to support high-level decision making by human

• Low end is basically an automated version of a current manual procedure

– A high level occurs when system takes over as much as possible the processing of the function

• High end often involves creating new processes and procedures

20/04/2015

15

Rocky Mountain Outfitters – example of functions of a high-end system

– Customers can access catalog on-line with 3D pictures over the WWW

– The catalog is also interactive and allows customer to combine items

– The user interface is voice-activated

– Payment is verified on-line

– The customer can see a history of all prior orders and can check the status of any order over the WWW or telephone

20/04/2015

16

Selecting Alternatives

• More and more new systems are being used to provide high-level automation solutions

• Criteria used to decide which functions to support and level of automation are based on

– Strategic IT plan

– Feasibility study • Economic feasibility

• Operational, organizational and cultural feasibility

• Technological feasibility

• Schedule and resource feasibility

Evaluation of Alternatives for RMO example

• Project team decided to include all functions that were classified as mandatory or important

• For each, a detailed analysis was done to determine level of automation

• A table or list can be made of preliminary selection of which functions to include and at what level of automation

• For most functions, a medium level of automation was selected (see shaded boxes)

• See next slide for part of that table

20/04/2015

17

Generating Alternatives for Implementation

• Now ask “where do we go from here?”

• Options include buying a computer program if the application is fairly standard OR company may decide to build the system from ground up

• Next figure shows this in a graph – Vertical column is the build-versus-buy axis (at the top

of the axis the entire system is bought as a package)

– In between is a combination of buy and build

– There a various alternatives ranging from in-house development to purchasing a complete ERP system

20/04/2015

18

Cloud

In-House Development

• Large and medium-sized companies have in-house development staff

• A problem with this is that special technical expertise may be beyond employees’ experience

• So may use company employees to manage and staff projects, but also call in consultants when needed

• Advantage

– Control of project and knowledge retained in the company

– Company can build internal expertise

• Disadvantage

– In-house staff may not know when they need assistance

20/04/2015

19

Custom Software Development

• A solution that is developed by an outside service provider – New system is developed from scratch (using SDLC)

– But project team consist mainly of outside consultants

– Advantages of custom development: • consulting firm may have developed similar systems and has good

knowledge of the domain and pool of qualified staff

– Outsourcing and contract development are the fastest growing segments of the IS industry

– Disadvantage: • the cost (paying at high consulting hourly wages – e.g. $100 per hour

is typical)

– Opted for when no in-house expertise or tight schedules

– Often for large systems (e.g. health care) where cost is outweighed by savings due to high volume of use of system

Packaged and Turnkey Software Systems

• Packaged software: software that is already built and can be purchased as a package – Strict definition is that software is used as is, with no change

– E.g. a standard reporting system package may work for some of the companies requirements

• Turnkey system: a complete system solution, including software and hardware, that can be just turned on – Companies creating these systems usually specialize in a

particular industry

– But problem is that often they don’t exactly meet the needs of an organization

– May allow for vendor to customize part of it to better suit needs

– Company may buy base system + a number of customization changes and a service agreement (e.g. hospital systems)

20/04/2015

20

• In some cases only executable code is provided, other cases include both source and executable

• Vendor may make the changes or company itself might (if it has programmers)

• Enterprise Resource Planning (ERP) – A turnkey system that includes all organizational

functions of an organization (e.g. companies such as SAP, Oracle provide these)

– May take longer than a year to install

– Can cost millions

– Advantage of ERP: a new system can often be obtained at a much lower cost than in-house development, also risks may be lower

– Disadvantage of ERP: system may not do exactly what the organization needs (even after customization). Customization can also take quite a long time and money

Facilities Management / Cloud

• Facilities management: the outsourcing of all data processing and information technology to an outside vendor – E.g. a bank my hire a facilities management firm to

provide all of the data processing including software, networks and even technical staff

– Typically part of a long-term strategic plan for an entire organization

– Contracts cost a lot (millions) – example EDS (Electronic Data Systems)

20/04/2015

21

Choosing an Alternative for Implementation

• Identifying Criteria for Selection – Criteria will be used to compare alternative choices

(e.g. in-house or outsourcing)

– Three general areas to consider • General requirements

• Technical requirements

• Functional requirements

– General requirements include • Feasibility assessment (scope and level of automation)

• Each alternative must meet the requirements of – Cost

– Technology

– Operations

– schedule

• For outsourced alternatives

– The providers stability and performance record is also important

• For in-house alternatives

– Must consider risks, length of schedule and availability of in-house expertise

• Must evaluate for total cost and impact on the organization of alternatives

20/04/2015

22

• Criteria for assessment of alternatives – The performance record of the provider

– Level of technical support from the provider

– Availability of experienced staff

– Development costs

– Expected value of benefits

– Length of time (schedule) until deployment

– Impact on internal resources

– Requirements for internal expertise

– Organizational impacts (retraining, skill levels)

– Expected cost of data conversion

– Warranties and support services (from outside vendors)

• Relative importance of each criteria can be weighted on a 5-point scale (a weighting scale) – 1 indicates low importance

– 5 indicates high importance

• Also for each alternative we can rate the alternative for that criteria, on a five point scale – 1 indicates the alternative is weak for that criteria

– 5 indicates the alternative is strong on that criteria

• Then we can multiply the importance of a criteria by its rating for each alternative to get extended scores

• Finally, we can add up the extended scores for all alternatives and see which comes up best

20/04/2015

23

• In addition to general requirements, we should include criteria to evaluate the quality of the software – Robustness (software does not crash)

– Programming errors (software calculates correctly)

– Quality of code (maintainability)

– Documentation

– Easy installation

– Flexibility (adjusts to new functionality and environments

– Structure (maintainable, easy to understand)

– User-friendliness

• Can do tables for the above technical requirements and also for functional requirements (tables 8-8 and 8-9) on next slides

20/04/2015

24

20/04/2015

25

Making the Selection – the RMO example

• Once each alternative is evaluated with a raw score

• In RMO example, the first three alternatives rank very close together on general requirements (with in-house slightly better than the others)

• The other tables show the in-house and custom development very close as best

• RMO therefore decides to go with in-house and hire consultants as needed

• RMO is now ready to proceed with the project

20/04/2015

1

1

ITEC 3010 Design

2

20/04/2015

2

3

4

The Structure Chart

• Structure chart – A hierarchical diagram showing the relationships

between the modules of a computer program

– The objective of structured design is to create a top-down decomposition of the functions to be performed by a given program in a system – use a structure chart to show this

– E.g. shows functions and sub functions (such as Calculate base amount, Calculate overtime amount etc.)

– Uses rectangles to represent each such module (the basic component of a structure chart

– Higher-level modules are “control” modules that control flow of execution (call lower level modules which are the “worker bee” modules that contain program logic)

20/04/2015

3

5

6

Structure Chart characteristics

• Structure chart is based on the idea of modular programming (and top-down programming) – Breaking a complex problem down into smaller

modules

– Modules are well formed with high internal cohesiveness and minimum data coupling

– Vertical lines connecting the modules indicate calling structure

– Little arrows next to the lines show the data passed between modules (inputs and outputs)

• Data couples: individual items that are passed between modules

• Program call: the transfer of control from a module to a subordinate module to perform a requested service (can be implemented as e.g. a function or procedure call)

20/04/2015

4

7

Structure Chart Symbols

• Rectangles represent modules – Can represent a function (e.g. C), a procedure (e.g. Pascal), a

paragraph (e.g. COBOL) , subroutine (e.g. FORTRAN) etc.

– Rectangle with double bars represents a module used several places (optional)

• Little arrows with open circles represent data couples

• Little arrows with closed circles represent control couple flag (e.g. end of file flag)

• Curved arrows immediately below a boss module represents iteration (looping)

• Darkened diamond represents a conditional call to lower modules

8

20/04/2015

5

9

10

Notes on Structure Chart

• Each module should do a very specific function

• Module at top of the tree is the boss module – Function is to call modules on level below, pass

information to them

• Middle level modules control the modules below – Call them and pass data

• At the very bottom, the leaves contain the actual algorithms to carry out the program functions

• Call of modules is left to right across the tree

20/04/2015

6

11

Developing a Structure Chart

• Transaction analysis – The development of a structure chart based on a DFD

that describes the processing for several types of transactions

– Uses as input the system flow chart and the event table to develop the top level of the tree in a structure chart

• Transform analysis – The development of a structure chart based on a DFD

that describes the input-process-output data flow

– Used to develop the subtrees in a structure chart – one for each event in the program

12

Transaction Analysis

• First step is to identify the major programs

– Can do it by looking at the system flow chart and identifying the major programs

• For a subsystem or program we want to make a structure chart for, we can look at the event-partitioned DFD to identify the major processes

– See next slide, shows event-partitioned DFD for the order-entry subsystem for RMO example, showing 5 major processes

– These major processes will become the modules in the resulting high level structure chart (see slide after that)

• Sub-System DFD and DFD Level 0 are also a good source

20/04/2015

7

13

14

20/04/2015

8

15

Transform Analysis

• Based on the idea that computer program “transforms” input data into output data

• Structure charts developed with transform analysis usually have 3 main subtrees – Input subtree to get data

– A calculate subtree to perform logic

– An output subtree to write the results

• Can create it rearranging elements from – DFD fragment for an event (e.g. “create new order”)

– The detailed DFD for that event

• E.g. see next two slides for “create new order” DFD fragment, and its corresponding detailed DFD

16

20/04/2015

9

17

18

Steps for creating the structure chart from the DFD

1. Identify the primary information flow

2. Find the process that represents the most fundamental change from an input stream to an output stream – the central transform

• Afferent data flow: the incoming data flow in a sequential set of process bubbles

• Efferent data flow: the outgoing data flow from a sequential set of process bubbles

• Central transform: the central processing bubbles in a transform analysis type of data flow

• In our example, the record (build) order process is the central process

20/04/2015

10

19

Steps continued

3. Redraw the data flow diagram (DFD) with

– The inputs to the left

– The central transform process in the middle

– The outputs to the right

– The parent process (top level – e.g. “Create new order”) above the central transform process (e.g. “Build order”)

– See next slide

20

Record Order

20/04/2015

11

21

Steps continued

4. Generate the first-draft structure chart including data couples (directly from our rearranged DFD on the previous slide)

• See next slide

22

Record Order

20/04/2015

12

23

Steps continued

5. Add other modules as necessary to

– Get input data via the user-interface screens

– Read and write to the data stores

– Write output data or reports

• These are lower level modules (utility modules)

• Also add data couples

• See next slide

24

Record Order

20/04/2015

13

25

Final Steps

6. Using structured English or decision table documentation, add any other required intermediate relationships (e.g. looping and decision symbols)

7. Make the final refinements to the structure chart based on quality control concepts (to be discussed)

26

Combining the top-level structure chart with the chart developed by transaction analysis

• Basically “glue” the diagram we made (high-level) using transaction analysis on top of the more detailed diagram (for lower-processing) we just made using transform analysis

• See next slide

20/04/2015

14

27

28

Evaluating the Quality of a Structure Chart

• Module coupling – The manner in which modules relate to each other

• Desirable to have loosely coupled modules – have modules as independent as possible

– Module does not need to know who invoked it

– Best coupling is through simple data coupling • The module is called and a specific set of data items is passed

• Module function performs its function and returns the output

20/04/2015

15

29

Evaluating Structure Charts (continued)

• Cohesion – Refers to the degree to which all of the code within a

module contributes to implementing one well-defined task

• Desirable to have modules with high cohesion implementing a single function – Modules that implement a single task tend to have

relatively low coupling because all of their internal code acts on the same data item(s)

– Modules with poor cohesion tend to have high coupling because loosely related tasks are typically performed on different data items across modules

– A flag passed down the structure chart is an indicator of poor cohesion

30

20/04/2015

16

31

Designing the Application Architecture: The Object-Oriented Approach

• Object-oriented design models provide the bridge between the object-oriented analysis models and the object-oriented programs

• Object-oriented programs

– Basic concept: the program consists of a set of program objects that cooperate to accomplish a result

– Objects work together by sending messages

– Example: in a graphical user interface (GUI) windows and menus are objects. If you click on a window object a message is sent to display itself (e.g. window, a menu bar etc.)

32

Differences between object oriented and traditional approaches

• In traditional computer environments there is some sort of central control – E.g. a mainframe computer may be connected to

thousands of terminals and controls them centrally

– No terminal does work unless directed to by the mainframe

• In object-oriented environment – Analogy to a network of nodes, where each node can

send messages to other independently, but all still work together, not centrally controlled (no one may be in charge)

20/04/2015

17

33

Overview

• Programmers use models to code the system

• Two most important models are design class diagrams and interaction diagrams (sequence diagrams and collaboration diagrams)

• Class diagrams are developed for domain, view, and data access layers

• Interaction diagrams extend system sequence diagrams

34

Object-Oriented Design – The Bridge Between Analysis and Programming

• Bridge between user’s requirements and new system’s programming

• Object-oriented design is the process by which detailed object-oriented models are built

• Programmers use the design to write code and test new system

• User-interface, network, controls, security, and database requires design tasks and models

20/04/2015

18

35

Overview of Object-Oriented Programs

• Set of objects that cooperate to accomplish result

• Object contains program logic and necessary attributes in a single unit

• Objects send each other messages and collaborate to support functions of main program

• OO system designer provides detail for programmers

– Design class diagrams, interaction diagrams, (some) statechart diagrams

36

Simplified Design Class for Student Class

20/04/2015

19

37

Object-Oriented Design Processes and Models

• Diagrams developed during analysis

– Use case diagrams, use case descriptions and activity diagrams, domain model class diagrams, and system sequence diagrams

• Diagrams developed during design

– Design class diagrams – set of object-oriented classes needed for programming, navigation between classes, attribute names and properties and method names and properties

– Interaction diagrams, package diagrams

38

Design Models with Their Respective Input Models

20/04/2015

20

39

Iterative Process of OO Design

• Create preliminary design class diagrams model

• Develop interaction diagrams for each use case or scenario (realization of use cases)

• Return to design class diagram – Develop method names based on the design of

interaction diagrams

– Update navigation visibility and attributes

• Partition design class diagram into related functions using package diagrams (subsystems or layers)

40

Design Class Symbols

• UML does not distinguish between design class notation and domain model notation

• Domain modeling shows users’ work environment

• Design class specifically defines software classes

• UML uses stereotype notation to categorize a model element by its characteristics

20/04/2015

21

41

Standard Stereotypes Found in Design Models

42

Standard Design Classes

• Entity – design identifier for problem domain class – Persistent class – exists after system is shut

down

• Boundary – designed to live on system’s automation boundary – User interface and windows classes

• Control – mediates between boundary and entity classes, between the view layer and domain layer

• Data access – retrieve from and send data to database

20/04/2015

22

43

Design Class Notation

• Name – class name and stereotype information

• Attributes – visibility (private or public), attribute name, type-expression, initial-value, property

• Method signature – information needed to invoke (or call) the method – Method visibility, method name, type-

expression (return parameter), method parameter list (incoming arguments)

– Overloaded method – method with same name but two or more different parameter lists

44

Internal Symbols Used to Define a Design Class

20/04/2015

23

45

Student Class Examples for the Domain Diagram and the Design

Class Diagram

46

Some Fundamental Design Principles

• Encapsulation – each object is self-contained unit that includes data and methods that access data

• Object reuse – designers often reuse same classes for windows components

• Information hiding – data associated with object is not visible to outside world

• Navigation visibility – object is able to view and interact with another object

20/04/2015

24

47

Navigation Visibility Between Customer and Order

48

Coupling and Cohesion • Coupling – qualitative measure of how

closely classes in a design class diagram are linked

– Number of navigation arrows on design class diagram

– Low: system is easier to understand and maintain

• Cohesion – qualitative measure of consistency of functions within a single class

– Separation of responsibility – divide low cohesive class into several highly cohesive classes

20/04/2015

25

49

Developing the First-Cut Design Class Diagram

• Extend domain model class diagram:

– Elaborate attributes with type and initial value information

– Add navigation visibility arrows

• Detailed design proceeds, use case by use case:

– Interaction diagrams implement navigation

– Navigation arrows are updated to be consistent

– Method signatures are added to each class

50

RMO Domain Model Class Diagram

20/04/2015

26

51

First-cut RMO Design Class Diagram

52

Interaction Diagrams – Realizing Use Case and Defining Methods

• Realization of use case done through interaction diagram development

• Determine what objects collaborate by sending messages to each other to carry out use case

• Sequence diagrams and collaboration diagrams represent results of design decision

20/04/2015

27

53

Partial Design Class Diagram for the Look Up Item Availability Use Case

54

Object Responsibility

• Objects responsible for system processing

• Knowing about object’s own data and other classes with which it collaborates to carry out use cases

• Doing activities to assist in execution of use case

– Receive and process messages

– Instantiate, or create, new objects required to complete use case

20/04/2015

28

55

Use Case Controller

• System sequence diagram (SSD) shows input messages from external actors within use case

• Only indicates that messages go to system

• Use case controller classes are designed as collection point for incoming messages

• Use case controller acts as intermediary between outside world and internal system

56

Designing with Sequence Diagrams

• Sequence diagrams used to explain object interactions and document design decisions

• Documents inputs to and outputs from system for single use case or scenario

• Captures interactions between system and external world as represented by actors

• Inputs are messages from actor to system

• Outputs are return messages showing data

20/04/2015

29

57

SSD for the Look Up Item Availability Use Case

58

First-Cut Sequence Diagram

• Start with elements from SSD

• Replace :System object with use case controller

• Add other objects to be included in use case

– Select input message from the use case

– Add all objects that must collaborate

• Determine other messages to be sent

– Which object is source and destination of each message?

20/04/2015

30

59

Objects included in Look Up Item Availability

60

First-Cut Sequence Diagram for the Look Up Item Availability Use Case

20/04/2015

31

61

Guidelines for Preliminary Sequence Diagram Development

• Take each input message and determine internal messages that result from that input

– For that message, determine its objective

– Needed information, class destination, class source, and objects created as a result

• Identify complete set of classes affected by each input message

– Select objects from domain class diagram

• Flesh out components for each message

62

Developing a Multilayer Design for Look up item availability

• First-cut sequence diagram – classes in domain layer

• Add design for user-interface classes – view layer

– Forms added as windows classes to sequence diagram

• Add design for data access classes – data access layer with separate classes for database

• Tools build GUI and problem domain classes

– Java and Visual Studio.NET

20/04/2015

32

63

Look Up Item Availability Use Case with View Layer and User-Interface Object

64

Partial Three-Layer Design for Look Up Item Availability

20/04/2015

33

65

Designing with Collaboration Diagrams

• Collaboration diagrams and sequence diagrams

– Both are interaction diagrams

– Both capture same information

– Process of designing is same for both

• Model used is designer’s personal preference

– Sequence diagram – because use case descriptions and dialog follow sequence of steps

– Collaboration diagram – emphasizes coupling

66

The Symbols of a Collaboration Diagram

20/04/2015

34

67

A Collaboration Diagram for Look Up Item Availability

68

Look Up Item Availability Use Case Using Iconic Symbols

20/04/2015

35

69

Updating the Design Class Diagram

• Design class diagrams developed for each layer

– New classes for view layer and data access layer

– New classes for domain layer use case controllers

• Sequence diagram’s messages used to add methods

– Constructor methods,

– Data get and set method

– Use case specific methods

70

Design Class, with Method Signatures, for the Order class

20/04/2015

36

71

Updated Design Class Diagram for the Domain Layer

72

Package Diagrams – Structuring the Major Components

• High-level diagram in UML to associate classes of related groups

• Identifies major components of a system and dependencies

• Determines final program partitions for each layer

– View, domain, data access

• Can divide system into subsystem and show nesting within packages

20/04/2015

37

73

Partial Design of a Three-Layer Package Diagram for RMO

74

RMO Subsystem Packages

20/04/2015

1

1

Designing Inputs, Outputs, and Controls

2

Final Exam

• Chapters 1 to 12 and 14 and 15(5th Edition)

• 20 multiple choices

• 3 or 4 short questions

• OO diagram

– Use Case

– Class

– Sequence

20/04/2015

2

3

Overview • This chapter focuses on system interfaces,

system outputs, and system controls that do not require much human interaction

• Many system interfaces are electronic transmissions or paper outputs to external agents

• System developers need to design and implement integrity and security controls to protect system and its data

• Outside threats from Internet and e-commerce are growing concern

4

Identifying System Interfaces

• System interfaces are broadly defined as inputs or outputs with minimal or no human intervention – Inputs from other systems (messages, EDI)

– Highly automated input devices such as scanners

– Inputs that are from data in external databases

– Outputs to external databases

– Outputs to other systems

20/04/2015

3

Identifying System Interfaces – Real-time connections (both input and output)

– Sensors !! • 30 billion RFID tags and 4.6 billion camera phones are used

around the world today. In addition, 200 million smart meters to be operated in 2014. Moreover, there were 2 billion people on web in 2011

»

» BIG DATA

5

Amount of new data stored varies across geography. New data stored (in Petabytes – 1M Gbytes - (PB)) by geography in 2010. New data stored is defined as the amount of available storage used in a given year [9].

6

Full Range of Inputs and Outputs

20/04/2015

4

7

eXtensible Markup Language (XML)

• Extension of HTML that embeds self-defined data structures in textual messages

• Transaction that contains data fields can be sent with XML codes to define meaning of data fields

• XML provides common system-to-system interface

• XML is simple and readable by people

• Web services is based on XML to send business transactions over Internet

8

System-to-System Interface Based on XML

Before XML This would be something like: RM010989;william jones;120 Roundabout Road;Los Angeles ….

20/04/2015

5

9

Design of System Inputs

• Identify devices and mechanisms used to enter input – High-level review of most up-to-date methods

to enter data

• Identify all system inputs and develop list of data content for each – Provide link between design of application

software and design of user and system interfaces

• Determine controls and security necessary for each system input

10

Input Devices and Mechanisms

• Capture data as close to original source as possible

• Use electronic devices and automatic entry whenever possible

• Avoid human involvement as much as possible

• Seek information in electronic form to avoid data re-entry

• Validate and correct information at entry point

20/04/2015

6

11

Prevalent Input Devices to Avoid Human Data Entry

• Magnetic card strip readers

• Bar code readers

• Optical character recognition readers and scanners

• Radio-frequency identification tags

• Touch screens and devices

• Electronic pens and writing surfaces

• Digitizers, such as digital cameras and digital audio devices

• Sensors !!

12

Defining the Details of System Inputs

• Ensure all data inputs are identified and specified correctly

• Can use traditional structured models – Identify automation boundary

• Use DFD fragments

• Segment by program boundaries

– Examine structure charts • Analyze each module and data couple

• List individual data fields

20/04/2015

7

13

Automation Boundary on a System-Level DFD

14

20/04/2015

8

15

List of Inputs for Customer Support System

16

Using Object-Oriented Models

• Identifying user and system inputs with OO approach has same tasks as traditional approach

• OO diagrams are used instead of DFDs and structure charts

• System sequence diagrams identify each incoming message

• Design class diagrams and sequence diagrams identify and describe input parameters and verify characteristics of inputs

20/04/2015

9

17

System Sequence Diagram for Create New Order

18

Input Messages and Data Parameters from RMO System Sequence Diagram

(Figure 14-10)

20/04/2015

10

19

Designing System Outputs

• Determine each type of output

• Make list of specific system outputs required based on application design

• Specify any necessary controls to protect information provided in output

• Design and prototype output layout

• Ad hoc reports – designed as needed by user

20

Designing Reports and Statements

• Printed versus electronic

• Types of output reports

– Detailed

– Summary

– Exception

– Executive

• Internal versus external

• Graphical and multimedia presentation

20/04/2015

11

21

RMO Summary Report with Drill Down to the Detailed Report

22

Formatting Reports

• What is the objective of report?

• Who is the intended audience?

• What is the media for presentation?

• Avoid information overload

• Format considerations include meaningful headings, date of information, date report produced, page numbers

20/04/2015

12

23

Designing Integrity Controls

• Mechanisms and procedures built into a system to safeguard it and information contained within

• Integrity controls

– Built into application and database system to safeguard information

• Security controls

– Built into operating system and network

24

Objectives of Integrity Controls

• Ensure that only appropriate and correct business transactions occur

• Ensure that transactions are recorded and processed correctly

• Protect and safeguard assets of the organization – Software

– Hardware

– Information

20/04/2015

13

25

Input Integrity Controls

• Used with all input mechanisms

• Additional level of verification to help reduce input errors

• Common control techniques

– Field combination controls

– Value limit controls

– Completeness controls

– Data validation controls

26

Database Integrity Controls

• Access controls

• Data encryption

• Transaction controls

• Update controls

• Backup and recovery protection

20/04/2015

14

27

Output Integrity Controls

• Ensure output arrives at proper destination and is correct, accurate, complete, and current

• Destination controls - output is channeled to correct people

• Completeness, accuracy, and correctness controls

• Appropriate information present in output

28

Interface Design Guidelines

• Many interface design guidelines have been published to help system developers

– Range from general to very specific rules

• System design standards

– General principles and rules that must be followed for the interface of any system developed by the organization

– Helps to ensure that all user interfaces are usable and all systems developed by the organization have a similar look and feel

20/04/2015

15

29

Visibility and Affordance

• Two key principles to ensure good human-computer interaction (Donald Norman) – Visibility

• A key principle of HCI that states all controls should be visible (so users know its availability) and provide feedback to indicate the control is responding to the user’s actions

• E.g. a button that can be clicked should be visible, and when it is clicked should look like it has been pressed to indicate it is responding

– Affordance • A key principle of HCI that states that the appearance of any

control should suggest its functionality

• e.g. a button affords clicking, a scroll bar affords scrolling, an item in a list affords selecting etc.

• Applies to objects on the desktop

30

Implications for designers

• If designers make all controls visible and clear more likely the interface will be usable

• Most users are now familiar with Windows user interface and common Windows controls

– Not necessarily with Iphone/Android Interfaces

• These principles should also be applied carefully to design of web pages, where there are new types of controls and possible designs of interfaces (not standardized)

20/04/2015

16

31

Eight Golden Rules

• Ben Shneiderman proposes eight underlying principles applicable to most interactive systems (and key to usability)

1. Strive for consistency

2. Enable frequent users to use short cuts

3. Offer informative feedback

4. Design dialogs to yield closure

5. Offer simple error handling

6. Permit easy reversal of actions

7. Support internal locus of control

8. Reduce short-term memory load

32

1. Strive for Consistency

• Information arranged on forms, the names and arrangement of menus, the size and shape of icons etc. should be consistent throughout the system

– This allows for many actions to become automatic

– If a new application comes along with a different way of functioning have to relearn all the basic operations

– Apple Macintosh was the first to emphasize the benefits of consistency

• Mac applications were consistent and a standards document was created for people writing Mac applications (so if you knew one you could figure out other applications easily since they were consistent)

– E.g. consistency in the menu bar for File, Edit and Format

– However some applications may not fit such guidelines and inconsistency may be useful for differentiating applications (for running and learning)

20/04/2015

17

33

2. Enable Frequent Users to Use Short Cuts

• Users who work with one application all the time are willing to invest time to learn short cuts

• They begin to lose patience with long menu sequences when they know exactly what they want to do

• Short-cut keys can reduce the number of interactions for a given task

• Designers can provide macro facilities for users to create their own short cuts

• E.g. mail order entry clerks at RMO wouldn’t want long multiple menus to slow them down, but instead short-cuts would make them more productive

34

3. Offer Informative Feedback

• Every action a user takes should result in some type of feedback from the computer

– Eg. If the user clicks a button it should visually change and perhaps make a sound to indicate it has responded

– Feedback of information to the user is also important • E.g. if a mail-order clerk enters a customer ID number in the

screen, the computer should display the name and address for confirmation by the clerk

• E.g. if the clerk enters a product ID for the order, the system should display a description of the product

20/04/2015

18

35

4. Design Dialogs to Yield Closure

• Each dialog with the system should be organized with a clear sequence (with a beginning and an end) – Reading one’s email

• If the system requirements are defined as events to which the system responds, each event leads to processing of one specific, well-defined activity

• Traditional approach – Each activity is defined by data flow diagrams and

structured English

• Object-oriented approach – Each activity (a use case) might be further defined as

multiple scenarios, each with a flow of events

36

5. Offer Simple Error Handling

• Errors can be costly so designers must try to prevent users from making errors – Better way is by limiting available options and allowing

user to choose from valid options at any point in the dialog

– Adequate feedback also reduces errors

• When errors occur need ways to handle it – Error messages should state specifically what is wrong

and explain how to create it

– Avoid message that scare or blame the user: e.g. “FATAL ERROR 2001”

– Also provide information that makes it easy to correct the error:

e.g. “The date of birth entered is not valid. Check to be sure only numeric characters in appropriate ranges are entered in the date of birth fields…”

20/04/2015

19

37

6. Permit Easy Reversal of Actions

• Users need to feel that they can explore options and take actions that can be canceled or reversed easily

• Allows users to learn about the system by exploring

• If they make a mistake, they can cancel the action

• Should include cancel buttons on all dialog boxes

• Also if user is going to delete something substantial (e.g. a file) the system should ask the user to confirm the action

38

7. Support Internal Locus of Control

• Experienced users want to feel they are in charge of the system and the system responds to them

• They should not be forced to do anything or made to feel the system is controlling them

• Much of this “comfort” and control is provided by the wording of prompts and messages

• Writing out a dialog can help to lead to such a design

20/04/2015

20

39

8. Reduce Short-Term Memory Load

• People have short-term memory limitations

– People remember only about seven chunks of information at a time

– Interface designer cannot assume the user will remember anything from form to form, or dialog box to dialog box

– If user has to stop and ask “Now what was the filename? The customer ID?” then the design is placing a burden on the user’s memory

40

Integrity Controls to Prevent Fraud

• Three conditions are present in fraud cases

– Personal pressure, such as desire to maintain extravagant lifestyle

– Rationalizations, including “I will repay this money” or “I have this coming”

– Opportunity, such as unverified cash receipts

• Control of fraud requires both manual procedures and computer integrity controls

20/04/2015

21

41

Fraud Risks and Prevention Techniques

42

Designing Security Controls • Security controls protect assets of

organization from all threats

– External threats such as hackers, viruses, worms, and message overload attacks

• Security control objectives

– Maintain stable, functioning operating environment for users and application systems (24 x 7)

– Protect information and transactions during transmission outside organization (public carriers)

20/04/2015

22

43

Security for Access to Systems

• Used to control access to any resource managed by operating system or network

• User categories

– Unauthorized user – no authorization to access

– Registered user – authorized to access system

– Privileged user – authorized to administrate system

• Organized so that all resources can be accessed with same unique ID/password combination

44

Users and Access Roles to Computer Systems

20/04/2015

23

45

Managing User Access

• Most common technique is user ID / password

• Authorization – Is user permitted to access?

• Access control list – users with rights to access

• Authentication – Is the user who they claim to be?

• Smart card – computer-readable plastic card with embedded security information

• Biometric devices – keystroke patterns, fingerprinting, retinal scans, voice characteristics

46

Data Security

• Data and files themselves must be secure

• Encryption – primary security method

– Altering data so unauthorized users cannot view

• Decryption

– Altering encrypted data back to its original state

• Symmetric key – same key encrypts and decrypts

• Asymmetric key – different key decrypts

• Public key – public encrypts; private decrypts

20/04/2015

24

47

Symmetric Key Encryption

Systems Analysis and Design in a Changing World, 4th Edition

48

Asymmetric Key Encryption

20/04/2015

25

49

Digital Signatures and Certificates

• Encryption of messages enables secure exchange of information between two entities with appropriate keys

• Digital signature encrypts document with private key to verify document author

• Digital certificate is institution’s name and public key that is encrypted and certified by third party

• Certifying authority

– VeriSign or Equifax

50

Using a Digital Certificate

20/04/2015

26

Disney’s New ‘MyMagic’ Wristbands to Turn Big Data Into Big Profits

http://skift.com/2013/10/06/disneys-new-mymagic-wristbands-to-turn-big-data-into-big-profits/#4

51

52

20/04/2015

27

53

Final Exam

• Chapters 1 to 12 and 14 and 15(5th Edition)

• 20 multiple choices

• 3 or 4 short questions

• OO diagram

– Use Case

– Class

– Sequence