|
|
|
|
System Design
System design can be explained and presented in narrative form.
But the benefits of diagrammatic view
cannot be understated. This helps to give a snapshot of what the
entire system looks like. Various
diagrammatic tools can be used while designing the system.
As an example consider the following DFD which indicates a
simple process of recording transactions and
posting into general ledger
79
User/Accountant uses chart of accounts to access the relevant
accounts in order to prepare different
vouchers according to requirements. The purpose behind this
entire activity is to record various
transactions. The next step is posting of all these transactions
in the system. This process updates the
general ledger.
19.1 Entity Relationship Diagram (ERD)
Another diagrammatical tool used in system design is ERD. ERD as
shown below indicates simple
relationships. These relationships can be read as follows.
•
One department has one
supervisor
•
A department may have
more than one employees
Or
•
An employee may be in
more than one departments
•
An employee may not be
working on any project but a project must have at least one employee working
on it
This is another form of ERD used to show the relations between
various fields in files used to record
specific data.
80
Room ID
Manager
Building
Room
Description
Status
User
User ID
First
Last
Login
Password
Type
Initials
Status
The above figure shows a hotel booking system. Various records
have been kept for each entity.
However each entity shares a relationship with for logical
purpose. For instance, the field for room ID
has been kept in reservation for access to further data. User
information has been kept separate,
however link has been made to reservation, session and logs by
making user ID common to all three
tables. Such kind of relationship helps in keeping
Reservation
Reservation ID
Room ID
User ID
Date
Start time
End time
Note
Status
Session
Session ID
User ID
Session String
Time Stamp
Log
Log ID
User ID
Time Stamp
In/out
1
1
81
19.2 Design of the information flow
It is a major step in the conceptual design. Following aspects
should be covered
•
Flow of data &
information and transformation points
•
The frequency and timing
of flows
•
The extent of formality
in these flows – input forms, report formats.
19.3 Design of data base
It involves determining scope and structure:
•
Scope – Whether the
database is local or global. If interdependence of organizational units is
high, the data base has to be global in order to prevent
sub-optimization of sub units. As it
becomes global, the cost of maintenance enhances.
•
Structure – refers to
the ways data is stored in partitions and sequences. Various design
methodologies can be used for devising a suitable structure in
accordance with the needs of the
organization and the new system.
19.4 Design of the User Interface
This phase involves determining the ways the information system
will interact with the users. Some
elements are
•
Source Documents to
capture raw data
•
Hard-copy output reports
•
Screen layouts
•
Inquiry screens
•
Interrogation languages
for the data base
•
Graphics and colour
displays
•
Voice output to guide
users or answer queries
•
Screen layouts for
manipulation by a light pen or mouse
•
Icons for pictorial
representations
The design process begins with stratifying system users and then
identifying their needs. e.g.
•
New users dealing with
system infrequently,
•
Experts dealing
regularly
19.5 Physical Design
The logical design is converted to physical design in this
phase. The physical design involves breaking
up the logical design into units, which in turn can be
decomposed further into implementation units
such as programs and modules.
Design of the Hardware/ Software Platform
New system requires new software and hardware not currently
available in the organization.
For example
82
•
User workstations might
have to be purchased to support an office automation system.
•
A minicomputer might
have to be purchased to provide extra processing resources to the new
system.
19.6 Program Development
The development phase involves converting design specifications
into executable programs. Once the
analysis and design is complete, the software is either
developed according to the needs or most suitable is
purchased. Similarly the specifications of the hardware are seen
and acquisition is made according to the
situation. Primary procedural programming activities include
•
The creation and testing
of source code
•
The refinement and
finalization of test plans
•
Writing and reviewing
program modules or components
•
Integration of Completed
components with other components to ensure the components properly
interact. The process continues as component groups are
progressively integrated and as interfaces
between component groups and other systems are tested.
19.7 Procedures Development
In this phase, following documents are prepared.
•
Technical manual – This
is meant for the Data Base Management and highlights the system
infrastructure, inputs-outputs of the system and flows of system
processes. Documents include
•
DFD’s (Data Flow
Diagrams)
•
ERD’s (Entity
Relationship Diagram)
•
Use cases, test cases
•
User manual
It defines the operations of the system in layman’s terms i.e.
•
Getting started with the
software
•
Operating the software
•
These manuals are
generally function related.
19.8 Testing
The purpose of this phase is to identify as far as possible any
errors and deficiencies in the system prior to
its final release into production use. For instance errors in
•
User interface
•
Procedure manuals
•
Job design
•
Organizational structure
design
In reality all system features cannot be checked at the outset.
For instance, users might realize that the
system has inadequate procedures manual only after the system
has been properly implemented.
Change Over
This phase comprises of those activities undertaken to replace
the new system in operation from the
83
existing system. Following ways of change over can be undertaken
•
Abrupt change over –
stop the existing system abruptly to shift over to new one
•
Phased change over –
Both are run but output of both the systems is used since functions
performed are different.
•
Parallel change over –
Both systems are run simultaneously for a period of time and output of
either of the systems is used. Functions performed by both are
same.
19.9 Operations & Maintenance
The new system is run as a production system and is periodically
modified to adjust for better functioning.
Following can be various forms of errors.
•
Removal of coding/logic
errors – Logic errors discovered in the system are corrected.
•
Modifications / system
rewrite – Changes in the system environment may necessitate system
modifications.
•
Perfective maintenance –
Changes might be made to improve processing efficiency.
19.10 Evaluating Waterfall
Arguments for water fall
•
Waterfall model places
emphasis on documentation (such as requirements documents and design
documents) as well as source code.
•
Other methodologies
which save time in software development can de-emphasize documentation. In
such methodologies project knowledge is stored mentally by team
members. Should team members
leave, this knowledge is lost, and substantial loss of project
knowledge may be difficult for a project to
recover from. Extreme Programming is an example which will be
discussed later.
•
Waterfall model is
preferred for its simple and arguably more disciplined approach. The model
itself
progresses linearly through discrete, easily understandable and
explainable "phases" and is thus easy to
understand
•
It also provides easily
mark able "milestones" in the development process. It is perhaps for this reason
that the waterfall model is used as a beginning example of a
development model in many software
engineering texts and courses.
Arguments against water fall
•
It is argued that it is
impossible to get one phase of a software product's lifecycle "perfected" before
moving on to the next phases and learning from them.
For example clients may not be aware of exactly what
requirements they want before they see a working
prototype and can comment upon it - they may change their
requirements constantly, and program
designers. This is an example of iterative model (to be
discussed later)
•
Waterfall model
advocates more reliance on fixed, static requirements. Designers may not be
fully
aware of future implementation difficulties when writing a
design for an unimplemented software
product. That is, it may become clear in the implementation
phase that a particular area of program
functionality is extraordinarily difficult to implement.
•
Another problem is that
the waterfall model assumes that the only role for users is in specifying
requirements, and that all requirements can be specified in
advance. Unfortunately, requirements grow
84
and change throughout the process and beyond, calling for
considerable feedback and iterative
consultation. Thus many other SDLC models have been developed.
The choice of phases differs in
various standards and organizations. |
|
|
|
|
|
|