Software System & Design Unit - I Semester I B.

Tech (CSE) 2028

Software Design
Software design is a mechanism to transform user requirements into some suitable
form, which helps the programmer in software coding and implementation. It deals
with representing the client's requirement, as described in SRS (Software Requirement
Specification) document, into a form, i.e., easily implementable using programming
language.

The software design phase is the first step in SDLC (Software Design Life Cycle),
which moves the concentration from the problem domain to the solution domain. In
software design, we consider the system to be a set of components or modules with
clearly defined behaviors & boundaries.

Objectives of Software Design:

Page | 2
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

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 Principles

Software design principles are concerned with providing means to handle the
complexity of the design process effectively. Effectively managing the complexity will
not only reduce the effort needed for design but can also reduce the scope of
introducing errors during design.

Following are the principles of Software Design

Page | 3
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the
problem into smaller pieces so that each piece can be captured separately. For software
design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple

3. Software is easy to test

4. Software is easy to modify

5. Software is easy to maintain

6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the
system. They have to cooperate and communicate to solve the problem. This
communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity

increases

Abstraction

Page | 4
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

An abstraction is a tool that enables a designer to consider a component at an abstract

level without bothering about the internal details of the implementation. Abstraction
can be used for existing element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction

2. Data Abstraction
Functional Abstraction
i. A module is specified by the method it performs.

ii. The details of the algorithm to accomplish the functions are not visible to
the user of the function.

Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction
Details of the data elements are not visible to the users of data. Data Abstraction
forms the basis for Object Oriented design approaches.
Modularity
Modularity specifies to the division of software into separate modules which are
differently named and addressed and are integrated later on to obtain the completely
functional software. It is the only property that allows a program to be intellectually
manageable. Single large programs are difficult to understand and read due to a large
number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.

o Each module has single specified objectives.

o Modules can be separately compiled and saved in the library.

o Modules should be easier to use than to build.

o Modules are simpler from outside than inside.

Advantages of Modularity
There are several advantages of Modularity

o It allows large programs to be written by several or different people

o It encourages the creation of commonly used routines to be placed in the

library and used by other programs.

Page | 5
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

o It simplifies the overlay procedure of loading a large program into main

storage.

o It provides more checkpoints to measure progress.

o It provides a framework for complete testing, more accessible to test

o It produced the well designed and more readable program.

Disadvantages of Modularity
There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased

o Compilation and loading time may be longer

o Inter-module communication problems may be increased

o More linkage required, run-time may be longer, more source lines must be
written, and more documentation has to be done
Modular Design
Modular design reduces the design complexity and results in easier and faster
implementation by allowing parallel development of various parts of a system. We
discuss a different section of modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing

functions that perform only one kind of task and do not excessively interact with other
modules. Independence is important because it makes implementation more
accessible and faster. The independent modules are easier to maintain, test, and
reduce error propagation and can be reused in other programs as well. Thus,
functional independence is a good design feature which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules

can be characterized by the design decisions that protect from the others, i.e., In other
words, modules should be specified that data include within a module is inaccessible
to other modules that do not need for such information.

The use of information hiding as design criteria for modular system provides the most
significant benefits when modifications are required during testing's and later during
software maintenance. This is because as most data and procedures are hidden from

Page | 6
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

other parts of the software, inadvertent errors introduced during modifications are
less likely to propagate to different locations within the software.

Software Design Approaches

There are two generic approaches for software designing:

To design a system, there are two possible approaches:

1. Top-down Approach

2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main
components and then decomposing them into their more detailed sub-
components.

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 one 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. 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.

Page | 7
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

2. Bottom-up Approach: A bottom-up approach begins with the lower details and
moves towards up the hierarchy, as shown in fig. This approach is suitable in case of
an existing system.

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.

SOFTWARE DESIGN STRATEGIES (Methodologies)

Software design is a process to conceptualize the software requirements into software
implementation. Software design takes the user requirements as challenges and tries
to find optimum solution. While the software is being conceptualized, a plan is
chalked out to find the best possible design for implementing the intended solution.

There are multiple variants of software design. Few of them are discussed as
follows::

Software design is a process to conceptualize the software requirements into software

implementation. Software design takes the user requirements as challenges and tries
to find optimum solution. While the software is being conceptualized, a plan is
chalked out to find the best possible design for implementing the intended solution.

