Software Engineering

Unit-2

Chapter-4 (Software design)

Design process and concepts, Effective Modular design, the design model, Design
documentation, Approaches to Software design.

Chapter-5 (Software Project management)

Software project planning, Project estimation techniques, COCOMO Model,

Project scheduling, Risk analysis and management, Software quality and
management, software configuration management.

Chapter-6 (User interface Design)

Characteristics of good user interface design, Command language user interface,

Menu based, Direct manipulation interfaces, Fundamentals of command based
user interface.

Prepared By: Er. Inderjeet Singh(e8822) Page 1

 Software Engineering

Chapter 4: Software Design

During the software design phase, the design document is produced, based on the
customer requirements as documented in the SRS document.

The design document produced at the end of the design phase should be
implementable using a programming language in the subsequent (coding) phase.

Outcome of the Design Process

• Different modules required: The different modules in the solution should

be clearly identified. Each module is a collection of functions and the data
shared by the functions of the module. Each module should accomplish
some well-defined task out of the overall responsibility of the
software. Each module should be named according to the task it performs.
For example, in an academic automation software, the module consisting of
the functions and data necessary to accomplish the task of registration of the
students should be named handle student registration.
• Control relationships among modules: A control relationship between two
modules essentially arises due to function calls across the two modules. The

Prepared By: Er. Inderjeet Singh(e8822) Page 2

 Software Engineering

control relationships existing among various modules should be identified in

the design document.
• Interfaces among different modules: The interfaces between two
modules identifies the exact data items that are exchanged between the
two modules when one module invokes a function of the other module.
• Data structures of the individual modules: Each module normally stores
some data that the functions of the module need to share to accomplish the
overall responsibility of the module. Suitable data structures for storing and
managing the data of a module need to be properly designed and
documented.
• Algorithms required to implement the individual modules: Each function
in a module usually performs some processing activity. The algorithms
required to accomplish the processing activities of various modules need to
be carefully designed and documented with due considerations given to the
accuracy of the results, space and time complexities.

Classification of Design Activities

A good software design is seldom realised by using a single step procedure,

rather it requires iterating over a series of steps called the design activities.

Depending on the order in which various design activities are performed, we can
broadly classify them into two important stages.

Prepared By: Er. Inderjeet Singh(e8822) Page 3

 Software Engineering

• Preliminary (or high-level) design, and

• Detailed design.

Note: Through high-level design, a problem is decomposed into a set of modules.

The control relationships among the modules are identified, and also the
interfaces among various modules are identified.

PRELIMINARY OR HIGH LEVEL DESIGN

The outcome of high-level design is called the program structure or the software
architecture. High-level design is a crucial step in the overall design of a software.
When the high-level design is complete, the problem should have been
decomposed into many small functionally independent modules that are
cohesive, have low coupling among themselves, and are arranged in a hierarchy.
Many different types of notations have been used to represent a high-level design.
A notation that is widely being used for procedural development is a tree-like
diagram called the structure chart. Another popular design representation
techniques called UML that is being used to document object-oriented design,
involves developing several types of diagrams to document the object-oriented
design of a systems.

Prepared By: Er. Inderjeet Singh(e8822) Page 4

 Software Engineering

DETAILED DESIGN

The outcome of the detailed design stage is usually documented in the form of a
module specification (MSPEC) document. After the high-level design is complete,
the problem would have been decomposed into small modules, and the data
structures and algorithms to be used described using MSPEC and can be easily
grasped by programmers for initiating coding.

Analysis versus design

The analysis results are generic and does not consider implementation or the
issues associated with specific platforms. The analysis model is usually
documented using some graphical formalism. In case of the function-oriented
approach that we are going to discuss, the analysis model would be
documented using data flow diagrams (DFDs), whereas the design would be
documented using structure chart. On the other hand, for object-oriented
approach, both the design model and the analysis model will be documented using
unified modelling language (UML). The analysis model would normally be very
difficult to implement using a programming language.

The design model is obtained from the analysis model through

transformations over a series of steps. In contrast to the analysis model, the
design model reflects several decisions taken regarding the exact way system is
to be implemented. The design model should be detailed enough to be easily
implementable using a programming language.

Prepared By: Er. Inderjeet Singh(e8822) Page 5

 Software Engineering

Characteristics of a Good Software Design

1. Correctness: Software design should be correct as per requirement.

2. Completeness: The design should have all components like data structures,
modules, and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.

Software Design Levels

Software design yields three levels of results:

• Architectural Design - The architectural design is the highest abstract

