Lecture Outline 11 The Development of Information Systems Chapter 8 page 390+

SYSTEM DEVELOPMENT - sometimes, a system that is needed by a business is not available as a 'canned' system which can be bought and installed - such a system must be custom-built either by systems developers in-house or by external consultants

- we now study how a business information system would be built in-house by the Information Systems Department of an Organization -what kind of system? - recall Library System - recall application components: technical components: organizational components:

System Development Life Cycle: *L -- usually a system is developed in specific SDLC stages: 1. System Investigation: a) Problem Definition b) Feasibility Study 2. System Analysis 3. System Design a) General Design b) Detailed Design 4. System Development (Building) 5. System Implementation 6. System Maintenance -Stages not necessarily linear

A LIFE CYCLE OVERVIEW: System Investigation: - identify problems with the current system and opportunities for improvement - why do we want a new system? e.g. from Library: - do initial feasibility study for the proposed system *L - financial feasibility (is $ available) - technical feasibility (is equipment available) - operational feasibility (will people be able to work with new system)

- if we determine that a new system is feasible, we go on to the next stages System Analysis: *L - analyze the current information system (manual or computerized), in terms of data, processing and information flow, and user input/output - ask where are problems with the current system or what other reasons are there to develop a new system -we get an idea of WHAT will be required of the new system in terms of data, processing, and user interfaces; we document this in detail

System Analysis *MC We now look at analysis in more detail After the preliminary investigation, if the system proposal is found to be feasible, a detailed analysis is carried out –For the current system –For the requirements of the new system

System Analysis (cont’d) A systems analyst can use different ways of gathering the information on system features and requirements *L –Current system documentation –Sampling outputs and input forms from current system –Observation; apprenticing with a user; videotaping people using the system –Administering questionnaires –Interviewing users

Documenting System Requirements *MC What has been discovered through the above techniques needs to be documented adequately Can use English descriptions, but then will need to use structured diagrams Might use traditional diagrams (data flow diagram and program structure chart) OR, may model entire system as a set of interacting objects (OO – object-oriented)

System Design *MC Detailed design for –Database –Programs –Menu, input, output screens, reports –Controls –Hardware & telecomm –Organizational aspects

Two Ways of Diagramming for Analysis and Design *MC 1. The Traditional Structured way –Data and programs designed separately –For data: entity-relationship diagrams (covered) –For programs: Start with data flow diagram in analysis This becomes the program structure chart in design

The Data Flow Diagram DFD Uses only 4 symbols: –square (external entity) –Curved arrow (data flow) –Open ended rectangle (data store) –Circle (process) See handout

Drawing a DFD Narrative: an application form comes in from the applicant. It is screened for completeness. If incomplete, it is sent back to the applicant. If complete, it is compared with the latest job requirements list from the personnel file. If the position on the application is vacant, the application is sent to the personnel department after the applicant’s name is recorded on the potential interview list which is kept in a filing cabinet

DFD for the above narrative See handout for Diagram Be able to describe how a DFD is drawn from a narrative You will not be required to draw one

Program Structure Chart A hierarchical chart with levels Each rectangle is a block of (3GL) program code Block below is called by the block above See handout for structure chart and the code it represents

Another way of analyzing and describing data and programs Object-Oriented Analysis and Design

An Object a structure that has BOTH attributes (variables, properties) and programs (methods) that act on these properties in an object, the attributes and programs are encapsulated

Example: a Customer Object - attributes: customerNo., name, address, phoneNo. creditLimit - programs: acceptCustomer(); assignCreditLimit(yearlyEarnings); deleteCustomer(customerNo)

Object Messages An Object Oriented Information system is built in such a way that object send messages to other objects A message activates thee execution of a specific program that is contained in the object receiving the message

Prescribed diagrams - when developing a new system in the object oriented way, the system development team uses specific diagrams in the Unified Modelling Language (UML): - use case diagrams (how system will be used) - object class diagrams - object interaction (sequence) diagrams From these diagrams we will know how to set up our database and how to write the programs for the new system

Design of other system components The diagrams helped us to design the database and programs for the new system We also have to design: menus, input screens, output screens, reports, system controls, hardware and telecommunication plans, organizational aspects

After system design, *L Programmers code programs that belong to each object class Programs are tested and loaded onto disk Database personnel set up the database on the disk of the server System is implemented Users are trained System is in regular use

Alternatives to Building a System In-house *MC Limited IS Staff IS Staff has limited skill set IS Staff is overworked May take too long