Information Systems Analysis and Design

MSC228

Trimester 1 / 2012 Topic 1

1

The first bit of business info

The University wishes to make you aware of the Emergency Evacuation Procedures that are in place for your safety. Please look around and familiarize yourself with the exits in this room and for each new venue in which you attend classes. You should also familiarise yourself with the building's emergency exits and assembly areas which can be found on Fire Emergency Floor Plans placed in the hallway of all buildings. In the unlikely event of an evacuation, you will hear a continuous loud beeping tone. On this alert signal you should prepare yourself to evacuate the building, If you hear a continuous two tone siren sound please evacuate in an orderly fashion to the assembly areas. All building occupants must evacuate on this evacuation signal, Remember not to use lifts during evacuation. Please follow the instructions given by Emergency Wardens, Security staff or Emergency Services personnel. At the end of the evacuation, you will be advised when it is safe to return to the building. 2

Welcome!
Unit Chair Burwood Campus and Off-Campus Co-Lecturing and Teaching Ms Merete Crofts
mrcrofts@deakin.edu.au

Your MSC228 teaching staff:

Dr. David Wilde Burwood Campus Co-Lecturing and Teaching

william.wilde@deakin.edu.au

Mr Graham Bignall Geelong Campus

graham.bignell@deakin.edu.au 3

Learning materials
Prescribed textbook Dennis, A., Wixom, B.H. & Roth, R. 2009 Systems Analysis and Design, 4th edn, John Wiley & Sons Inc $129.95 Other materials 2012 Study Guide $13 and DSO On DSO 2012 Lecture notes and tutorials 2012 Assignment details Readings as advised
4

Learning materials
Additional resources
There are many other good books that are available in the library, eg:

Avison, D. E and Guy Fitzgerald, 2003, Information systems development: methodologies, techniques, and tools, London : McGraw-Hill, 3rd ed Brown, David, 2002, Introduction to Object-Oriented Analysis: Objects and UML in Plain English, 2nd Edition, John Wiley Hoffer, J.A., George J.F. & Valacich J.S. 2002, Modern Systems Analysis and Design 3rd edn Prentice Hall, Upper Saddle River, NJ. Kendall, K. E. & Kendall, J. E. 2004, Systems Analysis and Design, 6th edn, Prentice Hall, Englewood Cliffs, NJ. Satzinger J.W., Jackson R.B. & Burd S.D. 2004, Systems Analysis and Design in a Changing World, 3rd edn, Course Technology

Structure
Lecture (2 hour session pw)
Look at the way in which information systems are planned, analysed, designed and implemented.

Tutorial (1 hour session pw)

Examine and discuss analysis and design issues.

Deakin Studies Online (DSO)

Online delivery of most of the learning materials (except the textbook/software) Most of the communication for this unit is carried out via DSO
6

Class Times and Locations

On campus students Burwood Lecture: Tutorials: Geelong Lecture: Tutorials: Tuesdays 15 17 LT3 Mondays 10 and 11; Tuesdays 12 Thursdays 15 17 LT ka5.332 Thursdays 12 and 14
7

DSO (D2L)
Logging in to DSO
Browser;
Use Microsoft Internet Explorer 5.0 or higher Mozilla

http://www.deakin.edu.au/current-students/index.php
Remember to log out when you are finished
8

Assessment
Assignment 1 Assignment 2 Exam Getting help DSO discussions, Tutorials, Your lecturer
9

Individual Individual

15% 35% 50%

Due 2/4/2012 Due 21/5/2012 Hurdle

What to avoid
Plagiarism is the copying of another persons ideas or expressions without appropriate acknowledgment and presenting these ideas or forms of expression as your own. It includes not only written works such as books or journals but data or images that may be presented in tables, diagrams, designs, plans, photographs, film, music, formulae, web sites and computer programs. Plagiarism also includes the use of the work of lecturers or other students as your own without acknowledgment. At Deakin, there are heavy penalties for plagiarism, so ensure that your work is original. Also make sure that your own work is not plagiarised by others!
10

10

