1. The Development of Information Systems Chapter 8 page 348+
Lecture Outline 11
The Development of Information Systems
Chapter 8 page 348+

2. 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

3. - recall Library System - recall application components:
- 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:

4. 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

5. A LIFE CYCLE OVERVIEW:
System Investigation:
<should we really develop a new system?>
- 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)

6. - 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

7. 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

8. 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

9. 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)

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

12. 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

13. 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

14. 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

15. 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

16. 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

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

18. 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

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

20. 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

21. 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

22. 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

23. 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

26. Reasons for Not Building a System In-house *MC
Limited IS Staff
IS Staff has limited skill set
IS Staff is overworked
May take too long