Software Design – UNIT III

Design Concepts:
Software Design is the process of transforming user requirements into
a suitable form, which helps the programmer in software coding and
implementation.
During the software design phase, the design document is produced,
based on the customer requirements as documented in the SRS
document.

S.K
The software design concept simply means the idea or principle
behind the design.
It describes how you plan to solve the problem of designing software,
the logic, or thinking behind how you will design software.
The software design concept provides a supporting and essential
structure or model for developing the right software.
There are many concepts of software design and some of them are
given below:

S.K
S.K
Abstraction
• Hide irrelevant Data
• Reduce complexity and increases efficiency or quality.
• Here, there are two common abstraction mechanisms
1. Functional Abstraction
2. Data Abstraction
Functional Abstraction
• A module is specified by the method it performs.
• The details of the algorithm to accomplish the functions are not visible to
the user of the function.
Data Abstraction
• Details of the data elements are not visible to the users of data.

S.K
Modularity
• Subdivide the system
• It dividing the system or project into smaller parts
• It reduce the complexity of the system or project.

S.K
• The desirable properties of a modular system are:
• Each module is a well-defined system that can be used with other
applications.
• Each module has single specified objectives.
• Modules can be separately compiled and saved in the library.
• Modules should be easier to use than to build.
• Modules are simpler from outside than inside.

S.K
Advantages of Modularity
• It allows large programs to be written by several or different people
• It encourages the creation of commonly used routines to be placed in
the library and used by other programs.
• It provides more checkpoints to measure progress.
• It provides a framework for complete testing, more accessible to test
• It produced the well designed and more readable program.

S.K
Disadvantages of Modularity
• Execution time maybe, but not certainly, longer
• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines
must be written, and more documentation has to be done

S.K
Basic design principles
• There are several principles that are used to organize and arrange the
structural components of Software design.
• Software Designs in which these principles are applied affect the
content and the working process of the software from the
beginning.

S.K
S.K
• Should not suffer from “Tunnel Vision” – While designing the
process, it should not suffer from “tunnel vision” which means that is
should not only focus on completing or achieving the aim but on
other effects also.
• Traceable to analysis model – The design process should be traceable
to the analysis model which means it should satisfy all the
requirements that software requires to develop a high-quality
product.

S.K
• Should not “Reinvent The Wheel” – The design process should not
reinvent the wheel that means it should not waste time or effort in
creating things that already exist. Due to this, the overall
development will get increased.
• Minimize Intellectual distance – The design process should reduce
the gap between real-world problems and software solutions for
that problem meaning it should simply minimize intellectual distance.

S.K
• Exhibit uniformity and integration – The design should display
uniformity which means it should be uniform throughout the process
without any change. Integration means it should mix or combine all
parts of software i.e. subsystems into one system.
•

S.K
• Accommodate change – The software should be designed in such a
way that it accommodates the change implying that the software
should adjust to the change that is required to be done as per the
user’s need.

S.K
• Degrade gently – The software should be designed in such a way that
it degrades gracefully which means it should work properly even if
an error occurs during the execution.
• Assessed or quality – The design should be assessed or evaluated for
the quality meaning that during the evaluation, the quality of the
design needs to be checked and focused on.
•

S.K
Component – level Design Principles
• The component-level design can be represented by using different
approaches.
• One approach is to use a programming language while other is to use
some intermediate design notation such as graphical (DFD,
flowchart, or structure chart), tabular (decision table), or text-based
(program design language) whichever is easier to be translated into
source code.

S.K
• The component-level design provides a way to determine whether
the defined algorithms, data structures, and interfaces will work
properly.
• Note that a component (also known as module) can be defined as a
modular building block for the software.
• However, the meaning of component differs according to how
software engineers use it. The modular design of the software should
exhibit the following sets of properties.

S.K
1. Provide simple interface: Simple interfaces decrease the number of
interactions. Note that the number of interactions is taken into account
while determining whether the software performs the desired
function.
It not only decreases the time involved in design, coding, and testing
but the overall software development cost is also liquidated gradually
with several projects.

S.K
2. Ensure information hiding: The benefits of modularity cannot be
achieved merely by decomposing a program into several modules;
rather each module should be designed and developed in such a way
that the information hiding is ensured.
The concept of information hiding helps in reducing the cost of
subsequent design changes.