Page | 8
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Structured Design
Structured design is a conceptualization of problem into several well-organized
elements of solution. It is basically concerned with the solution design. Benefit of
structured design is, it gives better understanding of how the problem is being solved.
Structured design also makes it simpler for designer to concentrate on the problem
more accurately.

Structured design is mostly based on ‘divide and conquer’ strategy where a problem
is broken into several small problems and each small problem is individually solved
until the whole problem is solved.

A good system design strategy is to organize the program modules in such a method
that are easy to develop and latter too, change. Structured design methods help
developers to deal with the size and complexity of programs. Analysts generate
instructions for the developers about how code should be composed and how pieces
of code should fit together to form a program. A good structured design has high
cohesion and low coupling arrangements.

Coupling and Cohesion

Module Coupling
In software engineering, the coupling is the degree of interdependence between
software modules. Two modules that are tightly coupled are strongly dependent on
each other. However, two modules that are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

Page | 9
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

A good design is the one that has low coupling. Coupling is measured by the number
of relations between the modules. That is, the coupling increases as the number of calls
between modules increase or the amount of shared data is large. Thus, it can be said
that a design with high coupling will have more errors.

There are five levels of coupling, namely -

• Content coupling - When a module can directly access or modify or refer to the
content of another module, it is called content level coupling.

• Common coupling- When multiple modules have read and write access to
some global data, it is called common or global coupling.

• Control coupling- Two modules are called control-coupled if one of them

decides the function of the other module or changes its flow of execution.

• Stamp coupling- When multiple modules share common data structure and
work on different part of it, it is called stamp coupling.

• Data coupling- Data coupling is when two modules interact with each other by
means of passing data (as parameter). If a module passes data structure as parameter,
then the receiving module should use all its components.

Ideally, no coupling is considered to be the best.

Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a
module belong together. Thus, cohesion measures the strength of relationships
between pieces of functionality within a given module. For example, in highly
cohesive systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high

cohesion" or "low cohesion."

Page | 10
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

There are seven types of cohesion, namely –

• Co-incidental cohesion - It is unplanned and random cohesion, which might be

the result of breaking the program into smaller modules for the sake of
modularization. Because it is unplanned, it may serve confusion to the programmers
and is generally not-accepted.

• Logical cohesion - When logically categorized elements are put together into a
module, it is called logical cohesion.

• Temporal Cohesion - When elements of module are organized such that they
are processed at a similar point in time, it is called temporal cohesion.

• Procedural cohesion - When elements of module are grouped together, which

are executed sequentially in order to perform a task, it is called procedural cohesion.

• Communicational cohesion - When elements of module are grouped together,

which are executed sequentially and work on same data (information), it is called
communicational cohesion.

• Sequential cohesion - When elements of module are grouped because the

output of one element serves as input to another and so on, it is called sequential
cohesion.

• Functional cohesion - It is considered to be the highest degree of cohesion, and

it is highly expected. Elements of module in functional cohesion are grouped because
they all contribute to a single well-defined function. It can also be reused.

Page | 11
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Cohesion is also called Intra-Module Binding.

Binding.

Coupling shows the relationships Cohesion shows the relationship within the
between modules. module.

Coupling shows the Cohesion shows the module's

relative independence between the relative functional strength.
modules.

While creating, you should aim for While creating you should aim for high
low coupling, i.e., dependency among cohesion, i.e., a cohesive component/ module
modules should be less. focuses on a single function (i.e., single-
mindedness) with little interaction with other
modules of the system.

Function Oriented Design

In function-oriented design, the system is comprised of many smaller sub-systems
known as functions. These functions are capable of performing significant task in the
system. The system is considered as top view of all functions. Function oriented
design inherits some properties of structured design where divide and conquer
methodology is used.

This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their operation.
These functional modules can share information among themselves by means of
information passing and using information available globally.

Another characteristic of functions is that when a program calls a function, the

function changes the state of the program, which sometimes is not acceptable by other
modules. Function oriented design works well where the system state does not matter
and program/functions work on input rather than on a state.

Page | 12
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Design Process
• The whole system is seen as how data flows in the system by means of data
flow diagram.

• DFD depicts how functions change the data and state of entire system.

• The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.

• Each function is then described at large.