version of the system. It identifies the software as a system with many
components interacting with each other. At this level, the designers get
the idea of proposed solution domain.
• High-level Design- The high-level design breaks the ‘single entity-multiple
component’ concept of architectural design into less-abstracted view of
sub-systems and modules and depicts their interaction with each other.
High-level design focuses on how the system along with all of its
components can be implemented in forms of modules. It recognizes

Prepared By: Er. Inderjeet Singh(e8822) Page 6

 Software Engineering

modular structure of each sub-system and their relation and interaction

among each other.
• Detailed Design- Detailed design deals with the implementation part of
what is seen as a system and its sub-systems in the previous two designs.
It is more detailed towards modules and their implementations. It defines
logical structure of each module and their interfaces to communicate
with other modules.

An understandable design is modular and layered

To be able to compare the understandability of two design solutions, we should

at least have an understanding of the general features that an easily
understandable design should possess. A design solution should have the
following characteristics to be easily understandable:

1. It should assign consistent and meaningful names to various design

components.
2. It should make use of the principles of decomposition and abstraction in
good measures to simplify the design.

Note: A design solution should be modular and layered to be understandable.

Prepared By: Er. Inderjeet Singh(e8822) Page 7

 Software Engineering

Modularity

A modular design is an effective decomposition of a problem. It is a basic

characteristic of any good design solution. A modular design, in simple words,
implies that the problem has been decomposed into a set of modules that have
only limited interactions with each other. Decomposition of a problem into
modules facilitates taking advantage of the divide and conquer principle.

If different modules have either no interactions or little interactions with each

other, then each module can be understood separately. This reduces the
perceived complexity of the design solution greatly.

For example, consider two alternate design solutions to a problem that are
represented in Figure 5.2, in which the modules M1, M2 etc. have been drawn as
rectangles. The invocation of a module by another module has been shown as an
arrow. It can easily be seen that the design solution of Figure 5.2(a) would be
easier to understand since the interactions among the different modules is low.

Prepared By: Er. Inderjeet Singh(e8822) Page 8

 Software Engineering

Note: A software design with high cohesion and low coupling among modules is
the effective problem decomposition.

Layered design

A layered design is one in which when the call relations among different modules
are represented graphically, it would result in a tree-like diagram with clear
layering. In a layered design solution, the modules are arranged in a hierarchy
of layers.

A module can only invoke functions of the modules in the layer immediately
below it. The higher layer modules can be considered to be similar to managers
that invoke (order) the lower layer modules to get certain tasks done. A layered
design can be considered to be implementing control abstraction, since a module
at a lower layer is unaware of (about how to call) the higher layer modules.

A layered design can make the design solution easily understandable, since to
understand the working of a module, one would at best have to understand
how the immediately lower layer modules work without having to worry about
the functioning of the upper layer modules.

When a failure is detected while executing a module, it is obvious that the

modules below it can possibly be the source of the error. This greatly
simplifies debugging since one would need to concentrate only on a few modules
to detect the error.

Prepared By: Er. Inderjeet Singh(e8822) Page 9

 Software Engineering

COHESION AND COUPLING

Cohesion is a measure of the functional strength of a module, whereas the

coupling between two modules is a measure of the degree of interaction (or
interdependence) between the two modules.

Coupling: Intuitively, we can think of coupling as follows. Two modules are said to
be highly coupled, if either of the following two situations arise:

1. If the function calls between two modules involve passing large chunks of
shared data, the modules are tightly coupled.
2. If the interactions occur through some shared data, then also we say that
they are highly coupled.
If two modules either do not interact with each other at all or at best interact by
passing no data or only a few primitive data items, they are said to have low
coupling.

Cohesion:

Suppose you listened to a talk by some speaker. You would call the speech to be
cohesive, if all the sentences of the speech played some role in giving the talk a
single and focused theme.

Now, we can extend this to a module in a design solution. When the functions of
the module co-operate with each other for performing a single objective, then
the module has good cohesion. If the functions of the module do very different

Prepared By: Er. Inderjeet Singh(e8822) Page 10

 Software Engineering

things and do not co-operate with each other to perform a single piece of work,
then the module has very poor cohesion.

Classification of Coupling

The coupling between two modules indicates the degree of interdependence

between them. Intuitively, if two modules interchange large amounts of data, then
they are highly interdependent or coupled.

These different types of coupling, in increasing order of their severities have also
been shown in Figure 5.5.

1. Data coupling: Two modules are data coupled, if they communicate using
an elementary data item that is passed as a parameter between the two,
e.g. an integer, a float, a character, etc. This data item should be problem
related and not used for control purposes.
Or