S.K
Characteristics of Components
• Reusability − Components are usually designed to be reused in
different situations in different applications. However, some
components may be designed for a specific task.
• Replaceable − Components may be freely substituted with other
similar components.
• Not context specific − Components are designed to operate in
different environments and contexts.

S.K
• Extensible − A component can be extended from existing components
to provide new behavior.
• Encapsulated − A A component depicts the interfaces, which allow
the caller to use its functionality, and do not expose details of the
internal processes or any internal variables or state.
• Independent − Components are designed to have minimal
dependencies on other components.

S.K
Cohesion
• Coupling and Cohesion are two key concepts in software engineering
that are used to measure the quality of a software system’s design.
• Cohesion refers to the degree to which elements within a module
work together to fulfill a single, well-defined purpose.
• High cohesion means that elements are closely related and focused
on a single purpose, while low cohesion means that elements are
loosely related and serve multiple purposes.

S.K
A good software design will have high cohesion.

S.K
S.K
Types of Cohesion
• Functional Cohesion: Functional Cohesion is said to exist if the
different elements of a module, cooperate to achieve a single
function.
• Sequential Cohesion: 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.
• Communicational Cohesion: 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.

S.K
• Procedural Cohesion: 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.
• Temporal Cohesion: When a module includes functions that are associated by
the fact that all the methods must be executed in the same time, the module is
said to exhibit temporal cohesion.
• Logical Cohesion: 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.
• Coincidental Cohesion: 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.
•

S.K
Coupling
• 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

S.K
S.K
• 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.

S.K
Types of Coupling

S.K
• 1. No Direct Coupling : There is no direct coupling between M1 and
M2. In this case, modules are subordinates to different modules.
Therefore, no direct coupling.

S.K
• 2. Data Coupling: When data of one module is passed to another
module, this is called data coupling.

S.K
• 3. Stamp Coupling: 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.

S.K
4. Control Coupling: Control Coupling exists among two modules if
data from one module is used to direct the structure of instruction
execution in another.
5. External Coupling: External Coupling arises when two modules share
an externally imposed data format, communication protocols, or
device interface. This is related to communication to external tools and
devices.
6. Common Coupling: Two modules are common coupled if they share
information through some global data items.

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

S.K
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 between Cohesion shows the relationship within the
modules. module.
Coupling shows the Cohesion shows the module's
relative independence between the relative functional strength.
modules.

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

In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.

S.K
Designing Conventional Components-
Graphical Design Notation
• There are two graphical design notations to be used flow chart and
box diagram that readily depict procedural details.
• If graphical tools are misused, the wrong picture may lead to the
wrong software.
• The flowchart is the most widely used graphical representation for
procedural design.

S.K
• The flowchart is quite simple pictorial. A box used to indicate a
processing step. A diamond represents a logical condition and
arrows show the flow of control.

S.K
S.K
Tabular Design Notation
• Decision tables provide a notation that translates action and
conditions (described in a processing narrative ) into a tabular form.
• The table is difficult to misinterpret and may even be used as a
machine readable input to a table driven algorithm

S.K
S.K
• Here, the double lines divide the table into four sections.
• The upper left hand section contains a list of all conditions whereas
lower left hand section contains list of all possible actions on
combinations of conditions.
• The right hand sections form a matrix to indicate condition
combination and the corresponding actions that will occur for a
specific combination.
• Therefore each column of the matrix may be interpreted as
processing rule.

S.K
The followings steps are applied to develop a decision table:
1. List all action that can be associated with a specific procedure ( or
Module) .
2. List all conditions ( or decision made ) during execution of
the procedure.
3.Associate specific sets of conditions with specific actions
eliminating impossible combinations of conditions
alternatively develop every possible permutation of conditions.
4. Define rules by indicating what actions occur for a set of
conditions.

S.K
Program Design Language
• Program Design Language (or PDL, for short) is a method for
designing and documenting methods and procedures in software.
• It is related to pseudocode, but unlike pseudocode, it is written in
plain language without any terms that could suggest the use of any
programming language or library.

S.K
• Use PDL to create specifications within the Detailed Programming
Facility that causes specialized source code to generate.
• Use PDL for calculations or comparisons. When the program
generates, the program generator converts the code into RPG source
code.

