UNIT 3

SOFTWARE DESIGN : So ware design is a process to transform user requirements into some suitable
form, which helps the programmer in so ware coding and implementa on. For assessing user
requirements, an SRS (So ware Requirement Specifica on) document is created whereas for coding
and implementa on, there is a need of more specific and detailed requirements in so ware terms.
The output of this process can directly be used into implementa on in programming languages.
So ware design is the first step in SDLC (So ware Design Life Cycle), which moves the concentra on
from problem domain to solu on domain. It tries to specify how to fulfill the requirements
men oned in SRS. So ware Design Levels So ware design yields three levels of results:

 Architectural Design - The architectural design is the highest abstract version of the system. It
iden fies the so ware as a system with many components interac ng with each other. At this level,
the designers get the idea of proposed solu on domain.

 High-level Design- The high-level design breaks the ‘single en ty-mul ple component’ concept of
architectural design into less-abstracted view of sub-systems and modules and depicts their
interac on with each other. High-level design focuses on how the system along with all of its
components can be implemented in forms of modules. It recognizes modular structure of each sub-
system and their rela on and interac on among each other.

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

Design Process

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

 DFD depicts how func ons change the data and state of en re system.

 The en re system is logically broken down into smaller units known as func ons on the basis of
their opera on in the system.

 Each func on is then described at large.

Object Oriented Design

Object oriented design works around the en es and their characteris cs instead of func ons
involved in the so ware system. This design strategy focuses on en es and its characteris cs. The
whole concept of so ware solu on revolves around the engaged en es. Let us see the important
concepts of Object Oriented Design:

 Objects - All en es involved in the solu on design are known as objects. For example, person,
banks, company and customers are treated as objects. Every en ty has some a ributes associated to
it and has some methods to perform on the a ributes.

 Classes - A class is a generalized descrip on of an object. An object is an instance of a class. Class

defines all the a ributes, which an object can have and methods, which defines the func onality of
the object. DEPT OF CSE & IT VSSUT, Burla In the solu on design, a ributes are stored as variables
and func onali es are defined by means of methods or procedures.

 Encapsula on - In OOD, the a ributes (data variables) and methods (opera on on the data) are
bundled together is called encapsula on. Encapsula on not only bundles important informa on of
an object together, but also restricts access of the data and methods from the outside world. This is
called informa on hiding.

 Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or sub-
classes can import, implement and re-use allowed variables and methods from their immediate
super classes. This property of OOD is known as inheritance. This makes it easier to define specific
class and to create generalized classes from specific ones.

 Polymorphism - OOD languages provide a mechanism where methods performing similar tasks but
vary in arguments, can be assigned same name. This is called polymorphism, which allows a single
interface performing tasks for different types. Depending upon how the func on is invoked,
respec ve por on of the code gets executed.

Design Process