When data of one module is passed to another module, this is called data
coupling.

Prepared By: Er. Inderjeet Singh(e8822) Page 11

 Software Engineering

2. Stamp coupling: Two modules are stamp coupled, if they communicate

using a composite data item such as a record in PASCAL or a structure in C.
Or

Two modules are stamp coupled if they communicate using composite data items
such as structure, objects, etc. When the module passes non-global data
structure or entire structure to another module, they are said to be stamp
coupled. For example, passing structure variable in C or object in C++ language to
a module.

3. Control coupling: Control coupling exists between two modules, if data

from one module is used to direct the order of instruction execution in
another. An example of control coupling is a flag set in one module and
tested in another module.
Or

Control Coupling exists among two modules if data from one module is used to
direct the structure of instruction execution in another.

Prepared By: Er. Inderjeet Singh(e8822) Page 12

 Software Engineering

4. Common coupling: Two modules are common coupled, if they share some
global data items.
Or

Two modules are common coupled if they share information through some global
data items.

5. Content coupling: Content coupling exists between two modules, if they

share code. That is, a jump from one module into the code of another
module can occur. Modern high-level programming languages such as C
do not support such jumps across modules.
Or

Content Coupling exists among two modules if they share code, e.g., a branch
from one module into another module.

Note: High coupling among modules not only makes a design solution
difficult to understand and maintain, but it also increases development effort

Prepared By: Er. Inderjeet Singh(e8822) Page 13

 Software Engineering

and also makes it very difficult to get these modules developed independently by
different team members.

Classification of Cohesiveness

Cohesiveness of a module is the degree to which the different functions of the

module co-operate to work towards a single objective. The different modules of a
design can possess different degrees of freedom. However, the different classes of
cohesion that modules can possess are depicted in Figure 5.3. The cohesiveness
increases from coincidental to functional cohesion. That is, coincidental is the
worst type of cohesion and functional is the best cohesion possible. These
different classes of cohesion are elaborated below.

1. Coincidental cohesion: A module is said to have coincidental cohesion, if it

performs a set of tasks that relate to each other very loosely, if at all. In
this case, we can say that the module contains a random collection of
functions. It is likely that the functions have been placed in the module out
of pure coincidence rather than through some thought or design. The
designs made by novice programmers often possess this category of

Prepared By: Er. Inderjeet Singh(e8822) Page 14

 Software Engineering

cohesion, since they often bundle functions to modules rather arbitrarily. An

example of a module with coincidental cohesion has been shown in Figure.
Example: Observe that the different functions of the module carry out very
different and unrelated activities starting from issuing of library books to
creating library member records on one hand, and handling librarian leave
request on the other.

Or

A module is said to have coincidental cohesion if it performs a set of tasks that are
associated with each other very loosely, if at all.

2. Logical cohesion: A module is said to be logically cohesive, if all elements of

the module perform similar operations, such as error handling, data
input, data output, etc. As an example of logical cohesion, consider a

Prepared By: Er. Inderjeet Singh(e8822) Page 15

 Software Engineering

module that contains a set of print functions to generate various types of

output reports such as grade sheets, salary slips, annual reports, etc.
Or

A module is said to be logically cohesive if all the elements of the module perform
a similar operation. For example Error handling, data input and data output, etc.

3. Temporal cohesion: When a module contains functions that are related by

the fact that these functions are executed in the same time span, then the
module is said to possess temporal cohesion. As an example, CPU boot
initialize all parts of the system.
Or
The elements are related by their timing involved. A module connected with
temporal cohesion all the tasks must be executed in the same time span. This
cohesion contains the code for initializing all the parts of the system. Lots of
different activities occur, all at unit time.

4. Procedural cohesion: A module is said to possess procedural cohesion, if the

set of functions of the module are executed one after the other, though
these functions may work towards entirely different purposes and operate
on very different data. Consider the activities associated with order
processing in a trading house. The functions login(), place-order(), check-
order(), print-bill(), place-order-on-vendor(), update-inventory(), and

Prepared By: Er. Inderjeet Singh(e8822) Page 16

 Software Engineering

logout() all do different thing and operate on different data. However, they
are normally executed one after the other during typical order processing by
a sales clerk.
Or

A module is said to be procedural cohesion if the set of purpose of the module are
all parts of a procedure in which particular sequence of steps has to be carried out
for achieving a goal, e.g., the algorithm for decoding a message.

5. Communicational cohesion: A module is said to have communicational