S.K
PDL checks variable definitions as follows:
• Checks the variable to see if it is a keyword
• Checks for the variable in the RPG program(high-level programming
language for business applications)
• If not in the program, checks to see if it exists in the Data Dictionary
Repository
• If not in the Data Dictionary Repository, the user must define the variable

S.K
The PDL uses:
• Data Item Formula Revisions screen
• PDL Statements
• Blocks of Statements
• Comments
• Assignments
• Database Operations
• Calls
• Loops
• Conditions

S.K
Comparison of notion in software engineering

S.K
Unit – IV Risk Management
Reactive and Proactive risks
What Is Risk Management?
When developing a risk management program, a company typically
goes through the following step. Those steps begin with a strategic
planning exercise with senior management, and conclude with a
business continuity plan.

S.K
• Risk Identification
• The first step is to identify the risks that might threaten your business
model or business continuity.
• Operational risk
• Financial risk
• Reputational risk
• Compliance, legal, or regulatory risk

S.K
Reactive risk management could mean the following:
• Preventing potential risks from becoming incidents
• Mitigating damage from incidents
• Stopping small threats from worsening
• Continuing critical business functions despite incidents
• Evaluating each incident to solve its root cause
• Monitoring to assure that the incident does not recur

S.K
Proactive risk management strategies include:
• Identifying existing risks to the enterprise, business unit, or project
• Developing a risk response
• Prioritizing identified risks according to the magnitude of their threat
• Analyzing risks to determine the best treatment for each
• Implementing controls necessary to prevent hazards from becoming
threats or incidents
• Monitoring the threat environment continuously

S.K
Software risks
• Software development risks are factors that can affect the success of
a software development project.
• Potential software development risks can occur both internally and
externally.

S.K
There are a variety of internal and external risks in software
development.
1. Code issues
One significant risk involved with software development is poor quality
code. Projects may contain poor quality code because of rushed work
and many other factors.
Issues with code may include bugs, logical errors and more.

S.K
2. Aggressive deadlines
Sometimes, software development projects have tight deadlines.
In some cases, software development teams may be unable to meet
these deadlines.
You can mitigate this risk by creating a thorough project plan that
allows you to set realistic deadlines.

S.K
3. Unmet expectations
Another risk involved with software development is inaccurate
estimations that lead to unmet expectations.
Often, software development projects require estimations, and
estimations can sometimes be inaccurate.
Inaccurate estimations of costs, deadlines and outcomes can cause
software development projects to not meet the expectations of
customers.

S.K
4. Low productivity
Productivity issues can also be risks in software development.
Sometimes, software development teams may struggle with
productivity, which can happen because of delays, employee burnout
and many other factors.

S.K
5. Budget issues
• Software development budgets can change as project scopes change,
but it's important to monitor projects so that they don't go over
budget.
• Be sure to adjust your project plan and budget whenever changes are
made to avoid raising project costs.

S.K
6. Poor risk management
• Poor risk management can be a risk itself. Good risk management is
essential for software development teams to spot risks and effectively
respond to them. You can improve your risk management by:
• Identifying potential risks
• Calculating the likelihood of each risk
• Creating risk mitigation plans
• Carefully monitoring risks

S.K
Risk identification
Risk Identification:
The project organizer needs to anticipate the risk in the project as early
as possible so that the impact of risk can be reduced by making
effective risk management planning.
A project can be of use by a large variety of risk. To identify the
significant risk, this might affect a project.
It is necessary to categories into the different risk of classes.

S.K
There are different types of risks which can affect a software project:
• 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.

S.K
• 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

