GROUP:-4

• Evaluation of alternative solutions to a business design.

• Specification of hardware, software and communication technology for the selected solution.

• Purpose : Devise means to meet all the business requirements detailed in the requirements report.

• LOGICAL DESIGN• PHYSICAL DESIGN• CONSTRUCTION • TESTING

LOGICAL DESIGN

PHYSICAL DESIGN

CONSTRUCTION SYSTEM TESTING

• Translation of the user requirements into detailed functions of the system.

• This is often conducted via modelling, which involves a simplistic representation of an actual system.

• Pertains to an abstract representation of the data flows, inputs and outputs of the system.

• INPUT FILES: The files used to capture the input data.

• PROCEDURES: The logical algorithms used to process the input. The procedures are later transformed into code written in a programming language.

• OUTPUT FILES: The files that will be used to capture information that is the result of processing data. The files in which input of customers, employees, suppliers, job applicants or other parties are recorded.

• USER DIALOG: The manner in which the user will interact with the system.

• INTERFACE: How the system will interact with other systems.

• Interface decisions include-

* Provisions for input of data and the information from the files of other systems.

* Lookups in the other system for decision making.* Retrieval of data from other systems.* Output of data to other systems.

• Flowcharts use graphical symbols to illustrate a systems logical operations as well as physical parts involved.

• There are symbols that represent pieces of hardware, such as terminals, disks, communication lines and also logical operations such as beginning and ending points of a process and points of decision making.

• For over 50 years, systems analysts and programmers have used flowchart as a language.

• It is an independent means of describing a systems logical sequence.• After detailing the logic of a process in a flowchart, programmers

translate the logic into a computer program.

• There are different symbols to represent – events, process, hardware device etc.

• Some of them are standardized by ANSI, others remain non standardized.

• The multitude of symbols, use of non standard symbols, the use of too many things in the same chart have rendered flow charting less and less popular in recent years.

• A simpler alternative to graphically represent information systems have been developed- Data flow diagrams (DFDs).

System design can be achieved with

the help of tools and techniques.

Several tools exist --- to design a

system + graphically and pictorially

represent the system

We discuss 2 such tools:

(a) DFD

(b) Data Dictionary

Data Flow Diagrams

Data Flow Diagrams

A graphical tool

Uses

Communicating

Structured Analysis Logical Requirement

Analysis Existing & Proposed System

Focus

Simple Technique

Provides an overview

Describe flow

DFD’S describe the flow of data in a business

operation.

DFD elements (Uses only 4 symbols) :

1.External entities (Source/Sinks)

2.Processes

3.Data stores

4.Direction in which the data flows

External Entities

A Rectangle represents an external entity

They either supply or receive data

They do not process data

Includes individuals and groups of people that are

external to the system

Ex: customers, employees , other departments in the

organization, or other organizations

Source – Entity that supplies data to the system.

Sink – Entity that receives data from the system.

ExternalEntities

Processes

1. STORES

Stores demand note

Delivery Slip

Issue Slip

Ex: Processing of data into informationApplication of data to decision making

Any events / sequence

of events --- in which

data are either

changed /acted on

• A circle represents a process

• Straight line with incoming arrows are input data flows

• Straight lines with outgoing arrows are output data flows

• Labels are assigned to Data flow. These aid documentation

Data Stores

• Data can be written into the data store. This is depicted by

an incoming arrow

• Data can be read from a data store. This is depicted by an

outgoing arrow

• External entity cannot read or write to the data store

• Two data stores cannot be connected by a data flow

Data StoresD1 Data StoresD1 Data StoresD1

Writing Reading

Any form of data at rest, it is a repository of data (storage)

Ex: database

Data Flows

• Data in motion

• Marks movement of data through the system - a pipeline

to carry data.

• Connects the processes, external entities and data stores.

• Generally unidirectional, If same data flows in both

directions, double-headed arrow can be used.

Data Flow

Rules of Data Flow• Data can flow from

External entity to process

Process to external entity

Process to store and back

Process to process

• Data cannot flow from

External entity to store

Store to external entity

Store to store

External entity to external entity

