Unit 2

Design process and concepts

Software Design
• Software design is a process to transform user requirements into
some suitable form, which helps the programmer in software coding
and implementation.
• Software design is the step in SDLC (Software Design Life Cycle),
which moves the concentration from problem domain to solution
domain.
• It main purpose is to specify how to fulfill the requirements
mentioned in SRS.

CHARACTERISTICS OF GOOD SOFTWARE DESIGN

• Correctness: Software design should be correct as per requirement.
• Completeness: The design should have all components like data
structures, modules, and external interfaces, etc.
• Efficiency: Resources should be used efficiently by the program.
• Flexibility: Able to modify on changing needs.
• Consistency: There should not be any inconsistency in the design.
• Maintainability: The design should be so simple so that it can be
easily maintainable by other designers.
Software Design Process
• The design phase of software development deals with transforming
the customer requirements as described in the SRS documents into a
form implementable using a programming language.
• The software design process can be divided into the following three
levels of phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design

1. Interface Design
• Interface design is the specification of the interaction between a
system and its environment.
• This phase proceeds at a high level of abstraction with respect to the
inner workings of the system i.e, during interface design, the internal
of the systems are completely ignored and the system is treated as a
black box.
• In this design, attention is focused on the dialogue between the target
system and the users, devices, and other systems with which it
interacts.
2. Architectural Design
• Architectural design is the specification of the major components of a
system, their responsibilities, properties, interfaces, and the
relationships and interactions between them.
• In architectural design, the overall structure of the system is chosen,
but the internal details of major components are ignored.

3. Detailed Design
• Design is the specification of the internal elements of all major
system components, their properties, relationships, processing, and
often their algorithms and the data structures.
In summary:
 Interface Design: Focuses on external interactions.
 Architectural Design: Focuses on the overall system structure.
 Detailed Design: Focuses on the internal workings of components.

Software Design Process

Elements of a System
1. Architecture: This is the conceptual model that defines the structure,
behavior, and views of a system.
2. Modules: These are components that handle one specific task in a
system. A combination of the modules makes up the system.
3. Components: This provides a particular function or group of related
functions. They are made up of modules.
4. Interfaces: This is the shared boundary across which the components of
a system exchange information and relate.
5. Data: This is the management of the information and data flow.
Modularization
 Modularization is a technique to divide a software system into
multiple discrete and independent modules, which are expected to be
capable of carrying out task(s) independently.
• Effective modular design can be achieved if the partitioned modules
are separately solvable, modifiable as well as compilable.
• Here separate compilable modules means that after making changes
in a module there is no need of recompiling the whole software
system.
Advantage of modularization
• Smaller components are easier to maintain
• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the program
• Components with high cohesion can be re-used again
• Concurrent execution can be made possible

Software Design Concepts

1. Abstraction (Hide Irrelevant data): Abstraction simply means to hide
the details to reduce complexity and increase efficiency or quality.
2. Modularity (subdivide the system): Modularity simply means
dividing the system or project into smaller parts to reduce the
complexity of the system or project. In the same way, modularity in
design means subdividing a system into smaller parts so that these
parts can be created independently and then use these parts in
different systems to perform different functions.
3. Architecture (design a structure of something): Architecture simply
means a technique to design a structure of something. Architecture in
designing software is a concept that focuses on various elements and
the data of the structure.
4. Refinement (removes impurities): Refinement simply means to refine
something to remove any impurities if present and increase the
quality. It is very necessary to find out any error if present and then
to reduce it.
 5. Pattern (a Repeated form): A pattern simply means a repeated form
or design in which the same shape is repeated several times to form a
pattern. The pattern in the design process means the repetition of a
solution to a common recurring problem within a certain context.
6. Refactoring (Reconstruct something): Refactoring in software design
means reconstructing the design to reduce complexity and simplify it
without impacting the behavior or its functions.

Effective Modular Design

In order to build a software with effective modular design there is a
factor “Functional Independence” which comes into play. The meaning of
Functional Independence is that a function is atomic in nature so that it
performs only a single task of the software without or with least interaction
with other modules. Functional Independence is considered as a sign of
growth in modularity i.e., presence of larger functional independence
results in a software system of good design and design further affects the
quality of the software.
A good software design should have high cohesion and low coupling.