S.K
Risk projection
Risk projection, also called risk estimation, attempts to rate each risk in two
ways—
The likelihood or probability that the risk is real and the consequences of the
problems associated with the risk, should it occur.
The project planner, along with other managers and technical staff,
performs four risk projection activities:
(1) establish a scale that reflects the perceived likelihood of a risk,
(2) define the consequences of the risk,
(3) estimate the impact of the risk on the project and the product, and (
(4) note the overall accuracy of the risk projection so that there will be no
misunderstandings.
S.K
• Developing a Risk Table
• A risk table provides a project manager with a simple technique for
risk projection
• A project team begins by listing all risks (no matter how remote) in
the first column of the table.
• This can be accomplished with the help of the risk item checklists
• Each risk is categorized in the second column

S.K
• The probability of occurrence of each risk is entered in the next
column of the table.
• The probability value for each risk can be estimated by team
members individually.
• Individual team members are polled in round-robin fashion until their
assessment of risk probability begins to converge.
• PS- project Size BU Business risk

S.K
S.K
Risk Refinement
• One way to do this is to represent the risk in condition-transition-
consequence (CTC) format .
• That is, the risk is stated in the following form: Given that
<condition> then there is concern that (possibly) <consequence>.
• Using the CTC format for the reuse risk

S.K
• All reusable software components must conform to specific design
standards and that some do not conform, then there is concern that
(possibly) only 70 percent of the planned reusable modules may
actually be integrated into the as-built system, resulting in the need
to custom engineer the remaining 30 percent of components.

S.K
• This general condition can be refined in the following manner:
• Subcondition 1. Certain reusable components were developed by a
third party with no knowledge of internal design standards.
• Subcondition 2. The design standard for component interfaces has
not been solidified and may not conform to certain existing reusable
components.

S.K
• Subcondition 3. Certain reusable components have been
implemented in a language that is not supported on the target
environment.
• The consequences associated with these refined sub conditions
remains the same (i.e., 30 percent of software components must be
customer engineered), but the refinement helps to isolate the
underlying risks and might lead to easier analysis and response.

S.K
Risk Mitigation, monitoring and management
• To mitigate this risk, project management must develop a strategy for
reducing turnover.
The possible steps to be taken are:
• Meet the current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market).
• Mitigate those causes that are under our control before the project
starts.

S.K
• Once the project commences, assume turnover will occur and
develop techniques to ensure continuity when people leave.
• Organize project teams so that information about each development
activity is widely dispersed.
• Define documentation standards and establish mechanisms to ensure
that documents are developed in a timely manner.
• Assign a backup staff member for every critical technologist.

S.K
• There are five general steps in the design process of a risk mitigation
plan:
1. Identify all possible events in which risk is presented.
2. Perform a risk assessment.
3. Prioritize risks.
4. Track risks.
5. Implement and monitor progress.

S.K
Risk mitigation best practices
1. Make sure stakeholders are involved at each step.
2. Create a strong culture around risk management
3. Communicate risks as they arise.
4. Ensure risk management policy is clear. (employee follows rules and
regulations)
5. Continuously monitor possible risks.

S.K
The RMMM plan
Risk Mitigation, Monitoring, and Management (RMMM) plan

• A risk management technique is usually seen in the software Project

plan.
• This can be divided into Risk Mitigation, Monitoring, and
Management Plan (RMMM). In this plan, all works are done as part of
risk analysis.
• As part of the overall project plan project manager generally uses
this RMMM plan.

S.K
• Risk is documented with the help of a Risk Information Sheet (RIS).
• This RIS is controlled by using a database system for easier
management of information i.e creation, priority ordering,
searching, and other analysis.
• After documentation of RMMM and start of a project, risk mitigation
and monitoring steps will start.

S.K
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
• Finding out the risk.
• Removing causes that are the reason for risk creation.
• Controlling the corresponding documents from time to time.
• Conducting timely reviews to speed up the work.

S.K
• Risk Monitoring :
It is an activity used for project tracking. It has the following primary
objectives as follows.
• To check if predicted risks occur or not.
• To ensure proper application of risk aversion steps defined for risk.
• To collect data for future risk analysis.
• To allocate what problems are caused by which risks throughout the
project.

S.K
• Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality.
• This task is done by Project manager when risk becomes reality and
causes severe problems.
• If the project manager effectively uses project mitigation to remove
risks successfully then it is easier to manage the risks.

S.K
• This shows that the response that will be taken for each risk by a
manager.
• The main objective of the risk management plan is the risk register.
• This risk register describes and focuses on the predicted threats to a
software project.

S.K
• Drawbacks of RMMM:
• It incurs additional project costs.
• It takes additional time.
• For larger projects, implementing an RMMM may itself turn out to be
another tedious project.
• RMMM does not guarantee a risk-free project, in fact, risks may also
come up after the project is delivered.

S.K