cohesion, if all functions of the module refer to or update the same data
structure. As an example of procedural cohesion, consider a module named
student in which the different functions in the module such as admitStudent,
enterMarks, printGradeSheet, etc. access and manipulate data stored in an
array named studentRecords defined within the module.
Or

A module is said to have communicational cohesion, if all tasks of the module refer
to or update the same data structure, e.g., the set of functions defined on an array
or a stack.

6. Sequential cohesion: A module is said to possess sequential cohesion, if the

different functions of the module execute in a sequence, and the output
from one function is input to the next in the sequence. As an example
consider the following situation. In an on-line store consider that after a

Prepared By: Er. Inderjeet Singh(e8822) Page 17

 Software Engineering

customer requests for some item, it is first determined if the item is in stock.
In this case, if the functions create-order(), check-item-availability(), place-
order on-vendor() are placed in a single module, then the module would
exhibit sequential cohesion. Observe that the function create-order() creates
an order that is processed by the function check-item-availability()(whether
the items are available in the required quantities in the inventory) is input to
place-order-on-vendor().
Or

A module is said to possess sequential cohesion if the element of a module form

the components of the sequence, where the output from one component of the
sequence is input to the next.

7. Functional cohesion: A module is said to possess functional cohesion, if

different functions of the module co-operate to complete a single task. For
example, a module containing all the functions required to manage
employees’ pay-roll displays functional cohesion. In this case, all the
functions of the module (e.g., computeOvertime(), computeWorkHours(),
computeDeductions(), etc.) work together to generate the payslips of the
employees.
Or

Functional Cohesion is said to exist if the different elements of a module,

cooperate to achieve a single function.

Prepared By: Er. Inderjeet Singh(e8822) Page 18

 Software Engineering

APPROACHES TO SOFTWARE DESIGN

There are two fundamentally different approaches to software design that are in
use today— function-oriented design, and object-oriented design. Though these
two design approaches are radically different, they are complementary rather than
competing techniques. The object-oriented approach is a relatively newer
technology and is still evolving. For development of large programs, the object-
oriented approach is becoming increasingly popular due to certain advantages
that it offers. On the other hand, function-oriented designing is a mature
technology and has a large following.

Function-oriented Design

Function Oriented design is a method to software design where the model is

decomposed into a set of interacting units or modules where each unit or
module has a clearly defined function. Thus, the system is designed from a
functional viewpoint.

The following are the salient features of the function-oriented design approach:

Top-down decomposition: A system, to start with, is viewed as a black box that

provides certain services (also known as high-level functions) to the users of the
system.

In top-down decomposition, starting at a high-level view of the system, each high-

level function is successively refined into more detailed functions.

Prepared By: Er. Inderjeet Singh(e8822) Page 19

 Software Engineering

For example, consider a function create-new-library member which essentially

creates the record for a new member, assigns a unique membership number
to him, and prints a bill towards his membership charge. This high-level function
may be refined into the following sub-functions:

• assign-membership-number
• create-member-record
• print-bill
Each of these subfunctions may be split into more detailed subfunctions and so on.

Centralised system state: The system state can be defined as the values of certain
data items that determine the response of the system to a user action or
external event.

For example, the set of books (i.e. whether borrowed by different users or
available for issue) determines the state of a library automation system. Such data
in procedural programs usually have global scope and are shared by many
modules.

Data Flow Diagram

Data-flow design is concerned with designing a series of functional

transformations that convert system inputs into the required outputs. The design
is described as data-flow diagrams. These diagrams show how data flows through
a system and how the output is derived from the input through a series of
functional transformations.
Prepared By: Er. Inderjeet Singh(e8822) Page 20
 Software Engineering

Data-flow diagrams are a useful and intuitive way of describing a system. They
are generally understandable without specialized training, notably if control
information is excluded. They show end-to-end processing. That is the flow of
processing from when data enters the system to where it leaves the system can be
traced.

Data-flow design is an integral part of several design methods, and most CASE
tools support data-flow diagram creation. Different ways may use different icons
to represent data-flow diagram entities, but their meanings are similar.

Data Dictionaries

A data dictionary lists all data elements appearing in the DFD model of a system.
The data items listed contain all data flows and the contents of all data stores
looking on the DFDs in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all
composite data elements in terms of their component data items.

Structured Charts

It partitions a system into block boxes. A Black box system that functionality is
known to the user without the knowledge of internal design.

Prepared By: Er. Inderjeet Singh(e8822) Page 21

 Software Engineering

Top Down Design