Note :

DFD’s represent only entities, processes,

data stores and data flows– nothing else.

They cannot represent hardware devices or

types of reports nor are they meant to detail

the logic of processes

Adv.: use of only 4 symbols + simplicity

Data flow diagram of a sales bonus system

The process of calculating sales bonus

Sales clerk : entity entering data (salesperson’s

I.D.)

It flow into a process - Bonus calculation---

receives data from salespeople database(data

store)

The result of the process--- Bonus amount for each

salesperson --- information ---flows into a bonus file

Later – company’s controller will use the

information to generate bonus checks

DFD FOR A BOOK BORROWING SYSTEM

DFD’s are used both in analysis and designphases of system development.

In analysis phase – DFD’s – Describe + illustrate------ How existing system operates

They are suitable for describing any IS even if it is notcomputer based.

Pinpoint weaknesses, which process and databasescan be automated etc..

Provide a logical blueprint for construction of a newsystem

Logical and Physical DFD• DFDs considered so far are called logical DFDs

• A physical DFD is similar to a document flow diagram

• It specifies who does the operations specified by the

logical DFD

• Physical DFD may depict physical movements of the

goods

• Physical DFDs can be drawn during fact gathering

phase of a life cycle

DATA DICTIONARY

It is the complete and comprehensive definition of the entire

data elements in the system.

It is the source document for the specification for all inputs ,

protocol ,outputs ,data structures ,database structures ,its

metadata and algorithms.

It is a data repository of all design data about the system.

Several description formats are available.

• One such format requires that for each item the following

information be stored in DD.: Name, Alias ,Use

,Description ,Additional information

• DD’s come to rescue when system breaks down for some

reason.

• It normally serves the following purpose:

1. A summary of the documentation

2. A tool to reduce reduntancy of data

3. A background for I/O design

4. As a centralized control of all data in a system

5. As a controller of data integrity

PHYSICAL DESIGN

• Graphical representation of a system showing the internal and external entities and the flow of data into and out of these.

• It begins once the logical blueprint for the new system is ready.

• A systems physical design process includes specifying the h/w and s/w needed to support it.

• It relates to the actual input and output processes of the system.

• The 3 sub-tasks in physical design

1. User interface design

2. Data design

3. Process design

• Physical design specifies where, how and by whom a system’s processes are accomplished and does not tell us what is being accomplished.

Prototyping process

• The major disadvantage of physical design is that it is a time-consuming process that is prone to considerable errors and omission.

• To overcome this limitation many analysts and designers prefer prototyping, a modern engineering based approach to design.

• Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback.

THE PROTOTYPING PROCESS

Contd..

1. Identify basic requirements

•Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.

2. Develop Initial Prototype

•The initial prototype is developed that includes only user interfaces.

3. Review

•The customers, including end-users, examine the prototype and provide feedback on additions or changes.

4. Revise and Enhance the Prototype

•Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary.

ADVANTAGES

• Reduces development time.

• Reduces development costs.

• Requires user involvement.

• Developers receive quantifiable user feedback.

• Results in higher user satisfaction.

• Exposes developers to potential future system enhancements.

• Missing functionality can be identified easily.

• Encourages innovation and flexible designs.

DISADVANTAGES

• Too much involvement of client, is not always preferred by the developer.

• Too many changes can disturb the rhythm of the development team.

• Long term maintenance can be expensive.

• Information can be lost through so many improvement changes.

CONSTRUCTION

• Construction begins once software developmental

tools are chosen.

• Professional programmers translate input, output and processes as described in flowcharts and data flow diagrams into programs.

• When program module is completed it is tested.

• When all the modules are completed and tested, the modules are integrated into one coherent program.

SYSTEM TESTING

• In system testing the entire integrated system is tested.

•The system is checked against the system requirements originally defined in the analysis phase by running typical data through the system.

•The quality of output is examined and processing times are measured to ensure that the original requirements are met.

•Testing should include attempts to get the system to fail.

• It is done so that many unforeseen snags can be discovered and fixed before the system is introduced.

• If new system passes the tests, it is ready for introduction in the business units that will use it.