Systems Implementation
- Introduction
- Case Tools
- 4th Generation Tools
- Relational Database Design and Creation
- The Human Computer Interface
- Prototyping
In this chapter we will discuss a number of issues concerned with the implementation of information systems. We will be looking at CASE and 4GL tools and at Relational Database Design, Prototyping and the Human Computer Interface.
Case Tools (Computer Aided Software/Systems Engineering, also known in the literature as CAISE - Computer Aided Information Systems Engineering Tools) have been around for many years and range from basic diagramming packages to systems which take the information systems engineer through the complete process of analysis and design, producing fully documented system models and database creation statements in SQL, some going so far as to produce skeleton code.
At the University of Glamorgan we have the PC/Select package with the SSADM toolkit, over the next week you will complete a PC/Select Open Learning Package, the package covers the basic features of PC/Select, i.e. drawing an LDS, some DFDs and some ELHs and specifying the attributes, primary and foreign keys of the LDS to enable the subsequent creation of a file of SQL Create Table and Create Index Statements.
There are many popular 4th Generation Tools (4GLs) which range from packages like ACCESS and PARADOX, suitable for the development of reasonably simple applications, to multi-featured packages such as ORACLE which is powerful enough to handle enormous distributed mainframe applications.
4GLs typically comprise a Relational Database Management System (RDBMS) surrounded by a number of interfaces, ranging from a simple SQL language interpreter to windows based screen development packages. Many 4GLs also have their own 3rd generation programming languages which can be used to add processing power to the default capabilities of the 4GL. Still other 4GLs allow front ends to be developed using languages such as Visual Basic.
Various 4GLs are available at the University of Glamorgan including PARADOX, ACCESS and ORACLE. PARADOX and ACCESS are typically used for developing stand-alone or end-user applications. ORACLE however is a fully featured 4GE. It has a developers toolkit and a database administrators toolkit.
| Developers Tools ORACLE Objects ORACLE Book ORACLE Forms ORACLE Reports ORACLE Graphics SQL*Plus | Administrators Tools Database Manager Database Expander Object Manager Session Manager User Manager Export/Import SQL*Loader |
Using ORACLE Forms it is easy to create rapid prototypes for applications using default processing capabilities. ORACLE also provides, through its own programming language (PL/SQL), the ability to introduce complex functionality. These features should enable your first rapid prototype to evolve into your finished application.
Relational Database Design and Creation
The first step in the implementation process is the creation or modification of the database in a test environment. In simple relational environments this is usually a straightforward task. Consider a simple LDS in which we have a customer entity type owning many orders and a many to many relationship between orders and parts broken down with an order-line entity type. The following attributes have been identified:-
Customer(Customer_Number, Customer_Surname, Customer_Initials, Address_Line1, District, Postal_Town, County, Postcode, Telephone, Credit_Limit, Outstanding_Balance)
Order(Order_Number, Customer_Number*, Order_Date)
Part(Part_Number, Part_Description, Part_Price, Quantity_In_Stock, Reorder_Level, Reorder_Quantity)
Order_Line(Order_Number*, Part_Number*, Quantity)
Key:- Order_Number Primary Key
Customer_Number * Foreign Key
Here are some rules of thumb for use when converting a documented LDS into an ORACLE database (these need to be upgraded to refer to ORACLE 7):-
- Each entity in the LDS becomes a table in the RDBMS.
- Primary key fields should have the not null attribute specified.
- Foreign key fields where the relationship is mandatory at the member end should also have the not null attribute specified.
- Each table should have a unique index specified for the columns (or concatenation of columns) making up the primary key.
- Each foreign key should have a non-unique index associated with it.
This database could be created in the ORACLE RDBMS as follows (these need to be upgraded to refer to ORACLE 7):-
Create table Customers
(Customer_Number Char(6) primary key,
Customer_Surname Char(30),
Customer_Initials Char(6),
Address_Line1 Char(30),
District Char(30),
Postal_Town Char(30),
County Char(30),
Postcode Char(10),
Telephone Char(20),
Credit_Limit Number(8,2),
Outstanding_Balance Number(8,2));
Create table Orders
(Order_Number Char(6) primary key,
Customer_Number Char(6)
foreign key
references CUSTOMERS(Customer_Number),
Order_Date Date);
Create table Parts
(Part_Number Char(6) primary key,
Part_Description Char(30),
Part_Price Number(8,2),
Quantity_In_Stock Number(5),
Reorder_Level Number(5),
Reorder_Quantity Number(5));
Create table Order_Lines
(Order_Number Char(6)
foreign key
references ORDERS(Order_Number),
Part_Number Char(6)
foreign key
references PARTS(Part_Number),
Quantity Number(4)
primary key (Order_Number, Part_Number));
The Human Computer Interface (HCI) can be a key factor in the success of an application. A HCI designer should be aware of what humans are good at and what computers are good at and take this into account. Humans in general are good at controlling, monitoring, decision making and responding to unexpected events. Computers in general are good at storing and recalling data, processing information using pre-specified procedures and presenting options (e.g. a menu or a pick list). Remember your job is to make the task easier not more difficult! Here are some general principles of HCI design:-
- Allocation of functions; Reduce the amount of memorisation required of commands, codes, syntax, and rules by the user. Reduce the amount of mental manipulation of data required.
- Consistency; Be consistent within and across applications in the use of display formats, colours, key-strokes and on-line help, e.g. don’t use
to move from field to field on one screen and on the next screen. - Expectations; Be aware of what other applications the end-user makes use of, identify their expectations and try to conform to them.
- Ease of Learning/Use; Applications need to be easy to learn, easy to use and provide the required functionality. A balancing act may be necessary. The HCI may have to be designed for novices, intermittent users and experts. This can be very difficult, e.g. the novice and intermittent user would probably be pleased to be led by the nose through a multi-level menu system but this approach would slow up the expert user who knows exactly what they want to do and how to do it.
- Designing Display Formats; The placement, organisation, sequence spacing, typography and labelling used in display formats can have a significant effect on the ease with which users can notice, interpret, remember and use the data presented.
- Effective Wording; Text should be legible, brief, clear and consistent. Don’t abbreviate unless the abbreviation is significantly shorter or is more meaningful to the user, e.g. FORTRAN is clearer than Formula Translation Language.
- Colour; Use colour conservatively. Overuse of colour can hinder rather than help causing particular problems to people with colour blindness.
- Graphics; Sometimes a picture is worth a thousand words. It is usually easier to understand a graphical representation, e.g. a pie chart than a tabular representation of data.
- Dialogue Design; Put the user in control, acknowledge their responses and give feedback. Not knowing whether a computer is responding to your actions or doing work on your behalf can be very exasperating.
- Data Entry; Reduce the amount of data to be input by providing defaults and enabling the user to select data from a list displayed on the screen.
- Help and Error Messages; use context sensitive help and clear helpful error messages.
- Consistency; Information such as screen identifier, screen title, page number, date, error messages and system messages should always appear in the same place. Dates should be consistent throughout the application, e.g. DD-MM-YYYY.
One of the most useful techniques for getting the HCI right is prototyping. The word prototype is defined as ‘an original thing in relation to a copy, imitation, representation, later specimen improved form etc.; a trail model, a preliminary version’ (Concise Oxford). In information systems engineering prototypes are used to both validate and identify user requirements to verify design and to provide a base line for the eventual development of the system. The idea is that a working model is much easier to understand, from the end-users point of view, than a set of diagrams and supporting documentation.
Some people have viewed prototyping as an alternative to analysis and design, this is not the case, the prototyping life cycle if carried out without conducting thorough analysis and design, is likely to be endless.
The prototyping lifecycle proceeds through six main phases:-
- Scope; In this phase the boundaries of the system in question are identified.
- Requirements Analysis; During this phase the requirements of the system are identified (this phase is roughly equivalent to the SSADM Requirements Analysis and Requirements Specification modules).
- Design; This covers the Logical Design of the system in question (this phase is roughly equivalent to the SSADM Logical System Specification stage)
- Prototype; During this phase a working model of the system is created by the developers using appropriate 4th generation tools (prototyping for information systems cannot really work effectively unless these tools are available).
- Demonstrate; During this phase the prototype is presented to the end-user for comment. The demonstration can result in, new or changed requirements, which would necessitate backtracking to the requirements analysis phase, holes being discovered in the analysis and design which would necessitate backtracking to the design phase, and purely cosmetic changes concerning the HCI, which would necessitate backtracking to the prototype phase.
- Deliver; A number of approaches can be taken to delivery, e.g. the big bang approach in which the whole application is delivered, or the incremental approach whereby parts of the application are delivered as they roll off the prototyping production line.
See slide 10
The literature commonly identifies 4 kinds of prototype:-
- Cosmetic Prototypes; These are non-functional mock-ups of systems or parts of systems which have the appearance that the designer expects the final system to have.
- Research Prototypes; Research prototyping occurs when there are specific and firm non-functional (i.e. regarding performance or security) requirements which the designers wish to prove.
- Throwaway Prototypes; These are prototypes which are built solely with the aim of validating requirements, they are put through verification and then discarded.
- Functional/Evolutionary Prototypes; Functional prototyping refers is an approach involving designing the system, producing a first working prototype, verifying the systems ability to support user requirements and refining this prototype into the finished system. Functional Prototyping depends to a large extent on whether the tools used in the development environment, e.g. a PC can be ported to the implementation environment, e.g. an ICL mainframe.
Prototyping ‘v’ SSADM’
As may be seen there are some inconsistencies in the approaches adopted under a prototyping scheme and the SSADM scheme. When using prototyping analysis and design are carried out in a less rigorous and comprehensive manner than when using SSADM. When using SSADM the assumption appears to be that the analyst will get it right first time, prototyping has a minor role in SSADM.
There is no right approach which suits all projects. It may be better to use a functional prototyping approach for relatively simple end-user applications, but a complex fundamental business system like payroll or customer billing probably needs the rigour of SSADM. Alternatively a hybrid approach could be adopted, integrating a prototyping approach to implementation, with SSADM.
Tutorial Sheet Prototyping
Objectives
To evaluate the strengths and weaknesses of the prototyping method.
Question 1
Why would an end user find it easier to criticise a prototype than a DFD?
Question 2
In what kinds of situations would you adopt the different prototyping methods and what approach are you adopting in your project.?
Question 3
Why is prototyping ineffective when using 3rd generation languages such as COBOL?
No comments:
Post a Comment