CHAPTER 5

THE PROCESS AND STAGES OF SYSTEM DESIGN

Company

LOGO

Chapter 5 : Lesson Objectives

1. 2. 3. 4.

What is system design? Why do we need system design ? Design evaluation criteria Stages of system design o Logical design - DFD o Physical design 5. Design methodologies & their advantages o Top-down vs. Bottom-up design o Structured design Functional decomposition Structured walkthrough Major development activities during structured design
o o

o
o

Database design Program design System and program test preparation System interface specification

1.What is System Design?

There are two ways of constructing a software design(Tony Hoare):

One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

System design is a solution , a how to approach to the creation of new system based on the requirements of the user . System design requires a deep thinking about the right way to decompose a complex system into smaller modules that can be individually coded and re-combined to bring back the required system. It is the important stage of system development that provides the understanding and procedural details necessary for implementing the system specified in the feasibility study.

1.What is System Design?(Continued)

Design activity of a system is a highly creative activity that involves the translation of a user-oriented document into a programmer-oriented document . It concentrates mainly on the solution domain rather than the user requirement domain.

Perhaps the most critical activity during system development

Design is done before the system is implemented Design is the intermediate language between requirements and code Proceeding from abstract to more concrete representations Result is the design that will be used for implementing the system

2.Why do we need system design ?

To have an understanding about the over all picture of what the new system should look like. This is very useful in making the conceptual layout of the new system. To create an adequate plan to satisfy user requirements before implementation is started . To divide a large complex system into smaller interacting modules .And if necessary to divide these smaller interacting modules into sub modules. To identify the number of necessary modules of a the new system to be developed and to plan how a large system should be divided into smaller modules. To have an efficient system and to minimize testing and maintenance efforts.

3.Design Evaluation Criteria

Goal is to find the best possible design Have to explore different designs Evaluation criteria are often subjective and non quantifiable Major criteria to evaluate a design Correctness Does the design implement system requirements properly? Is design feasible, given the constraints?

Efficiency Concerned with the proper use of scarce resources - processor & memory If other factors are same, efficiency should be maximized Maintainability Most affected by architectural design Should facilitate testing Should facilitate discovery and correction of bugs Make modifying the system easier

3.Design Goals(Continued)

Cost For same quality, minimize cost Design costs are quite small Should try to minimize cost in later phases Fault tolerance The built-in capacity of a system to provide continued correct service in the presence of one or more failures. Flexibility The design should be easily adaptable when changes of requirements occur User friendliness The design is easy for an untrained user to use; especially the design should have a uniform look and feel and standard interfaces Good documentation Program listings or technical manuals describing the operation and use of programs

4. Stages of system design

System design goes through logical and physical stages of development.

Logical design :
Review the present physical system that is its data flows , file content , volumes , etc. Prepare input/output specifications determines format , content of input and output , etc. Prepare edit ,security and control specifications Prepare implementation plan Modeling techniques are used to represent the actual system in a simple graphical way Prepare logical design walkthrough Review benefits , costs , conversion date and system constraints

The physical design:

Design the physical system Specify input/output media Design the database and specify backup procedures Design physical information flow and physical design walkthrough Plan the system implementation details Prepare a conversion schedule and target date Determine training procedures , courses and timetable Update benefits , costs , conversion date and system constraints Devise a test plan and specify any new hardware and software requirements

Logical design- Data flow diagrams(DFDs)

A DFD is a diagram representation of a system that is used to show how data is captured, processed , stored and distributed within a system. Such diagrammatic representation makes it easier the communication between users and analyst as well as analyst and programmers

During logical design of a system it is important to find out how data flows through a system:

Where does the data originate What processing is performed on it and by whom Who uses the data What data is stored and where What output is produced and who receives it

The DFD is a diagram that consists principally of four symbols, namely the external entity, the data flow, the process and the data store.

Logical design- Data flow diagrams(DFDs)

Squares representing external entities, which are sources or destinations of data. Rounded rectangles representing processes, which take data as input, do something to it, and output it. Arrows representing the data flows, which can either be electronic data or physical items. Open-ended rectangles representing data stores, including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper.

Processes External entities

Data flows

Data stores

Data Flow Diagrams Tips

The process is the main building block of DFDs. Identifying processes is not as straightforward as it seems and a certain knack is required. For a process to be complete, it needs to have both an input and an output (shown by data flows going into and coming out of it). If a process has no input then it has generated data for itself, something that is not allowed. If a process has no output then it has no use and exists only for itself.