• We know that a system is composed of more than one sub-systems and it

contains a number of components.

• Further, these sub-systems and components may have their on set of sub-
system and components and creates hierarchical structure in the system.

• Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component based
on some characteristics.

• Each sub-system or component is then treated as a system and

decomposed further.

• This process keeps on running until the lowest level of system in the top-
down hierarchy is achieved.
Prepared By: Er. Inderjeet Singh(e8822) Page 22
 Software Engineering

• Top-down design starts with a generalized model of system and keeps on

defining the more specific part of it.

• When all components are composed the whole system comes into
existence.

• Top-down design is more suitable when the software solution needs to be

designed from scratch and specific details are unknown.

Advantages:

• The main advantage of top down approach is that its strong focus on
requirements helps to make a design responsive according to its
requirements.

Prepared By: Er. Inderjeet Singh(e8822) Page 23

 Software Engineering

Disadvantages:

• Project and system boundaries tends to be application specification oriented.

Thus it is more likely that advantages of component reuse will be missed.

• The system is likely to miss, the benefits of a well-structured, simple

architecture.

Bottom Up Design

• The bottom up design model starts with most specific and basic components.

• It proceeds with composing higher level of components by using basic or

lower level components.

• It keeps creating higher level components until the desired system is not
evolved as one single component.

• With each higher level, the amount of abstraction is increased.

• Bottom-up strategy is more suitable when a system needs to be created

from some existing system, where the basic primitives can be used in the
newer system.

• Both, top-down and bottom-up approaches are not practical individually.

Instead, a good combination of both is used.

Prepared By: Er. Inderjeet Singh(e8822) Page 24

 Software Engineering

Advantages:

• The economics can result when general solutions can be reused.

• It can be used to hide the low-level details of implementation and be merged

with top-down technique.

Disadvantages:

• It is not so closely related to the structure of the problem.

• High quality bottom-up solutions are very hard to construct.

• It leads to increase of ‘potentially useful’ functions rather than most

appropriate ones.

Hybrid Design: It is a combination of both the top – down and bottom – up design
strategies. In this we can reuse the modules.

Prepared By: Er. Inderjeet Singh(e8822) Page 25

 Software Engineering

Object-oriented Design

In the object-oriented design (OOD) approach, a system is viewed as being made

up of a collection of objects (i.e. entities). Each object is associated with a set of
functions that are called its methods.

Each object contains its own data and is responsible for managing it. The data
internal to an object cannot be accessed directly by other objects and only
through invocation of the methods of the object. The system state is
decentralised since there is no globally shared data in the system and data is
stored in each object.

For example, in a library automation software, each library member may be a

separate object with its own data and functions to operate on the stored data. The
methods defined for one object cannot directly refer to or change the data of
other objects.

Prepared By: Er. Inderjeet Singh(e8822) Page 26

 Software Engineering

1. Objects: All entities involved in the solution design are known as objects.
For example, person, banks, company, and users are considered as objects.
Every entity has some attributes associated with it and has some methods to
perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an
instance of a class. A class defines all the attributes, which an object can
have and methods, which represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of
the integrity of the target object, the name of the requested operation, and
any other action needed to perform the function. Messages are often
implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using
abstraction. Abstraction is the removal of the irrelevant and the
amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept.
The data and operations are linked to a single unit. Encapsulation not only
bundles essential information of an object together but also restricts access
to the data and methods from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner
where the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate superclasses. This property of

Prepared By: Er. Inderjeet Singh(e8822) Page 27

 Software Engineering

OOD is called an inheritance. This makes it easier to define a specific class

and to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned the same
name. This is known as polymorphism, which allows a single interface is
performing functions for different types. Depending upon how the service is
invoked, the respective portion of the code gets executed.

Prepared By: Er. Inderjeet Singh(e8822) Page 28

 Software Engineering

Difference between Function Oriented Design and Object Oriented

Design
COMPARISON FUNCTION ORIENTED DESIGN OBJECT ORIENTED DESIGN
FACTORS
execute carried out using structured Carried out using UML
analysis and structured design i.e,
data flow diagram
State In this approach the state In this approach the state information is
information information is often represented not represented in a centralized
in a centralized shared memory. memory but is implemented or
distributed among the objects of the
system.
Approach It is a top down approach. It is a bottom up approach.
Begins basis Begins by considering the use Begins by identifying objects and
case diagrams and the scenarios. classes.
Decompose In function oriented design we We decompose in class level.
decompose in
function/procedure level.
Use This approach is mainly used for This approach is mainly used for
computation sensitive evolving system which mimics a
application. business or business case.