Cohesion is a measure of strength in relationship between various functions

within a module. It is of 7 types which are listed below in the order of high
to low cohesion:
1. Functional cohesion
2. Sequential cohesion
3. Communicational cohesion
4. Procedural cohesion
5. Temporal cohesion
6. Logical cohesion
7. Co-incidental cohesion
Coupling:
Coupling is a measure of strength in relationship between various modules
within a software. It is of 6 types which are listed below in the order of low
to high coupling:
1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4. External Coupling
5. Common Coupling
6. Content Coupling
Concurrency
• Back in time, all software are meant to be executed sequentially.
• By sequential execution we mean that the coded instruction will be
executed one after another implying only one portion of program
being activated at any given time.
• A software has multiple modules, then only one of all the modules can
be found active at any time of execution.
• In software design, concurrency is implemented by splitting the
software into multiple independent units of execution, like modules
and executing them in parallel.
• In other words, concurrency provides capability to the software to
execute more than one part of code in parallel to each other.
• It is necessary for the programmers and designers to recognize those
modules, which can be made parallel execution.
Design Verification
• It is then becomes necessary to verify the output before proceeding to
the next phase.
• The early any mistake is detected, the better it is or it might not be
detected until testing of the product.
• If the outputs of design phase are in formal notation form, then their
associated tools for verification should be used otherwise a thorough
design review can be used for verification and validation.
• By structured verification approach, reviewers can detect defects that
might be caused by overlooking some conditions. A good design review is
important for good software design, accuracy and quality.
Design Model
It is representation or blueprint that outlines the specifications, structure,
components, and relationships of the final product or system to be
developed. It serves as a guide for builders, engineers, and designers to
follow during the creation process.
Role and Purpose of Design Models
 Visualization: It Provide a visual representation of a system or
product that is yet to be built, allowing stakeholders to understand
and discuss its structure and functionality.
 Communication: It acts as a communication tool among various
stakeholders (designers, developers, clients, etc.) to ensure a common
understanding and alignment with the project's objectives.
 Decision Making: It allows stakeholders to explore different designs
and assess their feasibility, cost, and impact before implementation.
 Documentation: It acts as a form of documentation that details the
specifications and design choices for future reference and
maintenance.
Types of Design Models
 Conceptual Model - It is also known as high-level and abstract model
and provides overall vision of system or project without going into
 deeper details. It is used in early stages os design to have better
understanding.
 Logical Model – It focus on the functional requirements and the
logical structure of the system without specifying the physical
components. It include data models.
 Physical Models: It specifies the physical state of the system, like
dimensions, and configurations. It refers to the detailed hardware
requirements.
 Mathematical Models: It use mathematical equations to represent the
behavior of a system under various conditions.
Process of Developing a Design Model
 Requirements Gathering: Collecting and analyzing the needs and
constraints from stakeholders to understand the objectives of the
project.
 Conceptualization: Creating basic ideas and rough plans to capture
the overall vision of the project.
 Refinement: Refinement simply means to refine something to remove
any impurities if present and increase the quality. It is very necessary
to find out any error if present and then to reduce it.
 Validation: Validating the design model against requirements and
constraints, often involving stakeholders' feedback and possibly
prototyping or simulation.
 Finalization: Completing the design with all necessary details, ready
for implementation or construction.

System Design Strategy

Software design is the process of turning software requirements into
software implementation. It starts with understanding what users need
and then figuring out the best way to create software that meets those
needs. During this process, a plan is made to find the best possible design to
build the software.
There are multiple variants of software design. Let us study them briefly:
Structured Design
It is 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.
It gives better understanding of how the problem is being solved.
A good structured design always follows 2 rules for communication among
modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.

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.
It inherits some properties of structured design as this also work on ‘divide
and conquer’ strategy.
In this every function is associated with some actions.

Object Oriented Design

This design strategies focuses on entities and its characteristics.
the important concepts of Object Oriented Design:
class, object, abstraction, Encapsulation, inheritance, Polymorphism.
(Define all)

Software Design Approaches

i. Top Down Design
ii. Bottom-up Design
Top Down Design

• 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 is more suitable when the software solution needs to
be designed from scratch and specific details are unknown.

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.