26/12/2011

11

Data Flow Diagrams Tips

As with processes, data stores should both receive information for storing and provide it for further processing.

If a data store exists without a flow from a process coming into it or a flow towards a process coming out of it then the analyst should further investigate the system (by asking the user such questions as how does the information get here in the first place? and who uses this information after it gets here?).
Direct flows of information between two data stores are evidently not possible. A data store is passive. It does not suddenly jump up and throw data to another data store in the same way that the contents of a cabinet dont suddenly materialise somewhere else, as if moved by a poltergeist(ghost).

Data Flow Diagrams Tips

Some action has to take place to pick things out of one data store and redistribute them to others. That action is depicted by a process box which will need to intervene between the two communicating data stores. Data stores contain the data that exists inside a system. As such, data stores belong to the system and no one outside the system should have access to them. This means that an external entity cannot, under any circumstances, be connected via a data flow directly to a data store.

Data Flow Diagrams Tips

There should always be a process in between an external entity and a data store to either retrieve the data from the data store for sending to the external entity or to receive the data from an external entity before putting it into the appropriate data store. Conversely, a process that does neither take data from a data store nor puts data into one does not belong to the system and its inclusion should be further investigated. The data store is fundamental to an information system since it represents the location of the information. Any process that does not communicate with the information in the data stores is simply not a process of this information system.

Main steps to draw DFDs

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Identify the external entities Identify a general process that describes the over all activity Represent the external entities and the general process using correct symbols Connect the identified components with labeled data flows Identify and draw the more detailed processes using correct symbols Allocate appropriate descriptions to processes Connect external entities and processes using appropriate labeled data flows Identify and draw any data stores Connect processes and data stores with named data flows If refinement is needed , follow the above steps and make the required modification Observe the next slide that shows an example DFD for a Restaurant System

Example DFD Step 1

CUSTOMER

KITCHEN

RESTAURANT MANAGER

Example DFD Step 2 & 3

CUSTOMER

KITCHEN

0
Food ordering system

RESTAURANT MANAGER

Example DFD Step 4

CUSTOMER

KITCHEN

0
Customer Order Food ordering system

Food Order

Receipt Management Reports RESTAURANT MANAGER

The figure above shows a context diagram(top level DFD) for the Restaurant System

Example DFD Step 4

CUSTOMER

KITCHEN

0
Customer Order Food ordering system

Food Order

Receipt Manageme nt Reports

Does this show enough detail?

RESTAURANT MANAGER

Example DFD Step 5 & 6

1.0
Receive and transform Customer Food Order

3.0
Update Goods Sold file

2.0
Update Inventory file

4.0
Produce Management Reports

Example DFD Step 7

CUSTOMER Customer Order Receipt

1.0
KITCHEN Receive and transform Customer Food Order Food Order

2.0 3.0
Update Goods Sold file Update Inventory file

4.0
Produce Manageme nt Reports Management Reports RESTAURANT MANAGER

Example DFD Step 8

CUSTOMER Customer Order Receipt

1.0
KITCHEN Receive and transform Customer Food Order Food Order

2.0 3.0
Update Goods Sold file Update Inventory file

D1

Goods sold File

4.0
Produce Manageme nt Reports Manageme nt Reports

D2

Inventory File

RESTAURANT MANAGER

Example DFD Step 9

1.0
CUSTOMER
Customer Order

KITCHEN
Receive and transform Customer Food Order
Food Order

Receipt

3.0
Update Goods Sold file

Goods Sold

Inventory Data

2.0
Update Inventory file
Inventory Data

Goods Sold Data

D1 Goods Sold

4.0
Produce Manageme nt Reports

D2 Inventory File

Daily Goods Sold Amount

Daily Inventory Depletion Amounts

Management Reports

RESTAURANT MANAGER

Dos and Donts when constructing a Data Flow Diagram

Dos and Donts when constructing a Data Flow Diagram

Dos and Donts when constructing a Data Flow Diagram

5.Design Methodologies
Design methodologies refer to the collection of procedures, techniques , tools and documentation aids which help system designers to develop the proper design of the new system to be developed. Design methodologies are very importance to introduce structure into design so that the design process will be complete , consistent and more manageable and to minimize risks of failure in the latter stages of development. Design methodologies provide a set of rules for guiding the designer Many design methodologies exist Different methodologies may be useful for different applications