Prepared By: Er. Inderjeet Singh(e8822) Page 29

 Software Engineering

Introduction to Design Modeling in Software Engineering

Design modeling in software engineering represents the features of the software
that helps engineer to develop it effectively, the architecture, the user interface,
and the component level detail.

Design modeling provides a variety of different views of the system like

architecture plan for home or building. Different methods like data-driven,
pattern-driven, or object-oriented methods are used for constructing the design
model. All these methods use set of design principles for designing a model.

Working of Design Modeling in Software Engineering

Designing a model is an important phase and is a multi-process that represent the

data structure, program structure, interface characteristic, and procedural
details. It is mainly classified into four categories – Data design, architectural
design, interface design, and component-level design.

 Data design: It represents the data objects and their interrelationship in an

entity-relationship diagram. Entity-relationship consists of information
required for each entity or data objects as well as it shows the relationship
between these objects. It shows the structure of the data in terms of the
tables. It shows three type of relationship – One to one, one to many, and
many to many. In one to one relation, one entity is connected to another
entity. In one many relation, one Entity is connected to more than one entity.
Prepared By: Er. Inderjeet Singh(e8822) Page 30
 Software Engineering

In many to many relations one entity is connected to more than one entity as
well as other entity also connected with first entity using more than one
entity.
 Architectural design: It defines the relationship between major structural
elements of the software. It is about decomposing the system into
interacting components. It is expressed as a block diagram defining an
overview of the system structure – features of the components and how
these components communicate with each other to share data. It defines
the structure and properties of the component that are involved in the
system and also the inter-relationship among these components.
 User Interfaces design: It represents how the Software communicates with
the user i.e. the behaviour of the system. It refers to the product where
user interact with controls or displays of the product. For example, Military,
vehicles, aircraft, audio equipment, computer peripherals are the areas
where user interface design is implemented. UI design becomes efficient only
after performing usability testing. This is done to test what works and what
does not work as expected. Only after making the repair, the product is said
to have an optimized interface.
 Component level design: It transforms the structural elements of the
software architecture into a procedural description of software
components. It is a perfect way to share a large amount of data.
Components need not be concerned with how data is managed at a

Prepared By: Er. Inderjeet Singh(e8822) Page 31

 Software Engineering

centralized level i.e. components need not worry about issues like backup
and security of the data.

Principles of Design Model

 Design must be traceable to the analysis model:

Analysis model represents the information, functions, and behaviour of the

system. Design model translates all these things into architecture – a set of
subsystems that implement major functions and a set of component level design
that are the realization of Analysis classes. This implies that design model must be
traceable to the analysis model.

 Focus on the design of the data:

Data design encompasses the manner in which the data objects are realized
within the design. It helps to simplify the program flow, makes the design and
implementation of the software components easier, and makes overall
processing more efficient.

 User interfaces should consider the user first:

The user interface is the main thing of any software. No matter how good its
internal functions are or how well designed its architecture is but if the user
interface is poor and end-users don’t feel ease to handle the software then it
leads to the opinion that the software is bad.

Prepared By: Er. Inderjeet Singh(e8822) Page 32

 Software Engineering

 Components should be loosely coupled:

Coupling of different components into one is done in many ways like via a
component interface, by messaging, or through global data. As the level of
coupling increases, error propagation also increases, and overall maintainability of
the software decreases. Therefore, component coupling should be kept as low as
possible.

 Component level design should exhibit Functional independence:

It means that functions delivered by component should be cohesive i.e. it should

focus on one and only one function or sub-function.

Software Design Document:

Software Design Document is a written document that provides a description of

a software product in terms of architecture of software with various components
with specified functionality.

The design specification addresses different aspects of the design model and is
completed as the designer refines his representation of the software. These design
documents are written by software engineers/designers or project managers and
further passed to the software development team to give them an overview of
what needs to be built and how.

Prepared By: Er. Inderjeet Singh(e8822) Page 33

 Software Engineering

S.No Software Design Document Module, Subpart

01. Reference Documents 1. Existing software documentation
2. System Documentation
3. Vendor(hardware or software) documents
4. Technical reference

02. Modules for each module

1. Interface description
2. Design language(or other) description
3. Modules used

03. Scope 1. System objective

2. Hardware, software and human interfaces
3. Major software functions
4. Externally defined database
5. Major design constraints, limitations

04. Design Description 1. Data description

2. Derived program structure
3. Interface within structure

05. Test Provisions 1. Test guidelines