So ware design process can be perceived as series of well-defined steps. Though it varies according
to design approach (func on oriented or object oriented, yet It may have the following steps
involved:

 A solu on design is created from requirement or previous used system and/or system sequence
diagram.

 Objects are iden fied and grouped into classes on behalf of similarity in a ribute characteris cs.

 Class hierarchy and rela on among them are defined.

 Applica on framework is defined.

Different between cocomo 1 and cocomo 2

COCOMO 1 and COCOMO 2 are two models used for estimating the effort, cost, and schedule for
software projects.

1. COCOMO 1 is based on the linear reuse formula and the assumption of reasonably stable
needs. In contrast, COCOMO 2 is based on the non-linear reuse formula and provides
auto-calibration characteristics.
2. COCOMO 1 is useful in the waterfall model of the software development cycle (SDLC),
while COCOMO 2 is useful in quick development, non-sequential, and reuses software
models.
3. COCOMO 1 provides estimates of effort and schedule, while COCOMO 2 provides
estimates that represent one standard deviation around the most likely estimate.
4. COCOMO 1 has three submodels and fifteen cost drivers assigned, while COCOMO 2 has
four submodels and seventeen cost drivers assigned.
There are various key differences between COCOMO 1 and COCOMO 2. Some of the
key differences between COCOMO 1 and COCOMO 2 are as follows:

1. COCOMO 1 is very useful in waterfall model of the software development

cycle (SDLC). In contrast, COCOMO 2 is useful in quick development, non-
sequential, and reuses software models.
2. COCOMO 1 is mainly based on the assumption of reasonable stable needs. In
contrast, COCOMO 2 is based on the reuse model, which emphasizes the effort
necessary to understand and estimate.
3. COCOMO 1 offers time estimations and effort. In contrast, COCOMO 2 offers
estimates that are one standard deviation from the most common estimate.
4. COCOMO 1 development begins after the needs are assigned to the software.
In contrast, COCOMO 2 employs the spiral development strategy.
5. The size of the program in COCOMO 1 is indicated in lines of code. In contrast,
COCOMO 2 has extra factors for expressing software size, including lines of
code, object points, and function points.
 6. In COCOMO 1, no scaling factors are employed. In contrast, in COCOMO 2,
scaling factors are utilized to estimate work.
7. COCOMO 1 has 3 submodels (basic, intermediate, and advanced). In contrast,
COCOMO 2 has 4 submodels (application development model, post-
architectural model, early design model, and reuse model).
8. COCOMO 1 makes utilize of 15 cost drivers. In contrast, COCOMO 2 makes
utilize 17 different cost drivers.
9. As compared to the COCOMO 1 model, COCOMO 2 may reduce the amount of
risk.
10. In COCOMO 1, the effort formula's exponent is calculated utilizing three
different development modes. In contrast, in COCOMO 2, the effort formula's
exponent is based on five scale factors.

Risk Management

A so ware project can be affected by a large variety of risks. In order to be able to systema cally
iden fy the important risks which might affect a so ware project, it is necessary to categorize risks
into different classes. The project manager can then examine which risks from each class are relevant
to the project. There are three main categories of risks which can affect a so ware project:

1. Project risks Project risks concern varies forms of budgetary, schedule, personnel, resource, and
customer-related problems. An important project risk is schedule slippage. Since, so ware is
intangible, it is very difficult to monitor and control a so ware project. It is very difficult to control
something which cannot be seen. For any manufacturing project, such as manufacturing of cars, the
project manager can see the product taking shape. He can for instance, see that the engine is fi ed,
a er that the doors are fi ed, the car is ge ng painted, etc. Thus he can easily assess the progress of
the work and control it. The invisibility of the product being developed is an important reason why
many so ware projects suffer from the risk of schedule slippage.

2. Technical risks Technical risks concern poten al design, implementa on, interfacing, tes ng, and
maintenance problems. Technical risks also include ambiguous specifica on, incomplete
specifica on, changing specifica on, technical uncertainty, and technical obsolescence. Most
technical risks occur due to the development team’s insufficient knowledge about the project.

3. Business risks This type of risks include risks of building an excellent product that no one wants,
losing budgetary or personnel commitments, etc.

Risk Assessment

The objec ve of risk assessment is to rank the risks in terms of their damage causing poten al. For
risk assessment, first each risk should be rated in two ways:

• The likelihood of a risk coming true (denoted as r).

• The consequence of the problems associated with that risk (denoted as s)

Based on these two factors, the priority of each risk can be computed:

p=r*s

Where, p is the priority with which the risk must be handled, r is the probability of the risk becoming
true, and s is the severity of damage caused due to the risk becoming true. If all iden fied risks are
priori zed, then the most likely and damaging risks can be handled first and more comprehensive
risk abatement procedures can be designed for these risks.

Risk Containment

A er all the iden fied risks of a project are assessed, plans must be made to contain the most
damaging and the most likely risks. Different risks require different containment procedures. In fact,
most risks require ingenuity on the part of the project manager in tackling the risk. There are three
main strategies to plan for risk containment:

Avoid the risk- This may take several forms such as discussing with the customer to change the
requirements to reduce the scope of the work, giving incen ves to the engineers to avoid the risk of
manpower turnover, etc.

Transfer the risk- This strategy involves ge ng the risky component developed by a third party,
buying insurance cover, etc.

Risk reduc on- This involves planning ways to contain the damage due to a risk. For example, if there
is risk that some key personnel might leave, new recruitment may be planned.

Risk Leverage -To choose between the different strategies of handling a risk, the project manager
must consider the cost of handling the risk and the corresponding reduc on of risk. For this the risk
leverage of the different risks can be computed.

Risk leverage is the difference in risk exposure divided by the cost of reducing the risk. More formally,

risk leverage = (risk exposure before reduc on – risk exposure a er reduc on) / (cost of reduc on)

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.
In some software teams, 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.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

1. To check if predicted risks occur or not.

2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the
project.

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. 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.
Risk Mitigation:
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.
 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.
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project manager
monitors factors that may provide an indication of whether the risk is becoming
more or less likely. In the case of high staff turnover, the following factors can be
monitored:

 General attitude of team members based on project pressures.

 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
Risk Management:
Risk management and contingency planning assumes that mitigation efforts have
failed and that the risk has become a reality. Continuing the example, the project
is well underway, and a number of people announce that they will be leaving. If
the mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team. In addition, the
project manager may temporarily refocus resources (and readjust the project
schedule) to those functions that are fully staffed, enabling newcomers who must
be added to the team to “get up to the speed“.
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, infact, risks may also
come up after the project is delivered.

White box tes ng and black box tes ng are two fundamental approaches to so ware tes ng in
so ware engineering. They are used to ensure the quality and reliability of so ware applica ons by
examining them from different perspec ves. Here's an overview of each:

1. White Box Tes ng:

- White box tes ng is also known as clear-box tes ng, structural tes ng, or glass box tes ng.

- It focuses on examining the internal structure, logic, and code of the so ware.
 - Testers have knowledge of the so ware's internal workings, including the source code and design.

- White box tes ng is typically done by developers or testers who are closely familiar with the
so ware's implementa on.

- It involves tes ng individual func ons, methods, or code segments to ensure they work correctly
and meet design specifica ons.

- Techniques used in white box tes ng include code coverage analysis (e.g., statement coverage,
branch coverage, path coverage), control flow analysis, and data flow analysis.

- The primary goal is to uncover issues such as logical errors, missing func onality, and code
vulnerabili es.

2. Black Box Tes ng:

- Black box tes ng is also known as behavioral tes ng or func onal tes ng.

- It focuses on tes ng the so ware's external behavior and func onality without knowledge of its
internal code and structure.

- Testers approach the so ware as end-users or stakeholders who have no access to the internal
implementa on details.

- Testers create test cases based on specifica ons, requirements, and func onal documenta on.

- Black box tes ng is performed from the user's perspec ve to verify that the so ware func ons as
expected and complies with its requirements.

- Techniques used in black box tes ng include equivalence par oning, boundary value analysis,
use case tes ng, and scenario-based tes ng.

- The primary goal is to iden fy issues such as incorrect func onality, user interface problems, and
devia ons from specified requirements.

Both white box and black box tes ng are essen al in the so ware development process:

- White box tes ng is valuable for uncovering internal flaws and ensuring code quality.

- Black box tes ng is vital for valida ng that the so ware meets user expecta ons and requirements.

In prac ce, a combina on of these tes ng approaches is o en used to achieve comprehensive test
coverage. This is known as gray box tes ng, where testers have par al knowledge of the internal
structure while primarily focusing on the so ware's external behavior. By employing a mix of these
tes ng methods, so ware development teams can increase the likelihood of delivering reliable and
high-quality so ware.
Architectural styles in so ware engineering are design pa erns or frameworks that guide the
organiza on of so ware systems. They provide a structured way to design and build so ware,
helping developers create systems that are modular, maintainable, and scalable. These architectural
styles serve as blueprints for solving recurring design problems. Here are some common architectural
styles:

1. **Client-Server Architecture:**

- In this style, the so ware system is divided into two parts: the client, which is responsible for the
user interface and user interac on, and the server, which handles data storage and processing.

- It allows for scalability and separa on of concerns between the client and server, making it a
common choice for distributed applica ons.

2. **Layered Architecture:**

- In a layered architecture, the so ware system is divided into different layers, each responsible for
a specific set of func onali es.

- Common layers include presenta on, applica on logic, and data storage layers.

- This style promotes modulariza on and separa on of concerns.

3. **Microservices Architecture:**

- Microservices is an architectural style where a so ware system is composed of small,

independently deployable services that communicate with each other through APIs.

- Each microservice focuses on a specific business capability, which allows for flexibility, scalability,
and ease of maintenance.

4. **Monolithic Architecture:**

- In contrast to microservices, monolithic architecture places all the components of a so ware

system into a single codebase and applica on.

- This style can be easier to develop but can suffer from scalability and maintenance issues as the
applica on grows.

5. **Event-Driven Architecture:**

- Event-driven architecture is based on the concept of events and messages.

- Components of the system communicate by sending and receiving events, allowing for loose
coupling and real- me processing.
6. **Service-Oriented Architecture (SOA):**

- SOA is an architectural style that emphasizes the crea on of reusable, self-contained services that
can be composed to build larger applica ons.

- It promotes interoperability and reusability of components.

7. **Component-Based Architecture:**

- In this style, a so ware system is built by assembling pre-built components, such as libraries or
frameworks.

- It simplifies development and promotes reusability.

8. **Peer-to-Peer Architecture:**

- Peer-to-peer (P2P) architecture allows individual nodes (computers) to act both as clients and
servers, sharing resources and data directly with one another.

- It's o en used for decentralized systems and file-sharing applica ons.

9. **Event Sourcing and CQRS (Command Query Responsibility Segrega on):**

- These architectural styles are o en used together.

- Event sourcing captures all changes to an applica on's state as a series of immutable events,
while CQRS separates the read and write sides of the applica on for op miza on and scalability.

10. **Hexagonal Architecture (Ports and Adapters):**

- Hexagonal architecture emphasizes the separa on of the applica on's core business logic from
external dependencies.

- It uses "ports" for interac ons with the outside world and "adapters" to connect the core to
those ports.

These architectural styles offer different ways to structure and design so ware systems, and the
choice of the right style depends on the specific requirements and constraints of the project. O en, a
combina on of these styles may be used to address various aspects of a complex so ware system.