Design Notations
Design Notations are primarily meant to be used during the process of design and are
used to represent design or design decisions. For a function-oriented design, the
design can be represented graphically or mathematically by the following:

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.

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.

Page | 13
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

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.

The notation which is used is based on the following symbols:

Page | 14
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

The report generator produces a report which describes all of the named entities in a
data-flow diagram. The user inputs the name of the design represented by the
diagram. The report generator then finds all the names used in the data-flow diagram.
It looks up a data dictionary and retrieves information about each name. This is then
collated into a report which is output by the system.
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. For example, a data dictionary
entry may contain that the data. grossPay consists of the
parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their
type.

A data dictionary plays a significant role in any software development process

because of the following reasons:

o A Data dictionary provides a standard language for all relevant information for
use by engineers working in a project. A consistent vocabulary for data items
is essential since, in large projects, different engineers of the project tend to use
different terms to refer to the same data, which unnecessarily causes confusion.

o The data dictionary provides the analyst with a means to determine the
definition of various data structures in terms of their component elements.
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.

Page | 15
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules

o The relation between processing modules

o Interaction between modules

o Information passed between modules

The following notations are used in structured chart:

Page | 16
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed design
phases. Using pseudo-code, the designer describes system characteristics using short,
concise, English Language phases that are structured by keywords such as If-Then-
Else, While-Do, and End.

Object Oriented Design

Object oriented design works around the entities and their characteristics instead of
functions involved in the software system. This design strategy focuses on entities and
its characteristics. The whole concept of software solution revolves around the
engaged entities.

Important concepts of Object-Oriented Design:

In the object-oriented design method, the system is viewed as a collection of objects

(i.e., entities). The state is distributed among the objects, and each object handles its
state data. For example, in a Library Automation Software, each library representative
may be a separate object with its data and functions to operate on these data. The tasks
defined for one purpose cannot refer or change data of other objects. Objects have their
internal data which represent their state. Similar objects create a class. In other words,
each object is a member of some class. Classes may inherit features from the
superclass.

The different terms related to object design are:

Page | 17
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

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
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.
Design Process
Software design process can be perceived as series of well-defined steps. Though it
varies according to design approach (function oriented or object oriented, yet It may
have the following steps involved:

• A solution design is created from requirement or previous used system

and/or system sequence diagram.

• Objects are identified and grouped into classes on behalf of similarity in

attribute characteristics.

• Class hierarchy and relation among them are defined.

Page | 18
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

• Application framework is defined.

Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle. A life cycle model represents
all the methods required to make a software product transit through its life cycle
stages. It also captures the structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a software
product from its inception to retirement. Different life cycle models may plan the
necessary development activities to phases in different ways. Thus, no element which
life cycle model is followed, the essential activities are contained in all life cycle models
though the action may be carried out in distinct orders in different life cycle models.
During any life cycle stage, more than one activity may also be carried out.
Need of SDLC
The development team must determine a suitable life cycle model for a particular plan
and then observe to it.

Without using an exact life cycle model, the development of a software product would
not be in a systematic and disciplined manner. When a team is developing a software
product, there must be a clear understanding among team representative about when
and what to do. Otherwise, it would point to chaos and project failure. This problem
can be defined by using an example. Suppose a software development issue is divided
into various parts and the parts are assigned to the team members. From then on,
suppose the team representative is allowed the freedom to develop the roles assigned
to them in whatever way they like. It is possible that one representative might start
writing the code for his part, another might choose to prepare the test documents first,
and some other engineer might begin with the design phase of the roles assigned to
him. This would be one of the perfect methods for project failure.

A software life cycle model describes entry and exit criteria for each phase. A phase
can begin only if its stage-entry criteria have been fulfilled. So without a software life
cycle model, the entry and exit criteria for a stage cannot be recognized. Without
software life cycle models, it becomes tough for software project managers to monitor
the progress of the project.
SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes
the following steps:

Page | 19
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis
Requirement Analysis is the most important and necessary stage in SDLC. The senior
members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry. Planning for the quality assurance requirements and
identifications of the risks associated with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all
the data like what the customer wants to build, who will be the end user, what is the
objective of the product. Before creating a product, a core understanding or
knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money

transactions. In this method, the requirement has to be precise like what kind of
operations will be done, how it will be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the
feasibility of the growth of a product. In case of any ambiguity, a signal is set up for
further discussion.

Page | 20
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Once the requirement is understood, the SRS (Software Requirement Specification)

document is created. The developers should thoroughly follow this document and
also should be reviewed by the customer for future reference.
Stage2: Defining Requirements
Once the requirement analysis is done, the next stage is to certainly represent and
document the software requirements and get them accepted from the project
stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document

which contains all the product requirements to be constructed and developed during
the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis,
and design of the software project. This phase is the product of the last two, like inputs
from the customer and requirement gathering.
Stage4: Developing the project
In this phase of SDLC, the actual development begins, and the programming is built.
The implementation of design begins concerning writing code. Developers have to
follow the coding guidelines described by their management and programming tools
like compilers, interpreters, debuggers, etc. are used to develop and implement the
code.
Stage 5: Testing
After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements
stage. During this stage, unit testing, integration testing, system testing, acceptance
testing are done.
Stage 6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is deployed.
Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment. After the software is deployed, then its
maintenance begins.
Stage 7: Maintenance
Once when the client starts using the developed systems, then the real issues come up
and requirements to be solved from time to time. This procedure where the care is
taken for the developed product is known as maintenance.

Page | 21
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages
as well as some disadvantages. A few important and commonly used life cycle models
are as follows:

• Classical Waterfall Model

• Iterative Waterfall Model

• Prototyping Model
• Evolutionary Model
• Spiral Model
1. CLASSICAL WATERFALL MODEL
The classical waterfall model is intuitively the most obvious way to develop software.
Though the classical waterfall model is elegant and intuitively obvious, it is not a
practical model in the sense that it cannot be used in actual software development
projects. Thus, this model can be considered to be a theoretical way of developing
software. But all other life cycle models are essentially derived from the classical
waterfall model. So, in order to be able to appreciate other life cycle models it is
necessary to learn the classical waterfall model. Classical waterfall model divides the
life cycle into the following phases as shown in fig.2.1:

Page | 22
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Fig 2.1: Classical Waterfall Model

Feasibility study - The main aim of feasibility study is to determine whether it would
be financially and technically feasible to develop the product.

• At first project managers or team leaders try to have a rough understanding

of what is required to be done by visiting the client side. They study different input
data to the system and output data to be produced by the system. They study what
kind of processing is needed to be done on these data and they look at the various
constraints on the behavior of the system.

• After they have an overall understanding of the problem they investigate the
different solutions that are possible. Then they examine each of the solutions in terms
of what kind of resources required, what would be the cost of development and what
would be the development time for each solution.

• Based on this analysis they pick the best solution and determine whether the
solution is feasible financially and technically. They check whether the customer
budget would meet the cost of the product and whether they have sufficient technical
expertise in the area of development.

Requirements analysis and specification: - The aim of the requirements analysis and
specification phase is to understand the exact requirements of the customer and to
document them properly. This phase consists of two distinct activities, namely

• Requirements gathering and analysis

• Requirements specification

The goal of the requirements gathering activity is to collect all relevant information
from the customer regarding the product to be developed. This is done to clearly
understand the customer requirements so that incompleteness and inconsistencies are
removed.

The requirements analysis activity is begun by collecting all relevant data regarding
the product to be developed from the users of the product and from the customer
through interviews and discussions. For example, to perform the requirements
analysis of a business accounting software required by an organization, the analyst
might interview all the accountants of the organization to ascertain their requirements.
The data collected from such a group of users usually contain several contradictions
and ambiguities, since each user typically has only a partial and incomplete view of

Page | 23
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

the system. Therefore it is necessary to identify all ambiguities and contradictions in

the requirements and resolve them through further discussions with the customer.
After all ambiguities, inconsistencies, and incompleteness have been resolved and all
the requirements properly understood, the requirements specification activity can
start. During this activity, the user requirements are systematically organized into a
Software Requirements Specification (SRS) document. The customer requirements
identified during the requirements gathering and analysis activity are organized into
a SRS document. The important components of this document are functional
requirements, the nonfunctional requirements, and the goals of implementation.

Design: - The goal of the design phase is to transform the requirements specified in
the SRS document into a structure that is suitable for implementation in some
programming language. In technical terms, during the design phase the software
architecture is derived from the SRS document. Two distinctly different approaches
are available: the traditional design approach and the object-oriented design
approach.

• Traditional design approach -Traditional design consists of two different

activities; first a structured analysis of the requirements specification is carried out
where the detailed structure of the problem is examined. This is followed by a
structured design activity. During structured design, the results of structured analysis
are transformed into the software design.

• Object-oriented design approach -In this technique, various objects that occur
in the problem domain and the solution domain are first identified, and the different
relationships that exist among these objects are identified. The object structure is
further refined to obtain the detailed design.

Coding and unit testing:-The purpose of the coding phase (sometimes called the
implementation phase) of software development is to translate the software design
into source code. Each component of the design is implemented as a program module.
The end-product of this phase is a set of program modules that have been individually
tested. During this phase, each module is unit tested to determine the correct working
of all the individual modules. It involves testing each module in isolation as this is the
most efficient way to debug the errors identified at this stage.

Integration and system testing: -Integration of different modules is undertaken once

they have been coded and unit tested. During the integration and system testing
phase, the modules are integrated in a planned manner. The different modules
making up a software product are almost never integrated in one shot. Integration is
normally carried out incrementally over a number of steps. During each integration
step, the partially integrated system is tested and a set of previously planned modules
are added to it. Finally, when all the modules have been successfully integrated and
tested, system testing is carried out. The goal of system testing is to ensure that the

Page | 24
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

developed system conforms to its requirements laid out in the SRS document. System
testing usually consists of three different kinds of testing activities:

• α – testing: It is the system testing performed by the development team.

• β –testing: It is the system testing performed by a friendly set of customers.

• Acceptance testing: It is the system testing performed by the customer himself

after the product delivery to determine whether to accept or reject the delivered
product.

System testing is normally carried out in a planned manner according to the system
test plan document. The system test plan identifies all testing-related activities that
must be performed, specifies the schedule of testing, and allocates resources. It also
lists all the test cases and the expected outputs for each test case.

Maintenance: -Maintenance of a typical software product requires much more than

the effort necessary to develop the product itself. Many studies carried out in the past
confirm this and indicate that the relative effort of development of a typical software
product to its maintenance effort is roughly in the 40:60 ratios. Maintenance involves
performing any one or more of the following three kinds of activities:

• Correcting errors that were not discovered during the product development
phase. This is called corrective maintenance.

• Improving the implementation of the system, and enhancing the

functionalities of the system according to the customer’s requirements. This is called
perfective maintenance.

• Porting the software to work in a new environment. For example, porting may
be required to get the software to work on a new computer platform or with a new
operating system. This is called adaptive maintenance.

Shortcomings of the classical waterfall model

The classical waterfall model is an idealistic one since it assumes that no development
error is ever committed by the engineers during any of the life cycle phases. However,
in practical development environments, the engineers do commit a large number of
errors in almost every phase of the life cycle. The source of the defects can be many:
oversight, wrong assumptions, use of inappropriate technology, communication gap
among the project engineers, etc. These defects usually get detected much later in the
life cycle. For example, a design defect might go unnoticed till we reach the coding or
testing phase. Once a defect is detected, the engineers need to go back to the phase
where the defect had occurred and redo some of the work done during that phase and
the subsequent phases to correct the defect and its effect on the later phases. Therefore,

Page | 25
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

in any practical software development work, it is not possible to strictly follow the
classical waterfall model.
2. ITERATIVE WATERFALL MODEL
To overcome the major shortcomings of the classical waterfall model, we come up
with the iterative waterfall model.

Fig 3.1 : Iterative Waterfall Model

Here, we provide feedback paths for error correction as & when detected later in a
phase. Though errors are inevitable, but it is desirable to detect them in the same
phase in which they occur. If so, this can reduce the effort to correct the bug.

The advantage of this model is that there is a working model of the system at a very
early stage of development which makes it easier to find functional or design flaws.
Finding issues at an early stage of development enables to take corrective measures in
a limited budget.

The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software
system into further small serviceable increments/modules.

3. PRTOTYPING MODEL

Page | 26
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Prototype
A prototype is a toy implementation of the system. A prototype usually exhibits
limited functional capabilities, low reliability, and inefficient performance compared
to the actual software. A prototype is usually built using several shortcuts. The
shortcuts might involve using inefficient, inaccurate, or dummy functions. The
shortcut implementation of a function, for example, may produce the desired results
by using a table look-up instead of performing the actual computations. A prototype
usually turns out to be a very crude version of the actual system.
Need for a prototype in software development
There are several uses of a prototype. An important purpose is to illustrate the input
data formats, messages, reports, and the interactive dialogues to the customer. This is
a valuable mechanism for gaining better understanding of the customer’s needs:

• how the screens might look like

• how the user interface would behave

• how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect
product in the first attempt. Many researchers and engineers advocate that if you want
to develop a good product you must plan to throw away the first version. The
experience gained in developing the prototype can be used to develop the final
product.

A prototyping model can be used when technical solutions are unclear to the
development team. A developed prototype can help engineers to critically examine
the technical issues associated with the product development. Often, major design
decisions depend on issues like the response time of a hardware controller, or the
efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the
best or the only way to resolve the technical issues.

A prototype of the actual product is preferred in situations such as:

• User requirements are not complete

• Technical issues are not clear

Page | 27
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Fig 3.2: Prototype Model

4. EVOLUTIONARY MODEL
It is also called successive versions model or incremental model. At first, a simple
working model is built. Subsequently it undergoes functional improvements & we
keep on adding new functions till the desired system is built.
Applications:
• Large projects where you can easily find modules for incremental
implementation. Often used when the customer wants to start using the core features
rather than waiting for the full software.

• Also used in object oriented software development because the system can be
easily portioned into units in terms of objects.

Advantages:

• User gets a chance to experiment partially developed system

• Reduce the error because the core modules get tested thoroughly.
Disadvantages:

• It is difficult to divide the problem into several versions that would be

acceptable to the customer which can be incrementally implemented & delivered.

Page | 28
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Fig 3.3: Evolutionary Model

5. SPIRAL MODEL
The Spiral model of software development is shown in fig. 4.1. The diagrammatic
representation of this model appears like a spiral with many loops. The exact number
of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the
software process. For example, the innermost loop might be concerned with feasibility
study, the next loop with requirements specification, the next one with design, and so
on. Each phase in this model is split into four sectors (or quadrants) as shown in fig.
4.1. The following activities are carried out during each phase of a spiral model.

Page | 29
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

Fig 4.1: Spiral Model

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.

• Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.

• Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.
Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving the identified
risks.
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and plan the next iteration
around the spiral.

Page | 30
 Software System & Design Unit - I Semester I B. Tech (CSE) 2028

• Progressively more complete version of the software gets built with each
iteration around the spiral.
Circumstances to use spiral model
The spiral model is called a meta model since it encompasses all other life cycle
models. Risk handling is inherently built into this model. The spiral model is suitable
for development of technically challenging software products that are prone to several
kinds of risks. However, this model is much more complex than the other models –
this is probably a factor deterring its use in ordinary projects.
Comparison of different life-cycle models
The classical waterfall model can be considered as the basic model and all other life
cycle models as embellishments of this model. However, the classical waterfall model
cannot be used in practical development projects, since this model supports no
mechanism to handle the errors committed during any of the phases.

This problem is overcome in the iterative waterfall model. The iterative waterfall
model is probably the most widely used software development model evolved so far.
This model is simple to understand and use. However, this model is suitable only for
well-understood problems; it is not suitable for very large projects and for projects
that are subject to many risks.

The prototyping model is suitable for projects for which either the user requirements
or the underlying technical aspects are not well understood. This model is especially
popular for development of the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed
into a set of modules for incremental development and delivery. This model is also
widely used for object- oriented development projects. Of course, this model can only
be used if the incremental delivery of the system is acceptable to the customer.

The spiral model is called a meta model since it encompasses all other life cycle
models. Risk handling is inherently built into this model. The spiral model is suitable
for development of technically challenging software products that are prone to several
kinds of risks. However, this model is much more complex than the other models –
this is probably a factor deterring its use in ordinary projects.

The different software life cycle models can be compared from the viewpoint of the
customer. Initially, customer confidence in the development team is usually high
irrespective of the development model followed. During the lengthy development
process, customer confidence normally drops off, as no working product is
immediately visible. Developers answer customer queries using technical slang, and
delays are announced. This gives rise to customer resentment. On the other hand, an
evolutionary approach lets the customer experiment with a working product much
earlier than the monolithic approaches. Another important advantage of the
incremental model is that it reduces the customer’s trauma of getting used to an

Page | 31