Advantages of design methodologies

Improve productivity of analysts and programmers Improve documentation & subsequent maintenance and enhancement Cut down drastically on cost overruns and delays Improve communication among users, analysts , designers and programmers Standardize the approach to analysis and design Simplify design by segmentation

Top-down vs. Bottom-up design

Top down design starts with the system specifications
It is also called step-wise design It involves the breaking down of a complex system to gain insight into its compositional subsystems Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements Advantages: At each stage of design a clear picture of the whole design exists Most natural for handling complex problems Structuring the design provides control and improves morale Critical interfaces are tested first Much less time is needed for development Ease of maintenance

In bottom up design the designer will start by designing bottom modules

The individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed Necessary if existing modules have to be reused The designer must have some idea of the top modules

Pure top-down or bottom-up design is not always efficient way of system design Often a combination is used

Structured design

Structured design is an attempt to minimize complexity and make a problem manageable by subdividing it into smaller segments . This processes is called modularization or decomposition Modules are arranged in a hierarchical manner with the general modules at the top and detailed modules at the bottom Modularization enhances design clarity, simplifies implementation , reduces cost of testing, debugging and maintenance The system designer cannot simply chop a program into modules during modularization processes . The designer needs to know some guidelines so that he will know how many relevant modules are necessary and which interactions between/among the modules will best implement the specified requirements The most important guidelines in structured design are cohesion and coupling

Cohesion & Coupling

Cohesion: is the degree to which the components of a module are necessary and sufficient to carry out single , well defined function.

Designers must ensure that they dont split essential processes into fragmented modules Designers must ensure that they dont gather together unrelated processes into meaningless modules. The best modules are those that are functionally cohesive . The worst modules are those that are coincidentally cohesive.

Coupling : is the degree to which the modules are interconnected with or related to one another.
Independent modules: if one module can function completely without the presence of other Independence between modules is desirable Modules can be modified separately Can be implemented and tested separately This decreases programming cost In a system all modules cannot be independent Modules must cooperate with each other More connections between modules More dependent they are More knowledge about one module is required to understand the other module. "Highly coupled" modules are joined by strong interconnection "Loosely coupled" modules have weak interconnections

More on Coupling
Modules should be as loosely coupled as possible . Where possible, we should have independent modules Coupling is inter-module concept Complexity and obscurity of interfaces increase coupling Minimize the number of interfaces per module and keep the interfaces as simple as possible. Coupling is minimized if Only defined entry of a module is used by others Information is passed exclusively through parameters Coupling increases if Indirect and obscure interfaces are used Internals of a module are directly used Shared variables employed for communication

Structure Charts

A Structure Chart (Hierarchy chart) is a graphic representation of structure

Structure Chart represents modules and their interconnections. It is the documentation tool for structured design
Structure chart has three elements:

Each module is represented by a rectangle with a name Connection between modules is represented by a vector linking those modules The coupling between modules is represented by an arrow with a circular tail.

Structure Chart Example

Structured design walkthrough

Structured design walkthrough is nothing but it is the exchange of ideas among peers who review the output of design.

The design is presented by its authors to the members of the team and other participants , in which the participants ask questions , give comments about possible mistakes , violation of design standards , etc. to identify the possible problems as early as possible and to suggest a possible solution. This is a practical implementation of the proverb a stitch in time saves nine which means a timely effort will save you from more work later. The objective is to come up with a maintainable design that is flexible and adaptable and meets the organizations standards.
User involvement is very important during system design . It gives the designer important feedback as the design is being completed. It also provides the user with a basic understanding of what the candidate system will and will not do.

Development activities during structural design

There are several development activities that are carried out during structured design: 1. Database design : design of the physical database determining how storage formats and access paths are to be implemented 2. Program design : decision on the programming language to be used and the flow chart , coding , and debugging procedures prior to conversion. 3. System and program test preparation : prepare a detailed schedule about when and by whom the different types of tests are to be conducted. 4. System interface Specification : this specifies for the user how information should enter and leave the system . The designer must provide various options of interface . User documentation in the form of user manual must be prepared before the system is ready for implementation. The manual provides instructions on how to install and operate the system , how to provide input , how to access , update , or retrieve information , how to display or print an output , in what format , etc.

End of Slides

If you have any question?