2. Integration strategy
3. Special considerations

06. Packaging 1. Special program covering provisions

Prepared By: Er. Inderjeet Singh(e8822) Page 34

 Software Engineering

2. Transfer consideration

07. File Structure and global data 1. External Files structure

2. Global data
3. File and data cross – reference

08. Requirement cross-reference 1. cross-reference

Design Documentation

• Design documentation is a collection of documents and resources that

covers all aspects of your product design.

• Documentation should include information about users, product features,

and project deadlines; all essential implementation details; and design
decisions that your team and stakeholders have agreed on.

• The Design Document will be the starting point work product for a number of
assignments.

• In many cases the Design Document is done before any of the actual
"work".

• The Design Document could be seen a part of the Plan on what you will do.

Prepared By: Er. Inderjeet Singh(e8822) Page 35

 Software Engineering

• Design Document as providing more of a technical overview and the Plan

as a second document which includes assumptions, justifications, and the
like necessary for meeting the customer's requirements.

• The Implementation then would be the final step, in which you detail
exactly – often in a step-by-step manner - what you did to actually complete
the work required by the Design Document and Plan.

If you have a three-document model:

• Design - the picture that describes the end result (it often doesn't include
product names, but might in some cases).

• Plan - a milestone-level view of how that design will get accomplished (no
commands are included, but product names and the processes selected
might very well be documented).

• Implementation - a step-by-step list of what to do which could be used to

reproduce the work, possibly by someone who isn’t familiar with the design
or plan.

Documentation can vary from project to project. Many consulting companies and
resellers have standard documentation templates that they use when designing
solutions. A properly documented design should include the following
information:

• Architecture design

Prepared By: Er. Inderjeet Singh(e8822) Page 36

 Software Engineering

• Implementation plan

• Installation guide

• Validation test plan

• Operational procedures

Architecture Design: The architecture design document is a technical

document describing the components and specifications required to support
the solution and ensure that the specific business and technical requirements
of the design are satisfied.

Note: The architecture design document should include the following

information:

1. Purpose and overview

a. Executive summary

b. Design methodology

2. Conceptual design

3. Logical management, storage, compute, and network design

4. Physical management, storage, compute, and network design

A sample outline of the architecture design document is as follows:

Prepared By: Er. Inderjeet Singh(e8822) Page 37

 Software Engineering

• Cover page: It includes the customer and project names

• Document version log: It contains the log of authors and changes made to
the document

• Document contacts: It includes the subject matter experts involved in the

creation of the design

• Table of contents: It is the index of the document sections for quick

reference

• List of tables: It is the index of tables included in the document for quick
reference

• List of figures: It is the index of figures included in the document for quick
reference

• Purpose and overview: This section consists of an executive summary to

provide an overview of the design and the design methodology followed in
creating the design

• Conceptual design: It is the documentation of the design factors:

requirements, constraints, and assumptions

• Logical design: It has the details of the logical management, storage,

network, and compute design

Prepared By: Er. Inderjeet Singh(e8822) Page 38

 Software Engineering

• Physical design: It contains the details of the selected hardware and the
configuration of the physical and virtual hardware

Writing an implementation plan

• The implementation plan documents the requirements necessary to

complete the implementation of the design.

• The implementation plan defines the project roles and defines what is
expected of the customer and what they can expect during the
implementation of the design.

• This document is sometimes referred to as the statement of work. It defines

the key points of contact, the requirements that must be satisfied to start the
implementation, any project documentation deliverables, and how changes
to the design and implementation will be handled.

The following is an example outline for an implementation plan:

• Cover page: It includes the customer and project names

• Document version log: It contains the log of authors and changes made to
the document

• Document contacts: It includes the subject matter experts involved in the

creation of the design

• Table of contents: It is the index of document sections for quick reference

Prepared By: Er. Inderjeet Singh(e8822) Page 39

 Software Engineering

• List of tables: It is the index of tables included in the document for quick
reference

• List of figures: It is the index of figures included in the document for quick
reference

• Purpose statement: It defines the purpose of the document

• Project contacts: It is the documentation of key project points of contact

• Implementation requirements: It provides the access, facilities, hardware,

software, and licensing required to complete the implementation

• Implementation overview: It is the overview of the steps required to

complete the implementation

• Project deliverables: It consists of the documents that will be provided as

deliverables once implementation has been completed

Note: The implementation plan should include the following information:

1. Purpose statement

2. Project contacts

3. Implementation requirements

4. Overview of implementation steps

5. Definition of project documentation deliverables