Hybrid Design
It is a combination of both the top – down and bottom – up design
strategies. In this we can reuse the modules.
Software project planning
It is a way of planning and leading software projects. It is a part of project
management in which software projects are planned, implemented,
monitored, and controlled.
Need for Software Project Management
 to deliver quality products.
 keep the cost within the client’s budget constraint.
 deliver the project on time.
Project Estimation Techniques
Estimation determines how much money, effort, resources, and time it will take
to build a specific system or product. Estimation is based on −
• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks
There are two main models -
• Line of Code Estimation is done on behalf of number of line of codes in
the software product.
• Function Points Estimation is done on behalf of number of function
points in the software product.

Function Point Analysis (FPA)

Function Point Calculation
Project Scheduling
• A project schedule is a tool used to communicate what tasks need to be
done, who will do them, and the time frame in which they should be
completed.
• Effective project scheduling leads to project success, reduced costs, and
increased customer satisfaction.
• The most common and important form of project schedule is Gantt chart.
• Resource allocation is usually done using a Gantt chart.
• After resource allocation is completed, a PERT chart representation is
developed.
• The PERT chart representation is useful for program monitoring and
control.
Here are the key steps a software project manager follows:
1. Identify Activities: List all major tasks that need to be completed.
 2. Break Down Tasks: Divide tasks into smaller, manageable steps for
easier execution.
3. Understand Dependencies: Determine which tasks depend on others and
the sequence in which they must be completed.
4. Time Estimates: Estimate the time required for each task.
5. Create Activity Network: Visualize task relationships using an activity
network or flowchart to see how tasks are interconnected.
6. Task Dates: Set start and end dates for each task.
7. Critical Path Analysis: It is a sequence of tasks that determines the
project's overall duration. Tasks on the critical path must be completed on
time to avoid project delays.
8. Allocate Resources to Tasks: It involves assigning the right people,
equipment, and materials to each task to ensure smooth execution.

Advantages of Project Scheduling

• It simply ensures that everyone remains on same page as far as tasks get
completed, dependencies, and deadlines.
• It helps in identifying issues early and concerns such as lack or
unavailability of resources.
• It also helps to identify relationships and to monitor process.
• It provides effective budget management and risk mitigation.
Risk Management
Risk Management is the system of identifying addressing and eliminating
threats or risks before they can damage the project.
There are three main classifications of risks which can affect a software project:
• Project risks
• Technical risks
• Business risks

1. Project risks: Project risks refer to different forms of budgetary, schedule,

personnel, resource, and customer-related problems.
Since the software is intangible, it is very tough to monitor and control a
software project.
2. Business Risk: Building a product that no one wants or loosing budgetary
commitments.
3. Technical Risk: Concerned with quality, design, implementation, interface,
maintenance problems.

Risk Assessment
 It is a process to rank the risks in terms of their damage.
 Determine the average probability of occurrence value for each risk.
(denoted as P)
 Determine the impact for each component based on impact assessment
matrix.(Severity Value)
 Risk Assessment values are determined by multiplying the scores for the
Probability and Severity values together.
RA=P X S

Risk Identification
Risk identification refers to the systematic process of recognizing and
evaluating potential threats or hazards that could negatively impact an
organization, its operations, or its workforce. This involves identifying various
types of risks.
• Technology risks: Risks that assume from the software or hardware
technologies that are used to develop the system.
• People risks: Risks that are connected with the person in the
development team.
• Organizational risks: Risks that assume from the organizational
environment where the software is being developed.
• Tools risks: Risks that assume from the software tools and other support
software used to create the system.
• Requirement risks: Risks that assume from the changes to the customer
requirement and the process of managing the requirements change.
• Estimation risks: Risks that assume from the management estimates of
the resources required to build the system
Risk Analysis
Risk analysis is the process of evaluating and understanding the potential
impact and likelihood of identified risks on an organization. It helps determine
how serious a risk is and how to best manage it.
Risk Control
It is the process of managing risks to achieve desired outcomes. Once the risks
in a plan are identified, the project must prioritize addressing both the most
harmful and the most probable risks.
There are three main methods to plan for risk management:
• Avoid the risk: Risk avoidance can be achieved by discussing with the
client to change the requirements and reduce the project scope and many
other ways.
• Transfer the risk: This method involves getting the risky element
developed by a third party, buying insurance cover, etc.
• Risk reduction: Risk reduction involves planning strategies to minimize
potential losses caused by risks.
Risk Leverage
• Risk leverage is the variation in risk exposure divided by the amount of
reducing the risk.
• Risk leverage = (risk exposure before reduction - risk exposure after
reduction) / (cost of reduction)
1. Risk planning: The risk planning method considers each of the key risks
that have been identified and develop ways to maintain these risks.
2. Risk Monitoring: Risk monitoring is the process of ensuring that your
assumptions about product, process, and business risks remain valid over
time.