Unit Plan
1. Introduction to Systems Analysis and Design 2. Project Initiation and Feasibility Analysis 3. Requirements Gathering 4. Techniques: OO1 Use Case 5. Techniques: OO2 Structural/Behavioural 6. Techniques: Structured 1 7. Techniques: Structured 2 8. Techniques: Other 9. Moving to design 10. Human Computer Interaction 11. Revision

11

11

Systems Analysis and Design MSC228

Topic 1
12

Introduction
(Professor) Peter Juliff
Commercial computer systems designed & developed for:
British Petroleum, Trade Union Clinic, NCR, W.A Deutscher, Deakin University, ASEA, Parks Australia, Thorn Industries, Goulburn Valley Canneries, Health Computing Services, Victoria Institute of Colleges, Victorian Railways, Local Authorities Superannuation Board, Outer Eastern Municipalities Association

Programmed in languages from Burroughs and ICL assemblers through COBOL to

Visual Basic

Implemented on Burroughs, Honeywell, ICL and DEC mainframes and Windowsbased PC systems.
13

What am I doing here ?

1. To put the current practice of systems analysis and design into some perspective 2. To draw attention to the problems encountered in implementing computer-based systems 3. To inject a little been there and done that into the exercise . . . and why is any of this important anyway?
14

Over a period of 40 years . . . .

What has changed? Hardware technology Data organisation & access Move from batch to online processing of data The importance of human / computer interaction The emergence of rapid development methodologies through the prototyping capacity of software The expectations of users !!!!! What hasnt changed? The difficulty of defining system requirements The conflict between basing design on data vs procedure The (unrealistic) expectation that users know what they want The necessity for someone to inject imagination into the design The need to have users take ownership of the system

15

Overview
Systems Information Systems Systems Development Life Cycle Methodologies The Project Team
16

Job description of current Business/System Analyst

XXXXXX

We will re-visit this later in the lecture.

17

Systems

18

Systems
Natural
physical e.g. stellar, geological. living e.g. animal, plant.

Man-made Examples please?!

social
Facebook, dance classes

transportation
Tram, train, bus, air etc.

communication
Telephone, internet

information etc.
19

Systems
A system is: an interrelated set of components that are viewed as a whole.
(Teague & Pidgeon,1985)

Each system has a purpose (or goal) and must work towards that purpose.

Example Transportation system goal?

Many and varied depending on perspective, e.g. Making money A way to get around Political
20

Systems
Systems achieve their purpose by accepting inputs, and producing outputs, via an organised transformation process. To solve business problems it is essential to identify the organisation's goals. But how do we measure goals?

21

. . . and speaking of goals . . . .

Systems have many goals, many definitions of a user and many conflicting requirements : e.g. Banks Universities Customers Students Staff Administration staff Shareholders Academic staff Govt regulators Govt regulators

In each of these examples, the requirements of one set of users may be diametrically opposed to those of another set. . . . so - who do you consult to determine the system requirements? - who are you working for? (Live system vs Unit assignment !!!) - who are you trying to satisfy?

22

Systems
System Models produce a simple description of the area under study. To develop the model we use abstraction and selectivity. Models are used because it is impossible or impractical to deal with the system directly. Graphical models strongly aid the imaging or visualisation of a system

23

Information Systems

24

Information
Data vs. Information Data is represented as discrete entities e.g. a customers name, details on an invoice, the date on a receipt Information is data transformed into something of meaning e.g. sales of a product over a week or a month; a list of people who owe us money. It is used to assist people in making informed decisions.
25

Examples of Information Systems

Abacus Ledger books (or scrolls) Counting Boards EDP systems (batch systems) MIS (shared databases - online systems) DSS (decision support systems) EIS (executive information systems)
26

Information Systems
A collection of components that work together to provide information to help in the operations and management of an organization. Nickerson (2001, p4)

Its purpose is to get good information to the right people at the time when they need it the right time.
27

New Information Systems

Information systems projects are usually triggered by
Problems
Payroll system not working effectively

Opportunities
Selling products online

Directives
New tax laws
28

Systems Development Life Cycle (SDLC)

29

Systems Development Life Cycle

1. Planning
Why build the system?