Prepared By: Er. Inderjeet Singh(e8822) Page 40

 Software Engineering

6. Implementation of change management

Developing an installation guide

• The installation guide provides step-by-step instructions for the

implementation of the architecture design.

• This guide should include detailed information about how to implement and
configure all the resources associated with the virtual datacenter project.

• In many projects, the person creating the design is not the person
responsible for implementing the design.

• The installation guide outlines the steps necessary to implement the physical
design outlined in the architecture design document.

The following is an example outline for an installation guide:

• Cover page: It includes the customer and project names

• Document version log: It contains the log of authors and changes made to
the document

• Document contacts: It includes the subject matter experts involved in the

creation of the design

• Table of contents: It is the index of document sections for quick reference

Prepared By: Er. Inderjeet Singh(e8822) Page 41

 Software Engineering

• List of tables: It is the index of tables included in the document for quick
reference

• List of figures: It is the index of figures included in the document for quick
reference

• Purpose statement: It defines the purpose of the document

• Assumption statement: It defines any assumptions made in creating the

document

• Installation guide: It provides the step-by-step installation instructions to be

followed when implementing the design

Note: The installation guide should include the following information:

1. Purpose statement

2. Assumption statement

3. Step-by-step instructions to implement the design

Creating a validation test plan

• The validation test plan documents how the implementation will be verified.

Prepared By: Er. Inderjeet Singh(e8822) Page 42

 Software Engineering

• It documents the criteria that must be met to determine the success of the
implementation and the test procedures that should be followed when
validating the environment.

• The criteria and procedures defined in the validation test plan determine
whether or not the design requirements have been successfully met.

Note: The validation test plan should include the following information:

• Purpose statement

• Assumption statement

• Success criteria

• Test procedures

The following is an example outline of a validation test plan:

• Cover page: It includes the customer and project names

• Document version log: It contains the log of authors and changes made to
the document

• Document contacts: It includes the subject matter experts involved in the

creation of the design

• Table of contents: It is the index of document sections for quick reference

Prepared By: Er. Inderjeet Singh(e8822) Page 43

 Software Engineering

• List of tables: It is the index of tables included in the document for quick
reference

• List of figures: It is the index of figures included in the document for quick
reference

• Purpose statement: It defines the purpose of the document

• Assumption statement: It defines any assumptions made in creating the

document

• Success criteria: It is a list of criteria that must be met to validate the

successful implementation of the design

• Test Procedures: It is a list of test procedures to follow, including the steps to

follow and the expected results

A list of essential documents

• Project overview – This document contains a high-level overview of the

design and the goals the design team wants to accomplish. By reading this
document, anyone should be able to understand the purpose of a project.

• Product requirements – This document covers the business and technical

requirements of the design. It should be shared with stakeholders before

Prepared By: Er. Inderjeet Singh(e8822) Page 44

 Software Engineering

starting the design to ensure that both types of requirements are satisfied.
It’s also worth including in this doc information about constraints and
assumptions because they will influence the design decisions.

• Project deliverables – This document provides information about the design

artifacts established during the wireframing and prototyping phases (e.g., lo-
fi wireframes, mock-ups, hi-fi prototypes) that will be provided as
deliverables once implementation has been completed.

• Target audience information – This document lists relevant information

about your audience, from user personas to data from user research. This
information will help your team understand who your users are and what
good design means to them (via their functional and aesthetic preferences).
The doc serves as a reference for designers when sharing their rationale
behind individual design decisions.

• User journeys – This document outlines the path a user may take to reach
their goal when using a product.

• Design guidelines – This document describes the components and

specifications required to build the solution.

• Style guides – This document lists a set of standards for the stylization of
design. Styles, colors, and typefaces are essential pieces of this guide.

Prepared By: Er. Inderjeet Singh(e8822) Page 45

 Software Engineering

• Project scope and implementation plan – This document describes the roles
and flow of cross-team collaboration. The implementation plan documents
the requirements necessary to complete the implementation of the design.
For simple projects, it might be a high-level overview of the steps required to
complete the implementation. For complex projects, it can include a project
timeline with information about the time required to complete each of the
steps.

• Design validation and user testing – This document provides an overview of

the practices to be executed during the product design cycle, as well as steps
to be taken after product release to verify that the product satisfies user
needs.

• Operational instructions – This document provides detailed instructions on

how to perform common operational tasks after the design is implemented.
For example, it can provide step-by-step instructions on how to roll out a
new version of an app in the production environment.

Prepared By: Er. Inderjeet Singh(e8822) Page 46