COCOMO Model
• Barry Boehm proposed COCOMO (Constructive Cost Estimation Model)
in 1981.
• It is a procedural cost estimate model for software projects and often used
as a process of reliably predicting the various parameters associated with
making a project such as size, effort, cost, time and quality.
• Cocomo (Constructive Cost Model) is a regression model based on LOC,
i.e number of Lines of Code.
The key parameters which define the quality of any software products,
which are also an outcome of the Cocomo are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.
 • Schedule: Simply means the amount of time required for the completion
of the job, which is, of course, proportional to the effort put. It is
measured in the units of time such as weeks, months.
Types of Projects in the COCOMO Model

1. Organic: A software project is said to be an organic type if the team size

required is small, the problem is well understood and has been solved in
the past and the team members have a nominal experience regarding the
problem.
2. Semidetached: Project teams consist of a mixture of experienced and
inexperienced staff. It is of medium size, some innovation is required,
constraints and deadlines are moderate and the development environment
is somewhat fluid.
3. Embedded: the s/w is strongly coupled to complex h/w, such as air
traffic control, ATM's or weapon systems. The project team is large, a
great deal of innovation is required, constraints and deadlines are tight
and the development environment consist of many complex interfaces.
Types of COCOMO model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
1. Basic COCOMO Model
The Basic COCOMO model is a straightforward way to estimate effort and
time required for development based on the size of the project, measured in
Kilo Lines of Code (KLOC).
using the following expression:

E = a*(KLOC)b PM

Tdev = c*(E)d

Person required = Effort/ Time

Where,
E is effort applied in Person-Months
 KLOC is the estimated size of the software product indicate in Kilo Lines
of Code

Tdev is the development time in months

a, b, c are constants determined by the category of software project given in

below table.

2. Intermediate Model
Intermediate Model in which we not need to calculate the time and team size
required for development of the project.
The Intermediate COCOMO formula:

 EAF is the Effort Adjustment Factor (EAF) is a multiplier used to refine the
effort estimate obtained from the basic COCOMO model.

3. Detailed Model
In detailed cocomo, the whole software is divided into different modules and
then we apply COCOMO in different modules to estimate effort and then
sum the effort.
 The Six phases of detailed COCOMO are:
• Planning and requirements
• System design
• Detailed design
• Module code and test
• Integration and test
• Cost Constructive model
Next from ppt 2.2.2

EMPIRICAL ESTIMATION TECHNIQUE

 Empirical estimation techniques are based on making an educated guess of
the project parameters.
 While using this technique, prior experience with development of similar
products is helpful.
 Two popular empirical estimation techniques are: Expert judgment technique
and Delphi cost estimation.
Expert judgment technique
Experts divide a software product into component units:
e.g. GUI, database module, data communication module, billing module, etc.
then add up the guesses for each of the components.
Delphi cost estimation

Software Quality Management

• Software Quality Management is a process that ensures the required level
of software quality is achieved when it reaches the users.
• Quality software refers to a software which is reasonably bug or defect
free, is delivered in time and within the specified budget.

Software Configuration Management

Software Configuration Management (SCM) is defined as a process to
systematically manage, organize, and control the changes in the documents,
codes, and other entities during the Software Development Life Cycle. -> The
primary goal is to increase productivity with minimal mistakes.

Ch -3
 Attractive Design: Visually appealing UI that draws users in and makes
them want to use the software.
 Simplicity: An intuitive, easy-to-navigate design that allows users to
complete tasks without unnecessary complexity.
 Responsiveness: Quick and efficient responses to user inputs, reducing wait
times and enhancing productivity.
 Clarity: Clear and understandable layout, allowing users to find what they
need without confusion or extensive instructions.
 Consistency: Uniform design and layout across all screens, providing a
seamless and familiar experience for users.