2. Analysis
Who, what, when, where will the system be?

3. Design
How will the system work?

4. Implementation
System delivery

Most systems analysis methodologies follow the basic steps of the SDLC
30

10

1. Planning
Identifying business value Analyze feasibility Develop work plan Staff the project Control and direct project
31

Identifying business value

Does this mean a Cost/Benefit Analysis?
Thoughts on CBAs : Tom De Marco (1970s) - theyre useless Steve Jobs (40 years later) - theyre useless Many of both the costs and benefits of any system are impossible to quantify in $$$ terms Those able to be quantified will turn out to be wrong or will be fudged to justify the project
( not just choosing among providers )

. . . think of a cost/benefit analysis of owning a telephone . . . and of not owning a telephone

(do you really have a choice?)

32

Control and direct project

The necessity for milestones to be built into the plan. e.g. - Building a house - half the money is spent, have they built half the house? - Driving to Sydney - half the time has elapsed, have we gone half the distance? Without these, the project is doomed from the outset . . . and what might they be? The control variables are time, money and functionality Who monitors the project? The myth of user sign-off before proceeding to the next stage The Mythical Man-month (Fred Brooks)
33

11

2. Analysis
Analysis Information gathering Models created

34

Information gathering
From whom? . . . If youre relying on the current users, think again - they arent aware of what may be possible - they arent even completely aware of the current system What to gather? . . . What will be carried into the new system? - the data? Surely, but + or the status quo? - the procedures? Can we not improve/eliminate these? Who provides the imagination?
35

Models created
What to model?
Current system
Data - useful if its to be carried forward Procedures - useless unless theyre to be carried forward What is the point of being an expert on a system about to be junked? Immersion in the current system is likely to ensure its replication

New system
Start from scratch when developing procedures Is there a way to produce the result by a different means than is currently used? Can more information be produced from the data than is currently feasible?

. . . let me give you an example

36

12

3. Design
Physical design Architectural design Interface design Database and file design Program design
37

4. Implementation
Construction Installation Maintenance

38

Processes and Deliverables

Process Planning Analysis Design Implementation Product Project Plan System Proposal System Specification New System and Maintenance Plan
39

13

Methodologies

40

Methodologies
A formalized approach or series of steps Aim is to provide a guide which if followed will lead to a successful information system Building a house without a plan is unlikely to get you your dream house Writing code without a well-thought-out system request may work for small programs, but rarely works for large ones.
41

The Need for a Methodology

Specific detailed ways of creating systems, that have been at least partially tested and documented, are termed

METHODOLOGIES

42

14

The Need for a Methodology

With the growth of the use of computers during the 1950s and 1960s it was recognised that:
The role of the systems analyst was important There was a need for integrated IS development To facilitate IS development a detailed IS development methodology was desirable
The Nike methodology - Just Do It The IBM methodology we have the solution already, just amend your problem to fit it.

43

What is a Methodology?
A collection of procedures, techniques, tools and documentation aids which will help the systems developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of subphases, which will guide the systems developer in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate information system projects
Avison and Fitzgerald (2003)
44

What is a Methodology?
Procedure A set of activities to be carried out to achieve a desired outcome Technique A way of doing a particular activity in the information systems development process Tool An aid, often computer-based, that enables some of the procedures or certain techniques to be carried out automatically or semi-automatically Documentation Aid Particular notations or ways of presenting data that capture aspects of the system to be implemented that are deemed important Phase/Sub-Phase A logical grouping/sub-grouping of procedures carried out at a particular stage of the system development
45

15

What is a Methodology?
The Philosophical View
Avison and Fitzgerald argue also that a methodology should be based upon a particular philosophical view This distinguishes a methodology from a method (a recipe) It shapes what is emphasized, and assumptions made Examples of a Philosophical View:
People are important One should take a Scientific approach One should aim to automate the development work

46

Methodologies
What is relevant is that the requirements of a batch mode payroll system, or an information retrieval system, or an on-line auction system are dramatically different the wants, needs, views and levels of knowledge and skills of the many people and organizations touched by IS are radically different It would be surprising if a single methodology used to develop systems for all of these scopes and contexts was equally successful.
47

Methodologies
Structured Design Rapid Application Design Object-oriented analysis and design . many others including: SSM and Multiview
48

16

. . . Hold it right there !!!

What are the methodologies producing?
Documentation vs Information Documentation without information is a waste of everybodys time

Information for whom?

The users? - can they understand it? The developers? - will they use it? The maintenance techos?
- will it explain what was done, and why?

Can it drive the database definition and/or the software?

49

Structured Design
Projects move methodically from one step to the next step Generally, a step (or phase) is finished before the next one begins Uses modelling tools to show business processes and business data
50

Waterfall Development Method

With waterfall development- based methodologies, the analysts and users proceed sequentially from one phase to the next.
Fig 1-2, p8, Dennis et al
51

17

Structured Design
Benefits Structure provides a good aid to developers to improve chances of success Usually have to complete one stage before moving on Diagramming relatively easy to understand, i.e. not programming based The system requirements are identified long before programming begins. Drawbacks Hard to go backwards in process Less creativity Can be time consuming
52

Rapid Application Development (RAD)

RAD-based methodologies adjust the SDLC phases to get some part of system developed quickly and into the hands of the users. Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, such as CASE (computer-aided software engineering) tools. Phased (series of versions) or prototyping (all stages performed concurrently)
Effective to create systems quickly e.g. web based systems Changes can be made easily Criticized for lacking methodological rigor Possibly the greatest single contribution made by the evolution of modern software
53

Comments

How Prototyping Works

Fig 1-4, p11, Dennis et al

54

18

Object-Oriented Analysis and Design

Attempts to balance the emphasis on data and process by combining both (data and procedures) in models Interaction occurs via messages (that pass information) between the objects A standard modelling technique is the Unified Modeling Language (UML)

..designed to help the participants in software development efforts build models that will enable the team to: - visualize the system, - specify the structure and behaviour of that system, - construct the system, and - document the decisions along the way.
(Scott 2001, p1)
55

Object-Oriented Analysis and Design

Use-case driven
Captures the main functionality of the system from a users perspective

Architecture Centric
3 different views (functional, static, dynamic)

Iterative and Incremental

processes are repeated and gradually refined

This we will revisit in weeks 4 and 5.

56

Benefits
Objects can be designed independently giving designers more flexibility in design Systems can be more flexible More rapid and less expensive system development Another way of improving productivity is through libraries of reusable objects
57

19

Process Modelling DFDs

Context diagram for a fast food ordering system

58

SSM Rich picture Model

59

Use Case Diagram

60

20

The Project Team

61

Project Team
System Analysts System Designers Project Manager Programmers Technical writers

Other stakeholders; System owners, System users, IT vendors and consultants

62

Systems Analyst
The systems analyst is a key person analyzing the business, identifying opportunities for improvement, and designing information systems to implement these ideas. It is important to understand and develop through practice the skills needed to successfully design and implement new information systems.
63

21

Job description of current Business/System Analyst

XXXXXX

64

Systems Analyst

Whitten et al, 2000, Fig 1.4

65

Skills Required by Systems Analysts

Interpersonal communication/relations skills Character and ethics Flexibility and adaptability Systems analysis and design skills Working knowledge of information technology General business knowledge Problem-solving skills
66

22

Summary

67

Summary
Systems theory and how it relates to Information systems Information Systems project triggers Goal of System Development

68

Summary
The Systems Development Lifecycle:
1. 2. 3. 4. Planning Analysis Design Implementation

Major development methodologies:

Structured design RAD Object-Oriented approach

Major development team roles, responsibilities and skill requirements

69

23

What to do now

70

What to do now
Log into DSO, read the Welcome message and explore the environment Download a copy of the Assignment Purchase the text book

71

Reading - Further Study

To complement this introduction to Topic 1 students should read Topic 1 in the Study Guide, and the sections of the text referred to in that study guide. Prepare for next weeks tutorial - download the Tutorial Questions and make sure you have read the material in preparation for next weeks classes. Test your own understanding of Topic 1 by completing the Review Questions as listed in the study guide
72

24