UNIT -5

SOFTWARE ENGINEERING
SOFTWARE PROCESSES


Software is the set of instructions in the form of programs to govern the computer system
and to process the hardware components. To produce a software product the set of activities
is used. This set is called a software process.

What are Software Processes?

Software processes in software engineering refer to the methods and techniques used to
develop and maintain software. Some examples of software processes include:
 Waterfall: a linear, sequential approach to software development, with distinct phases
such as requirements gathering, design, implementation, testing, and maintenance.
 Agile: a flexible, iterative approach to software development, with an emphasis on rapid
prototyping and continuous delivery.
 Scrum: a popular Agile methodology that emphasizes teamwork, iterative development,
and a flexible, adaptive approach to planning and management.
 DevOps: a set of practices that aims to improve collaboration and communication
between development and operations teams, with an emphasis on automating the software
delivery process.
Each process has its own set of advantages and disadvantages, and the choice of which one to
use depends on the specific project and organization.
Components of Software
There are three main components of the software:
1. Program: A computer program is a list of instructions that tell a computer what to do.
2. Documentation: Source information about the product contained in design documents,
detailed code comments, etc.
3. Operating Procedures: Set of step-by-step instructions compiled by an organization to
help workers carry out complex routine operations.
Other Software Components
Other Software Components are:
1. Code: the instructions that a computer executes in order to perform a specific task or set
of tasks.
2. Data: the information that the software uses or manipulates.
3. User interface: the means by which the user interacts with the software, such as buttons,
menus, and text fields.
4. Libraries: pre-written code that can be reused by the software to perform common tasks.
5. Documentation: information that explains how to use and maintain the software, such as
user manuals and technical guides.
6. Test cases: a set of inputs, execution conditions, and expected outputs that are used to test
the software for correctness and reliability.
7. Configuration files: files that contain settings and parameters that are used to configure
the software to run in a specific environment.
8. Build and deployment scripts: scripts or tools that are used to build, package, and deploy
the software to different environments.
9. Metadata: information about the software, such as version numbers, authors, and
copyright information.
All these components are important for software development, testing and deployment.
Key Process Activities
There four basic key process activities are:
1. Software Specifications: In this process, detailed description of a software system to be
developed with its functional and non-functional requirements.
2. Software Development: In this process, designing, programming, documenting, testing,
and bug fixing is done.
3. Software Validation: In this process, evaluation software product is done to ensure that
the software meets the business requirements as well as the end users needs.
4. Software Evolution: It is a process of developing software initially, then timely updating
it for various reasons.
Software Crisis
The term “software crisis” refers to a set of problems that were faced by the software industry
in the 1960s and 1970s, such as:
1. Size and Cost: Day to day growing complexity and expectation out of software. Software
are more expensive and more complex.
2. Quality: Software products must have good quality.
3. Delayed Delivery: Software takes longer than the estimated time to develop, which in
turn leads to cost shooting up.
4. High costs and long development times: software projects were taking much longer and
costing much more than expected.
5. Low quality: software was often delivered late, with bugs and other defects that made it
difficult to use.
6. Lack of standardization: there were no established best practices or standards for
software development, making it difficult to compare and improve different approaches.
7. Lack of tools and methodologies: there were few tools and methodologies available to
help with software development, making it a difficult and time-consuming process.
Software Process Model
A software process model is an abstraction of the actual process, which is being described. It
can also be defined as a simplified representation of a software process. Each model
represents a process from a specific perspective.
Following are some basic software process models on which different type of software
process models can be implemented:
1. A workflow Model : It is the sequential series of tasks and decisions that make up a
business process.
2. The Waterfall Model: It is a sequential design process in which progress is seen as
flowing steadily downwards.
 Phases in waterfall model:
 Requirements Specification
 Software Design
 Implementation
 Testing

3. Dataflow Model: It is diagrammatic representation of the flow and exchange of

information within a system.
4. Evolutionary Development Model: Following activities are considered in this method:
 Specification
 Development
 Validation
5. Role / Action Model: Roles of the people involved in the software process and the
activities.
Need for Process Model
The software development team must decide the process model that is to be used for software
product development and then the entire team must adhere to it. This is necessary because
the software product development can then be done systematically. Each team member will
understand what is the next activity and how to do it. Thus process model will bring the
definiteness and discipline in overall development process. Every process model consists of
definite entry and exit criteria for each phase. Hence the transition of the product through
various phases is definite.
If the process model is not followed for software development then any team member can
perform any software development activity, this will ultimately cause a chaos and software
project will definitely fail without using process model, it is difficult to monitor the progress
of software product. Thus process model plays an important rule in software engineering.
Advantages or Disadvantages of Process Model
There are several advantages and disadvantages to different software development
methodologies, such as:
Waterfall
Advantages of waterfall model are:
1. Clear and defined phases of development make it easy to plan and manage the project.
2. It is well-suited for projects with well-defined and unchanging requirements.
Disadvantages of waterfall model are:
1. Changes made to the requirements during the development phase can be costly and time-
consuming.
2. It can be difficult to know how long each phase will take, making it difficult to estimate
the overall time and cost of the project.
3. It does not have much room for iteration and feedback throughout the development
process.
Agile
Advantages of Agile Model are:
1. Flexible and adaptable to changing requirements.
2. Emphasizes rapid prototyping and continuous delivery, which can help to identify and fix
problems early on.
3. Encourages collaboration and communication between development teams and
stakeholders.
Disadvantages of Agile Model are:
1. It may be difficult to plan and manage a project using Agile methodologies, as
requirements and deliverables are not always well-defined in advance.
2. It can be difficult to estimate the overall time and cost of a project, as the process is
iterative and changes are made throughout the development.
Scrum
Advantages of Scrum are:
1. Encourages teamwork and collaboration.
2. Provides a flexible and adaptive framework for planning and managing software
development projects.
3. Helps to identify and fix problems early on by using frequent testing and inspection.
Disadvantages of Scrum are:
1. A lack of understanding of Scrum methodologies can lead to confusion and inefficiency.
2. It can be difficult to estimate the overall time and cost of a project, as the process is
iterative and changes are made throughout the development.
DevOps
Advantages of DevOps are:
1. Improves collaboration and communication between development and operations teams.
2. Automates software delivery process, making it faster and more efficient.
3. Enables faster recovery and response time in case of issues.
Disadvantages of DevOps are:
1. Requires a significant investment in tools and technologies.
2. Can be difficult to implement in organizations with existing silos and lack of culture of
collaboration.
3. Need to have a skilled workforce to effectively implement the devops practices.
4. Ultimately, the choice of which methodology to use depends on the specific project and
organization, as well as the goals and requirements of the project.
Software processes provide structured methods for developing and maintaining software.
They include approaches like Waterfall for linear projects, Agile for flexibility, Scrum for
teamwork, and DevOps for automation and collaboration. Each has unique strengths, tailored
to different project needs. Choosing the right process enhances efficiency and product
quality.

GENERIC SOFTWARE

Generic software is off-the-shelf software available for use. These can be described as ready-
made products already developed b some organization that the client can download
immediately and use to perform the task. The software is designed to accomplish several
general use purposes and meets the needs of clients from different departments. Various
groups of users can use it according to their requirements. Custom software is different from
generic software is developed for a specific group of users that want to perform a particular
function with the software. The client specifies their needs before the software development.
The developer builds the software accordingly.

An example of generic software is the MS Excel spreadsheet application. Different types of

users use it to perform various functions. The data analyst uses its tool to read and analyze the
data, while people with a finance background use it as an accounting application. It is also
used to perform computation and store data. An example of custom software can be the
employee portal of an organization, as that is used by the members of the particular
organization only.

Characteristics of Generic Software

Generic software is designed to be used widely by people across different industries. These
software are not tailored according to a need of a specific user. Some of the characteristics of
generic software are as follows:

o Flexible: generic software is designed to be used in different situations. Since the

objective of the developing agent is to develop software for the masses, the software
 developed is made flexible to address the needs of different users. Thus, it can be
adopted by other groups of users to perform the same or different operations.
o Customization: The generic software is not designed for a selective group of people.
There is no certainty over the preferences of the user implementing the software.
Therefore, several functions allow the users to customize the software according to
their requirements. These include graphical customization, like changing the
appearance of the software and its theme according to the user's preference.
o Ease of Operation: They are decided to be used by both technical and non-technical
personnel. Some of the generic software is used to perform daily tasks. Therefore, the
developer ensures that they are easy to implement. It is best suited for beginners as it
does not include complex functions.
o Broad Compatibility: since the developer has yet to learn about the final user. The
software is developed to be implemented on different operating systems. The software
can be designed to work with different hardware equipment and be implemented with
other software applications.
o Standardization: Since the generic software is developed to be accepted widely.
Therefore, they are built while adhering to certain industry standards that make it
simpler for organizations worldwide to implement the software without requiring
them to change their systems. They also follow specific regulatory measures to ensure
they can be accepted widely.
o Cost-effective: Most generic software is designed for learning purposes or use by the
general public. Since the number of users is relatively high, the software license cost
is kept very low. It enables users to use this software when they cannot afford custom
or tailor-made software. Some developers also provide free versions of these
applications.
o Limited Functionality: Generic Software only has some of the features the user
requires. There might be some functions that the user wants to perform, but the
software does not support them. This software is designed broadly and mainly does
not include complex processes. In this scenario, the user may have to use multiple
software and require additional tools to perform these functions.

Advantages of Generic Software

Several advantages of generic software are as follows:

1. Easy to use: the developers develop this software for both technical and non-
technical background people. The implementation of the functions is kept very
simple. They can be used easily and support a wide range of systems.
2. Flexibility: Generic software is designed to ensure that the software can be used in
different scenarios. Since they are developed to be used by people in various fields,
they should be flexible to accommodate the needs of different types of users.
3. Cost Effective: This is the most essential reason that most small and medium-sized
organizations prefer generic software. The generic software is developed to be used
by numerous users from different fields. The cost per user is relatively low compared
to custom-built applications for specific persons in a particular organization. Since
most start-ups and small, medium-sized organization has limited budgets using
generic software is a better option.
4. Adaptability: This software is developed to be adaptable to different system and
application requirements making this software more versatile. They are specifically
advantageous if there are different users from around the world. It also allows
organizations to adapt to the changes as they can modify the processes and workflow
in response to changing market conditions and several other factors.
5. Standardization: Generic software is developed for different industries. They are
made compatible with the maximum user's system. Therefore, most generic software
is designed around specific industry and regulatory standards. It helps businesses and
organizations as they can download these applications and install them in their
system. It ensures that the application meets particular needs and follows best
practices in the industry.
6. User-friendly: They are developed not only to be used by professionals but also by
non-IT professionals. Therefore, the developers ensure that it is simple to perform
operations and can be easily used by all. They avoid adding complex application
functionality, and their interface is easy to use.
7. Regular Updates: Since the application has a broad user base, developers often
launch regular updates. They release updates to resolve any issues or bugs that may
occur while using the application. This ensures that the software is working efficiently
and is compatible with the latest updates in the industry. It also ensures software
security is maintained.
8. Wide Availability: Numerous users from different fields use these applications.
These software are popular and have a large client base. Therefore it is easier to find
support and resources online to help with using these programs. Several tutorials
 explain the implementation and working of these applications. It makes it easier for
users to find assistance.

Disadvantages of Generic Software

There are several advantages of using generic software in your organization, but certain
disadvantages may occur when working with this software. Some of these are mentioned
below:

1. Limited Customization:
2. Limited Functions: Security Issues: Generic software has a wide range of
applications and is used by numerous users. This makes it vulnerable to security
breaches and cyber-attacks. Moreover, it is readily available on the internet to send
viruses while downloading the software. Many hackers use such applications to target
popular application software and exploit the vulnerabilities of these applications.
3. Dependent on Software Updates: Compatibility Issues: the software is developed
according to the most used system requirements and platforms. The software is
released for different systems and platforms, but compatibility issues are still possible.
It is particularly possible if the user uses old hardware or software or when using
software or recently launched.
4. Training and Support: Ownership and Licensing:

Reasons to Choose Generic Software

1. Cost-effectiveness: .
2. Ease of implementation: .
3. Broad functionality: .
4. Wide availability.
5. Regular updates:

PROCESS LIFECYCLE ORSOFTWARE 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:

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.

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.

Stage5: 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.

Stage6: 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.

Stage7: 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.

PRESCRIPTIVE PROCESS MODELS

SDLC Models

Software Development life cycle (SDLC) is a spiritual model used in project management
that defines the stages include in an information system development project, from an initial
feasibility study to the maintenance of the completed application.

There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models." Each process model follows a series of phase unique to its
type to ensure success in the step of software development.

Here, are some important phases of SDLC life cycle:

WATERFALL MODEL

The waterfall is a universally accepted SDLC model. In this method, the whole process of
software development is divided into various phases.

The waterfall model is a continuous software development model in which development is

seen as flowing steadily downwards (like a waterfall) through the steps of requirements
analysis, design, implementation, testing (validation), integration, and maintenance.
Linear ordering of activities has some significant consequences. First, to identify the end of a
phase and the beginning of the next, some certification techniques have to be employed at the
end of each step. Some verification and validation usually do this mean that will ensure that
the output of the stage is consistent with its input (which is the output of the previous step),
and that the output of the stage is consistent with the overall requirements of the system.

RAD Model

RAD or Rapid Application Development process is an adoption of the waterfall model; it

targets developing software in a short period. The RAD model is based on the concept that a
better system can be developed in lesser time by using focus groups to gather system
requirements.

o Business Modeling
o Data Modeling
o Process Modeling
o Application Generation
o Testing and Turnover

Spiral Model

The spiral model is a risk-driven process model. This SDLC model helps the group to adopt
elements of one or more process models like a waterfall, incremental, waterfall, etc. The
spiral technique is a combination of rapid prototyping and concurrency in design and
development activities.

Each cycle in the spiral begins with the identification of objectives for that cycle, the different
alternatives that are possible for achieving the goals, and the constraints that exist. This is the
first quadrant of the cycle (upper-left quadrant).

The next step in the cycle is to evaluate these different alternatives based on the objectives
and constraints. The focus of evaluation in this step is based on the risk perception for the
project.

The next step is to develop strategies that solve uncertainties and risks. This step may involve
activities such as benchmarking, simulation, and prototyping.

V-Model

In this type of SDLC model testing and the development, the step is planned in parallel. So,
there are verification phases on the side and the validation phase on the other side. V-Model
joins by Coding phase.

Incremental Model
The incremental model is not a separate model. It is necessarily a series of waterfall cycles.
The requirements are divided into groups at the start of the project. For each group, the SDLC
model is followed to develop software. The SDLC process is repeated, with each release
adding more functionality until all requirements are met. In this method, each cycle act as the
maintenance phase for the previous software release. Modification to the incremental model
allows development cycles to overlap. After that subsequent cycle may begin before the
previous cycle is complete.

Agile Model

Agile methodology is a practice which promotes continues interaction of development and

testing during the SDLC process of any project. In the Agile method, the entire project is
divided into small incremental builds. All of these builds are provided in iterations, and each
iteration lasts from one to three weeks.

Any agile software phase is characterized in a manner that addresses several key assumptions
about the bulk of software projects:

1. It is difficult to think in advance which software requirements will persist and which
will change. It is equally difficult to predict how user priorities will change as the
project proceeds.
2. For many types of software, design and development are interleaved. That is, both
activities should be performed in tandem so that design models are proven as they are
created. It is difficult to think about how much design is necessary before construction
is used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a planning
point of view) as we might like.

Iterative Model

It is a particular implementation of a software development life cycle that focuses on an

initial, simplified implementation, which then progressively gains more complexity and a
broader feature set until the final system is complete. In short, iterative development is a way
of breaking down the software development of a large application into smaller pieces.

Big bang model

Big bang model is focusing on all types of resources in software development and coding,
with no or very little planning. The requirements are understood and implemented when they
come.

ADVERTISEMENT

This model works best for small projects with smaller size development team which are
working together. It is also useful for academic software development projects. It is an ideal
model where requirements are either unknown or final release date is not given.
Prototype Model

The prototyping model starts with the requirements gathering. The developer and the user
meet and define the purpose of the software, identify the needs, etc.

A 'quick design' is then created. This design focuses on those aspects of the software that
will be visible to the user. It then leads to the development of a prototype. The customer then
checks the prototype, and any modifications or changes that are needed are made to the
prototype.

Looping takes place in this step, and better versions of the prototype are created. These are
continuously shown to the user so that any new changes can be updated in the prototype. This
process continue until the customer is satisfied with the system. Once a user is satisfied, the
prototype is converted to the actual system with all considerations for quality and security.

PROJECT MANAGEMENT

A project is a group of tasks that need to complete to reach a clear result. A project also
defines as a set of inputs and outputs which are required to achieve a goal. Projects can vary
from simple to difficult and can be operated by one person or a hundred.

Projects usually described and approved by a project manager or team executive. They go
beyond their expectations and objects, and it's up to the team to handle logistics and complete
the project on time. For good project development, some teams split the project into specific
tasks so they can manage responsibility and utilize team strengths.

What is software project management?

Software project management is an art and discipline of planning and supervising software
projects. It is a sub-discipline of software project management in which software projects
planned, implemented, monitored and controlled.

It is a procedure of managing, allocating and timing resources to develop computer software

that fulfills requirements.

In software Project Management, the client and the developers need to know the
length, period and cost of the project.

Prerequisite of software project management?

There are three needs for software project management. These are:

1. Time
2. Cost
3. Quality

It is an essential part of the software organization to deliver a quality product, keeping the
cost within the client?s budget and deliver the project as per schedule. There are various
 factors, both external and internal, which may impact this triple factor. Any of three-factor
can severely affect the other two.

Project Manager

A project manager is a character who has the overall responsibility for the planning, design,
execution, monitoring, controlling and closure of a project. A project manager represents an
essential role in the achievement of the projects.

A project manager is a character who is responsible for giving decisions, both large and small
projects. The project manager is used to manage the risk and minimize uncertainty. Every
decision the project manager makes must directly profit their project.

Role of a Project Manager:

1. Leader

A project manager must lead his team and should provide them direction to make them
understand what is expected from all of them.

2. Medium:

The Project manager is a medium between his clients and his team. He must coordinate and
transfer all the appropriate information from the clients to his team and report to the senior
management.

3. Mentor:

He should be there to guide his team at each step and make sure that the team has an
attachment. He provides a recommendation to his team and points them in the right direction.

Responsibilities of a Project Manager:

1. Managing risks and issues.

2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.

COMPONENT BASED DEVELOPMENT


Component-Based Software Engineering (CBSE) is a process that focuses on the design
and development of computer-based systems with the use of reusable software components.
It not only identifies candidate components but also qualifies each component’s interface,
adapts components to remove architectural mismatches, assembles components into a
selected architectural style, and updates components as requirements for the system change.
 The process model for component-based software engineering occurs concurrently
with component-based development.
Component-based development:
Component-based development (CBD) is a CBSE activity that occurs in parallel with domain
engineering. Using analysis and architectural design methods, the software team refines an
architectural style that is appropriate for the analysis model created for the application to be
built.
CBSE Framework Activities:
Framework activities of Component-Based Software Engineering are as follows:
1. Component Qualification: This activity ensures that the system architecture defines the
requirements of the components for becoming a reusable components. Reusable
components are generally identified through the traits in their interfaces. It means “the
services that are given and the means by which customers or consumers access these
services ” are defined as a part of the component interface.
2. Component Adaptation: This activity ensures that the architecture defines the design
conditions for all components and identifies their modes of connection. In some cases,
existing reusable components may not be allowed to get used due to the architecture’s
design rules and conditions. These components should adapt and meet the requirements
of the architecture or be refused and replaced by other, more suitable components.
3. Component Composition: This activity ensures that the Architectural style of the system
integrates the software components and forms a working system. By identifying the
connection and coordination mechanisms of the system, the architecture describes the
composition of the end product.
4. Component Update: This activity ensures the updation of reusable components.
Sometimes, updates are complicated due to the inclusion of third-party (the organization
that developed the reusable component may be outside the immediate control of the
software engineering organization accessing the component currently).

ASPECT-ORIENTED SOFTWARE DEVELOPMENT

Aspect-oriented software development (AOSD) is a software design solution that helps

address the modularity issues that are not properly resolved by other software approaches,
like procedural, structured and object-oriented programming (OOP). AOSD complements,
rather than replaces, these other types of software approaches.

AOSD is also known as aspect-oriented programming (AOP).

 Considered a subset of post-object programming technologies

 Better software design support through isolating application business logic from supporting
and secondary functions
 Provides complementary benefits and may be used with other agile processes and coding
standards
 Key focus – Identification, representation and specification of concerns, which also may be
cross-cutting
 Provides better modularization support of software designs, reducing software design,
development and maintenance costs
 Modularization principle based on involved functionalities and processes
 Because concerns are encapsulated into different modules, localization of crosscutting
concerns is better promoted and handled
 Provides tools and software coding techniques to ensure modular content support at the
source code level
 Promotes reusability of code used for the modularization of cross-cutting concerns
 Smaller code size, due to tackling cross cutting concerns
 Reduced efficiency from increased overhead

FORMAL METHODS

Formal methods are techniques we use in computer science and software engineering to
ensure the correctness of our programs and reduction in our programs' errors. They rely on
math and logic to model and analyze system behavior, making systems more reliable and
[Link] are multiple reasons we use formal methods for:
 Correctness and reliability: Formal methods help solve errors and inconsistencies in
software and hardware, making projects less error-prone, more reliable, and correct.
 Early error detection: Formal methods allow us to detect errors and inconsistencies
in the early phases of our software development cycle, reducing future losses
regarding time and money.
 Fewer unambiguity: By using formal languages for system specifications, we can
clearly understand our system's behavior and specification, so there are fewer
misunderstandings between us and the stakeholders.
 Safety critical systems: Safety critical systems refer to systems whose failure can
lead to consequences of bigger impact, such as medical devices and aerospace, etc.
Formal methods help us maintain high safety standards for such systems.
 Verification and alidation: We can use formal verification and validation methods to
prove and ensure the correctness of our system's hardware and software.
 Security: Formal methods help us ensure the security of our devices by validating
and verifying our systems' requirements.

Use of Formal methods in software development life cycle

Software development life cycle (SDLC) refers to the entire process of development of the
software applications. It includes the following [Link] development life cycle

Let's discuss the role of formal methods in phases of software development.

Analysis

Formal methods are useful to remove ambiguities and inconsistencies in our software
application's requirements as it verifies and validates them using formal verification and
validation techniques. These techniques help us better understand the requirements.

Feasibility study

We use formal methods in feasibility studies of our software project to analyze its viability,
assess risks, and ensure technical feasibility. This enhances accuracy in decision-making and
reduction in potential errors that might occur in the future.

Design

Formal methods can be useful in the design phase of our software application as they can
help in the software architecture using formal models to give us a road map for our software
application.

Development

We can use formal specification methods in the development phase to remove any bugs and
errors in implementing our code.

Testing

We can use formal verification methods for software components or the entire system to
validate if the intent of the software application is fulfilled or not. Moreover, the software is
tested using rigorous techniques to ensure a bug-free application.

Deployment

Formal methods can help in validating that our software application meets the client's
requirements and needs and can ensure that the deployed software matches the formally
verified models.

Maintenance

As changes are made to the software, formal methods can be used to verify that modifications
do not introduce new issues or affect existing functionality.

Limitations of formal methods

 Complexity: For larger and more complex systems, formal methods are difficult to
apply. It can be more time and effort-consuming.
 Expensive: Formal methods are costly in terms of time and resources as compared to
traditional verification and validation techniques.
 Limited Scope: Formal methods are suitable for a limited type of system. For
systems with rapidly changing requirements or a high degree of uncertainty, formal
methods is not suitable.
 Difficult to understand: Formal methods are highly precise and detailed, so they can
be difficult to understand for some complex systems.
AGILE PROCESS MODEL

EXTREME PROGRAMMING, ADOPTIVE SOFTWARE

DEVELOPMENT,SCRUM,DYNAMIC SYSTEM DEVELOPMENT MODEL,FEATURE
DIVEN DEVELOPMENT,CRYSTAL

The meaning of Agile is swift or versatile."Agile process model" refers to a software

development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in
advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller parts
helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software development
life cycle including planning, requirements analysis, design, coding, and testing before a
working product is demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback
1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders
to define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance
and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.

Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

Scrum

SCRUM is an agile development process focused primarily on ways to manage tasks in team-
based development [Link] are three roles in it, and their responsibilities are:

o Scrum Master: The scrum can set up the master team, arrange the meeting and
remove obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the delay
and is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the
sprint or cycle.

eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing demands or
requirements, or when they are not sure about the system's performance.

Crystal:

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development
team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
Wrap up: According to the user environment, this phase performs deployment, post-
deployment.

Dynamic Software Development Method(DSDM):

DSDM is a rapid application development strategy for software development and gives an
agile project distribution structure. The essential features of DSDM are that users must be
actively connected, and teams have been given the right to make decisions. The techniques
used in DSDM are:

1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

Feature Driven Development(FDD):

This method focuses on "Designing and Building" features. In contrast to other smart
methods, FDD describes the small steps of the work that should be obtained separately per
function.
Lean Software Development:

Lean software development methodology follows the principle "just in time production." The
lean method indicates the increasing speed of software development and reducing costs. Lean
development can be summarized in seven phases.

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

When to use the Agile Model?

o When frequent changes are required.

o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages(Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions
taken throughout various phases can be misinterpreted at any time by different team
members.
2. Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can become
a difficulty.
 SOFTWARE REQUIREMENTS
FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTS

ELICITING – REQUIREMENTS


Requirements elicitation is the process of gathering and defining the requirements for a
software system. The goal of requirements elicitation is to ensure that the software
development process is based on a clear and comprehensive understanding of the customer’s
needs and requirements. This article focuses on discussing Requirement Elicitation in detail.

What is Requirement Elicitation?

The process of investigating and learning about a system’s requirements from users, clients,
and other stakeholders is known as requirements elicitation. Requirements elicitation
in software engineering is perhaps the most difficult, most error-prone, and most
communication-intensive software development.
1. Requirement Elicitation can be successful only through an effective customer-developer
partnership. It is needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and refinement
of the requirements for a software system.
3. Requirement Elicitation is a critical part of the software development life cycle and is
typically performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the organization,
including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and well-
defined requirements that serve as the basis for the design and development of the
software system.
6. Requirements elicitation is difficult because just questioning users and customers about
system needs may not collect all relevant requirements, particularly for safety and
dependability.
7. Interviews, surveys, user observation, workshops, brainstorming, use cases, role-playing,
and prototyping are all methods for eliciting requirements.
Importance of Requirements Elicitation
1. Compliance with Business Objectives: The process of elicitation guarantees that the
software development endeavors are in harmony with the wider company aims and
objectives. Comprehending the business context facilitates the development of a solution
that adds value for the company.
2. User Satisfaction: It is easier to create software that fulfills end users’ needs and
expectations when they are involved in the requirements elicitation process. Higher user
pleasure and acceptance of the finished product are the results of this.
3. Time and Money Savings: Having precise and well-defined specifications aids in
preventing miscommunication and rework during the development phase. As a result,
there will be cost savings and the project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is crucial for
projects in regulated industries to guarantee that the software conforms with applicable
laws and norms. In industries like healthcare, finance, and aerospace, this is crucial.
5. Traceability and Documentation: Throughout the software development process,
traceability is based on well-documented requirements. Traceability helps with testing,
validation, and maintenance by ensuring that every part of the software can be linked to a
particular requirement.
Requirements Elicitation Activities
Requirements elicitation includes the subsequent activities. A few of them are listed below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to be applied must
be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.
Requirements Elicitation Methods
There are several requirements elicitation methods. A few of them are listed below:
1. Interviews
The objective of conducting an interview is to understand the customer’s expectations of the
software.
It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility. Interviews may be open-ended or structured.
1. In open-ended interviews, there is no pre-set agenda. Context-free questions may be
asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a
proper questionnaire is designed for the interview.
2. Brainstorming Sessions
 Brainstorming Sessions is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their
priority if possible.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the developers
think they are supposed to build and what customers think they are going to get. A team-
oriented approach is developed for requirements gathering. Each attendee is asked to make a
list of objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, the team is divided into smaller sub-teams to develop mini-specifications and
finally, a draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes the
requirements that are valuable to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed software are
discussed with the customer. For example – normal requirements for a result management
system may be entry of marks, calculation of results, etc.
 Expected requirements: These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.
 Exciting requirements: It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. For example – when unauthorized access is
detected, it should back up and shut down all processes.
5. Use Case Approach
Use Case technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.
The components of the use case design include three major things – Actor, use cases, and use
case diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in some
way. An actor may be a person, machine, etc. It is represented as a stick figure. Actors
can be primary actors or secondary actors.
 Primary actors: It requires assistance from the system to achieve a goal.
 Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete set of use
cases specifies all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents what happens when an
actor interacts with a system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
Steps of Requirements Elicitation
Following are the Steps of Requirement Elicitation
1. Identify all the stakeholders, e.g., Users, developers, customers, etc.
2. List out all requirements from the customer.
3. A value indicating the degree of importance is assigned to each requirement.
4. In the end, the final list of requirements is categorized as:
 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.
Features of Requirements Elicitation
1. Stakeholder engagement: Requirements elicitation involves engaging with stakeholders
such as customers, end-users, project sponsors, and subject-matter experts to understand
their needs and requirements.
2. Gathering information: Requirements elicitation involves gathering information about
the system to be developed, the business processes it will support, and the end-users who
will be using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing requirements
based on their importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves documenting the
requirements clearly and concisely so that they can be easily understood and
communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating and verifying
the requirements with the stakeholders to ensure they accurately represent their needs and
requirements.
6. Iterative process: Requirements elicitation is an iterative process that involves
continuously refining and updating the requirements based on feedback from
stakeholders.
7. Communication and collaboration: Requirements elicitation involves effective
communication and collaboration with stakeholders, project team members, and other
relevant parties to ensure that the requirements are clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing
requirements, stakeholder needs, and project constraints.
Advantages of Requirements Elicitation
1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration between
stakeholders.
3. Results in good quality software: Increases the chances of developing a software system
that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to manage
expectations.
5. Supports the identification of potential risks: Supports the identification of potential
risks and problems early in the development cycle.
6. Facilitates development of accurate plan: Facilitates the development of a
comprehensive and accurate project plan.
7. Increases user confidence: Increases user and stakeholder confidence in the software
development process.
8. Supports identification of new business opportunities: Supports the identification of
new business opportunities and revenue streams.
Disadvantages of Requirements Elicitation
1. Time-consuming: It can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: This may be impacted by changing business
needs and requirements.
4. Impacted by other factors: Can be impacted by political and organizational factors.
5. Lack of commitment from stakeholders: This can result in a lack of buy-in and
commitment from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting priorities and
competing interests.
7. Sometimes inaccurate requirements: This may result in incomplete or inaccurate
requirements if not properly managed.
8. Increased development cost: This can lead to increased development costs and
decreased efficiency if requirements are not well-defined.

USE-CASE MODEL

The Use-case model is defined as a model which is used to show how users interact with the
system in order to solve a problem. As such, the use case model defines the user's objective,
the interactions between the system and the user, and the system's behavior required to meet
these objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the
association between them.

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is
related to the given model, each demonstrating a subset of the model components related to a
specific purpose. A similar model component might be appearing on a few use-case
diagrams; however, each use-case should be consistent. If, in order to handle the use-case
model, tools are used then this consistency restriction is automated so that any variations to
the component of the model (changing the name, for instance) will be reflected automatically
on each use-case diagram, which shows that component.

Packages may include a use-case model, which is used to organize the model to simplify the
analysis, planning, navigation, communication, development and maintenance.

Various use-case models are textual and the text captured in the use-case specifications,
which are linked with the element of every use-case model. The flow of events of the use
case is described with the help of these specifications.

The use-case model acts as an integrated thread in the development of the entire system. The
use-case model is used like the main specification of the system functional requirements as
the basis for design and analysis, as the basis for user documentation, as the basis of defining
test cases, and as an input to iteration planning.

Origin of Use-Case

Nowadays, use case modeling is frequently connected with UML, in spite of the fact that it
has been presented before UML existed. Its short history is:

o Ivar Jacobson, in the year 1986, originally formulated textual and visual modeling
methods to specify use cases.
o And in the year 1992, his co-authored book named Object-Oriented Software
Engineering - A Use Case Driven Approach, assisted with promoting the strategy for
catching functional requirements, particularly in software development.

Components of Basic Model

There are various components of the basic model:

1. Actor
2. Use Case
3. Associations

Actor

Usually, actors are people involved with the system defined on the basis of their roles. An
actor can be anything such as human or another external system.

Use Case
The use case defines how actors use a system to accomplish a specific objective. The use
cases are generally introduced by the user to meet the objectives of the activities and variants
involved in the achievement of the goal.

Associations

Associations are another component of the basic model. It is used to define the associations
among actors and use cases they contribute in. This association is called communicates-
association.

Advanced Model Components

There are various components of the advanced model:

1. Subject
2. Use-Case Package
3. Generalizations
4. Generalizations
5. Dependencies

Subject

The subject component is used to represent the boundary of the system of interest.

Use-Case Package

We use the model component in order to structure the use case model to make simpler the
analysis, planning, navigation, and communication. Suppose there are various actors or use
cases. In that case, we can also use use-case packages in order to further structure the use-
case model in much the similar way we use directories or folders to organize the information
on our hard-disk.

For various reasons, we divide the use-case model into the use-case packages, containing:

o To help parallel development by partitioning the problem into bite-sized parts.

o To improve communication with various stakeholders by making packaging
containing actors, use cases and related to the specific stakeholder.

Generalizations

Generalizations mean the association between the actors in order to help re-use of common
properties.

Dependencies
In UML, various types of dependencies are defined between use cases. In particular,
<<include>> and <<extend>>.

ADVERTISEMENT

We use <<include>> dependency to comprise shared behavior from an included use case into
a base use case to use common behavior.

We use <<extend>> dependency to include optional behavior from an extended use-case into
an extended use case.

How to Draw a Use-Case Diagram?

If we want to draw a use case diagram in UML first, we must study the complete system
appropriately. We need to find out every function which is offered by the system. When we
find out all the system's functionalities then we convert these functionalities into a number of
use cases, and we use these use-cases in the use case diagram.

A use case means essential functionality of any working system. When we organize the use
cases, then next we need to enlist the numerous actors or things that will collaborate with the
system. These actors are used to implement the functionality of a system. Actors can be
someone or something. It can likewise be a private system's entity. The actors should be
pertinent to the functionality or a system in which the actors are interacting.

When we enlist the use cases and actors, then next, we need to find the relationship of a
specific actor with the system or a use case. An actor should find the total number of ways in
order to cooperate with the system. One actor can interact with the numerous use cases
simultaneously, or it may interact with the multiple-use cases concurrently.

We have to follow the following rules while drawing use-case for any framework:

o The use case name and actor name should be meaningful and related to the system.
o The actor's interaction with the use case should be well-described and in a
comprehensible manner.
o Use annotations wherever they are essential.
o If the actor or use case has many relationships, then display only important
interactions.

When to Use a Use-Case Diagram?

The use-case diagram is an extraordinary system's functionality that is accomplished by a

client. The objective of use-case diagram is to capture the system's key functionalities and
visualize the interactions of different thinkings known as actors with the use case. It is the
basic use of use-case diagram.

With the help of the use-case diagram, we can characterize the system's main part and flow of
work among them. In the use-case, the implementation of details is hidden from external use,
and only the flow of the event is [Link] use-case diagrams, we can detect the pre-
and post-conditions after communication with the actor. We can determine these conditions
using several test cases.

Generally, the use-cases diagram is used for:

o Examining the system's requirements.

o Capturing the system's Functionalities.
o We use use-case diagram in order to modeling the general idea behind the system.
o System's Forward and reverse engineering using several test cases.
o Complex visual designing of software.

Use cases are planned to convey wanted functionality so that the exact scope of use case can
differ based on the system and the purpose of making the UML model.

Tips for Drawing a Use-Case Diagram

There are various tips for drawing a use-case diagram:

o It must be complete.
o It must be simple.
o The use-case diagram must show each and every interaction with the use case.
o It is must that the use-case should be generalized if it is large.
o At least one system module must be defined in the use case diagram.
o When there are number of actors or use-cases in the use-case diagram, only the
significant use-cases must be represented.
o The use-case diagrams must be clear and easy so that anyone can understand them
easily.

Importance of Use-Case Diagram

Use Cases have been broadly used over the last few years. There are various benefits of the
use-case diagram:

o Use-case diagram provides an outline related to all components in the system. Use-
case diagram helps to define the role of administrators, users, etc.
o The use-Case diagram helps to provide solutions and answers to various questions
that may pop up if you begin a project unplanned.
o It helps us to define the needs of the users extensively and explore how it will work.
Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:

System

With the help of the rectangle, we can draw the boundaries of the system, which includes use-
cases. We need to put the actors outside the system's boundaries.

Use-Case

With the help of the Ovals, we can draw the use-cases. With the verb we have to label the
ovals in order to represent the functions of the system.

Actors

Actors mean the system's users. If one system is the actor of the other system, then with the
actor stereotype, we have to tag the actor system.

Relationships

With the simple line we can represent relationships between an actor and use cases. For
relationships between use-case, we use arrows which are labeled either "extends" or "uses".
The "extends" relationship shows the alternative options under the specific use case. The
"uses" relationship shows that single use-case is required to accomplish a job.

Guidelines for Better Use-Cases

With regards to examine the system's requirements, use-case diagrams are another one to one.
Use-cases are simple to understand and visual. The following are some guidelines that help
you to make better use cases that are appreciated by your customers and peers the same.

Generally, the use-case diagram contains use-cases, relationships, and actors. Systems and
boundaries may be included in the complex larger diagrams. We'll talk about the guidelines
of the use-case diagram on the basis of the objects.

Do not forget that these are the use case diagram's guidelines, not rules of the use-case
diagram.

Actors

o The actor's name should be meaningful and relevant to the business

If the use-case interacting with the outside organization, then we have to give the
actor's name with the function instead of the organization name, such as Airline
company is better than the PanAir).
o Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes the
actors more readable and easily highlights the use-cases, which are exact for that
actor.
o External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email
management software, then in this case, the software is an actor to that specific user-
case.

Use-Cases

o The name of the use-case begins with a verb

The use-case models action, so the name of the use-case must start with a verb.
o The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking at a
diagram, such as instead of "Print," "print Invoice is good.
o Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included use-
cases to the right of the invoking use-cases.
o Place inheriting use-case below the parent use-case
In order to enhance the diagram's readability, we have to place the inheriting use-case
below the parent use-case.
Systems/Packages

o Give descriptive and meaningful names to these objects.

o Use them carefully and only if needed.

Relationships

o When we are using <<extend>> arrow, points to the base use-case.

o When we are using <<include>> then arrow points to the comprised use-case.
o Actor and use-case relationship do not display arrows.
o <<extend>> may have an optional extension condition.
o <<include>> and <<extend>> both are shown as dashed arrows.

Use-Case Examples

Use-Case Example-Association Link

In this use-case diagram, we show a group of use cases for a system which means the
relationship among the use-cases and the actor.

REQUIREMENT ANALYSIS AND MODELLING

REQUIREMENT REVIEWS

Requirements are mandatory in terms of software development. Requirements are the basics
that take forward the development procedure. Requirements enhance the existing project to a
different level. The software cannot progress without the participation of user input. User
input like feedback and product review comes as the major requirements in the development
work.
What are requirement reviews ?
In short, Requirement review is the practice of scanning the software errors to make the
industry user-friendly for all.
Why is requirement review performed ?
Software in the current time is so Advanced that the act of requirement review holds greater
importance in software development. The pursuance of requirement reviews helps to have a
clear peek into the space of the software industry. The requirement reviews call attention to
the only chance of finding quality reviews. So keeping in mind that there are problems and
solutions to everything, a requirement review needs a good performance.
Importance of performing requirement review :
 The performance of requirement review helps to radiate the precise and correct data to the
consumers and users.
 It helps to have a quick tour of the Existing project to see whether or not it is going in the
right direction.
 It helps to provide practical instructions and helps make decisions accordingly.
Methods of performing requirement review :

[Link] consultation :
Suggestion matters also matter the way of performance. Teamwork goes hand in hand. When
there are people to offer suggestions, give appropriate guidelines, and supervise in a team.
There is no doubt about the project getting mismanaged. Reaching out to the team/individual
who has better insights into requirement review works the best way.
[Link] user’s requirement :
Recognize the user’s needs and go all out in understanding them. Requirements keep on
changing with time. So, When you have collected a list of things that a user requires in the
current time. There you found a way to go about it. To get exact information on their
requirements, Asking for feedback is Important.

[Link] measures to software problem :

The occurrence of software problems is predictable. Errors and defects are bound to take
place in software development. In this context, Rather than making a fuss about the
Problems, developers should find solutions to satisfy the requirements. The requirement
review not only meets the expectations of users but also the standard of the entire industry.
Advantages of performing requirement reviews :
 Requirement reviews accord the developers a motive and structure to carry out the project
further.
 Group collaboration is the highlight. Group work saves time.
 Therefore, the developers can utilize the saved time in rechecking and reconfirming the
processing work to take it ahead.
Disadvantages of performing requirement reviews :
 Lack of attention acts as a hindrance. When a team does not listen to each other in a
meeting room because of disagreement on matters, it emerges as a sign of unprofessional
and uncoordinated work.
 At times, the Review cannot be accurate. So, If you fail in assembling the precise
information, it can be an obstacle for the developers and the industry.

SYSTEM REQUIREMENTS AND SPECIFICATION (SRS) DOCUMENT

System Requirements Document is also known as System Requirements

Specifications. System requirements document is a set of documentation that describes the
behavior and features of a software or system. It comprises of various elements that attempt
to characterize the functionality needed by the client to satisfy their users. In other words, the
system requirements document (SRD) describes the system-level performance and functional
requirements for a system.

System Requirements Document or System Requirements Specification is defined as a

document which defines what the software will do and how it will be required to perform,
and it also defines the functionality the software needs to satisfy all stakeholders (users,
business) requirements.

What is Included in a System Requirement Document?

While the SRD capacities as an outline for dealing with the extent of a project, it eventually
characterizes the functional and non-functional requirements of the system. The document
doesn't layout design or technology solutions. These decisions will be taken by the
developers later.

The well-written system requirement document should:

o Split the problem into manageable parts.

o Notify design specifications i.e., SRD needs to comprise adequate information on
software requirements to present an effective design.
o Gives feedback to the customer or client.
o For testing and validation, serve as a reference.

According to the IEEE standards, SRDs must cover the following important topics.

o Quality
o Security/Privacy
o Functional capabilities
o Safety
o Performance levels
o Constraints and Limitations
o Data Structure/Elements
o Reliability
o Interfaces

Main Elements of System Requirements Document

Based on the procedure employed (Waterfall vs. agile), the degree of convention and detail in
the SRS will differ, however in general, system requirement document or system requirement
specification contains a description of the system requirements, functional requirements,
technical requirements, acceptance criteria, assumptions and constraints. We have explained
each of these in more detail below:
Constraints and Assumption

The constraints and assumption section will underline the lack of any design imposed by the
client on the system design, resulting in removing some options from being considered by the
developers. This section also comprises assumptions which are made by the team of
requirement engineering at the time of requirements gathering and analysis. If there is an
incorrect assumption, it is needed to re-evaluate the system requirements specification in
order to ensure that the documented requirements are still valid.

Functional and System Requirements

This segment normally comprises a hierarchical arrangement of requirements, with the

functional/business requirements at the uppermost level and the detailed system requirements
are listed as their child items.

Mostly in the form of statements, the requirements are written like "System requires the
capability to do x," with supporting information comprised as required.

Technical Requirements

This part is utilized to list any of the non-functional requirements, which basically personifies
the technical environment that the product requires to work in and incorporate the technical
limitations that it requires to work under. These technical requirements are important in
deciding how high-level functional requirements can decompose into more definite system
requirements.

Business Drivers

This part depicts the reasons why the client is hoping to build the system. The new system's
rationale is significant because it will manage the choices made by business experts,
engineers, and system architects. Another convincing purpose behind recording the business
logic and behind the system is that during the project, client can change the staff.
Documentation that absolutely recognizes the business explanations for the system will help
to continue support the project if the original sponsor proceeds onward.

The drivers may comprise issues as well as opportunities. Generally, a mix of issues and
opportunities are required to give inspiration to a new system.
System Qualities

The system qualities are the non-functional requirements which are used to define the
system's quality. These qualities are frequently known as "ilities," and the reason behind that
is many of these qualities end with "ility". They are comprised of items like availability,
maintainability, security, reliability, and scalability.

Unlike functional requirements, the quality of the system generally contains tables of
particular metrics that the system should meet to be acknowledged.

Business Models

This part portrays the fundamental business model of the client that the system will require to
support. This contains current-state, future-state and organizational context state diagrams,
key business functions, business context and process flow diagrams. This part is generally
made during the functional analysis phase.

Acceptance Criteria

This part will portray the measures by which the client will "sign-off" the final system. Based
on the procedure, this may occur toward the end of the testing and quality assurance stage, or
in agile methodology, toward the finish of every iteration.

Usually, this measure refers to the requirement in order to complete all user acceptance tests
and fix all bugs/defects which meet a pre-defined priority or severity limits.

Business and System Use Cases

This segment ordinarily comprises a UML use case diagram, which shows the main external
entities that will collaborate with the system along with diverse use cases that should be met.
There will be a formal definition of the steps for every use case which is required to fulfill the
purpose of the business, along with the essential pre-conditions and post-conditions.

Generally, the system use cases are derived from the system requirements and the business
use case is derived from the functional requirements. By using the flowchart, the steps of use
cases are represented.

Characteristics of a Good System Requirements Document

There are various characteristics of good system requirements:

1. Completeness
2. Correctness
3. Modifiability
4. Consistency
5. Testability
 6. Design independence
7. Understandable by the customer
8. Traceability
9. Verifiability
10. Unambiguousness

1. Completeness

The completeness of the system requirements specification or system requirements document

shows each meaning of completion, together with the number of pages, that properly covers
all the functional and non-functional requirements as well as resolving parts to the extent
possible.

2. Correctness

The reviews of the users are used to make sure the accuracy of the requirements states in the
system requirements document. The system requirements document is called true if it
contains all the requirements which are really anticipated from the system.

3. Modifiability

The system requirements document should be modified as well as able to adapt changes to
the system. Modifications must be appropriately indexed and cross-referenced.

4. Consistency

In the system requirements document, requirements are called consistent if in between any
requirements, there is no conflict. Examples of conflicts: logical conflicts such as time period
of the report generation, terminologies which are used at separate places, etc.

5. Testability

A system requirement document must be written in a manner which is simple to create test
plans and test cases from the document.
 6. Design Independence

For the final system, it must be an option to select from the different design alternatives. In
particular, the system requirement document should not include any details regarding
implementation.

7. Understandable by the Customer

An end-user possibly a specialist in his/her particular domain; however probably won't be a

specialist in computer science. Thus, the utilization of formal notations and symbols must be
avoided as much as possible. It is must that the language should be simple and clear.

8. Traceability

One must be capable to design a component in a program and then to detect a requirement for
a code fragment. Similarly, one needs to be able to detect the need for related test cases.

9. Verifiability

A system requirements document is validated if, in the system requirements document, a

particular technique is present in order to quantifiably measure the degree to which the
system meets each requirement. For instance, a requirement expressing that the system
should be easy to use isn't verifiable and listing such requirements must be dodged.

10. Unambiguousness

If each requirement in the system requirements document has only a single interpretation,
then the system requirement document is unambiguous. If we want to avoid
unambiguousness, we have to use some modeling techniques such as proper reviews, ER
diagrams, buddy checks, etc.

McCall’s Quality Model


McCall’s Software Quality Model was introduced in 1977. This model is
incorporated with many attributes, termed software factors, which
influence software. The model distinguishes between two levels of
quality attributes:
 Quality Factors
 Quality Criteria
Quality Factors: The higher-level quality attributes that can be accessed
directly are called quality factors. These attributes are external. The
attributes at this level are given more importance by the users and
managers.
Quality Criteria:
The lower or second-level quality attributes that can be
accessed either subjectively or objectively are called Quality Criteria.
These attributes are internal. Each quality factor has many second-
level quality attributes or quality criteria.

Product Operation

It includes five software quality factors, which are related to the

requirements that directly affect the operation of the software such as
operational performance, convenience, ease of usage, and correctness.
These factors help in providing a better user experience.
 Correctness: The extent to which software meets its requirements
specification.
 Efficiency: The number of hardware resources and code the
software, needs to perform a function.
 Integrity: The extent to which the software can control an
unauthorized person from accessing the data or software.
 Reliability: The extent to which software performs its intended
functions without failure.
 Usability: The extent of effort required to learn, operate, and
understand the functions of the software.

Product Revision

It includes three software quality factors, which are required for

testing and maintenance of the software. They provide ease of
maintenance, flexibility, and testing efforts to support the software to
be functional according to the needs and requirements of the user in
the future.
 Maintainability: The effort required to detect and correct an error
during maintenance.
 Flexibility: The effort needed to improve an operational software
program.
 Testability: The effort required to verify software to ensure that it
meets the specified requirements.

Product Transition
It includes three software quality factors, that allow the software to
adapt to the change of environments in the new platform or
technology from the previous.
 Portability: The effort required to transfer a program from one
platform to another.
 Re-usability: The extent to which the program’s code can be reused
in other applications.
 Interoperability: The effort required to integrate two systems.

Questions for Practice

1. Which of the following is not one of three software product aspects addressed by
McCall’s software quality factors? [UGC-NET 2017]
(A) Ability to undergo change
(B) Adaptability to new environments
(C) Operational characteristics
(D) Production costs and scheduling
Solution: Correct answer is (D).

2. Which one is not a product quality factor of McCall’s quality model?

(A) Product Revision
(B) Product Operation
(C) Product Specification
(D) Product Transition
Solution: Correct Answer is (C).

FAQs

1. What is McCall’s Quality Model?

Answer:
McCall’s Quality Model classifies all software requirements into 11 different types of
software quality factors.
2. What is the purpose of the Quality Model?
Answer:
The purpose of the Quality Model is to provide the basis for specifying quality requirements
and evaluating quality.
4. How is Boehm’s Quality Model better than McCall’s Quality Model?
Answer:
McCall’s Quality Model focuses on only high-level characteristics whereas Boehm’s Quality
Model works on a wide range of characteristics.
ISO/IEC 9126 in Software Engineering
ISO/IEC 9126 is an international standard proposed to make sure ‘quality of all software-
intensive products’ which includes a system like safety-critical where in case of failure of
software lives will be in jeopardy. ISO i.e. International Organization for
Standardization and IEC i.e. International Electrotechnical Commission have developed
ISO/IEC 9126 standards for software engineering → Product Quality to provide an all-
inclusive specification and evaluation model for the quality of the software product.

The standard is divided into 4 parts as depicted in the following

figure:

Parts of Standard

Part-1: Software Engineering: Product Quality “Quality model”: It describes the quality
model framework which explains relationships between different approaches to quality as
well as identifying quality characteristics and sub-characteristics of software products.
Part-2: Software Engineering: Product Quality “External Metrics”: Its use is to describe
external metrics that are used to measure characteristics and sub-characteristics which are
identified in part 1.
Part-3: Software Engineering: Product Quality “Internal Metrics”: Its use is to describe
internal metrics that are used to measure characteristics and sub-characteristics which are
identified in part 1.
Part-4: Software Engineering: Product Quality “Quality in use metrics”: Its use is to
identify metrics that are used to measure the effects of combined quality characteristics for
users.
From the above discussion, it is concluded that the first three parts are concerned with
describing and measuring the quality of software products, and the fourth part is concerned
with the quality of software products from the user’s point of view.
Furthermore, the first part i.e. the Quality model is concerned classified into two categories as
depicted in the following figure:
 Characteristics of Quality Model

Internal External Quality Part

It determines the quality of a software product through six characteristics which are
Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability. Each
characteristic is subdivided into related sub-characteristics which are also depicted in the
above example.
Functionality
The functions are those that will satisfy implied needs.
 Suitability
 Accuracy
 Interoperability
 Security
 Functionality Compliance
Reliability
A set of attributes that will bear on the capability of software to maintain the level of
performance.
 Maturity
 Fault Tolerance
 Recoverability
 Reliability Compliance
Usability
A set of attributes that bear on the effort needed for use by an implied set of users.
 Understandability
 Learnability
 Operability
 Attractiveness
 Usability Compliance
Efficiency
A set of attributes that bear on the relationship between the level of performance of the
software under stated conditions.
 Time Behavior
 Resource Utilization
 Efficiency Compliance
Maintainability
A set of attributes that bear on the effort needed to make specified modifications.
 Analyzability
 Changeability
 Stability
 Testability
 Maintainability Compliance
Portability
A set of attributes that bear on the ability of software to be transferred from one environment
to another.
 Adaptability
 Installability
 Co-existence
 Replaceability
 Portability Compliance
Quality in Use Model
It identifies the four quality characteristics.
 Effectiveness
 Productivity
 Safety
 Satisfaction
Questions For Practice
1. According to the ISO-9126 Standard Quality Model, match the attributes given in
List 1 with their definition in List-2. [UGC-NET CS 2019]
List-1 List-2

a. Functionality i. Relationship between level of performance and amount of resources

b. Reliability ii. Characteristics related to the achievement of the purpose

c. Efficiency iii. Efforts needed to make for improvement

d. Maintainability iv. The capability of software to maintain the performance of Software

Choose the correct option from the ones given below.

(A) a-i, b-ii, c-iii, d-iv
(B) a-ii, b-i, c-iv, d-iii
(C) a-ii, b-iv, c-i, d-iii
(D) a-i, b-ii, c-iv, d-iii
Solution: Correct Answer is (C).

Frequently Asked Questions

1. What is ISO 9126 used for?

Answer:
 ISO 9126 is a type of international software that is used for creating a solid framework for
assessing the software.
2. What are the characteristics of quality of ISO 9126?
Answer:
ISO 9126 determines the characteristics of the product via six characteristics that are
mentioned below.
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability

Quality Control : Meaning, Need, Types, Roles and Responsibilties


What is Quality Control?
Quality Control (QC) is a systematic process that plays a crucial role in ensuring the
consistent delivery of high-quality products or services. At its core, Quality Control involves
a set of activities and techniques designed to monitor, assess, and regulate various elements
of the production process, with the ultimate goal of meeting predetermined standards and
specifications. This comprehensive approach covers every stage, from the initial phases of
production to the final delivery of goods or services. By implementing Quality Control
measures, organizations can identify and rectify defects, errors, or deviations from
established standards, thereby guaranteeing the reliability and conformity of their offerings.
In essence, Quality Control encompasses a range of methodologies and tools, including
inspections, tests, and statistical analyses, aimed at validating that products or services meet
predefined quality benchmarks. This process is not only reactive, addressing issues after they
arise, but also proactive, incorporating preventive measures to minimize the occurrence of
defects. The effectiveness of QC lies in its ability to ensure that every output aligns with the
specified quality criteria, fostering customer satisfaction, regulatory compliance, and the
overall success of an organization in a competitive market.

Geeky Takeaways:
 Quality Control is a process through which a business seeks to ensure that product
quality is not compromised.
 Quality Control helps in determining whether they are within the specifications for the
final product.
 It is highly dependent on the product or industry for measuring quality.
 The food industry uses quality control measures to make sure customers do not get sick
from their products.
 Quality control provides safeguards to make sure damaged products do not end up with
customers.

Why is Quality Control Needed?

1. Customer Satisfaction: Quality Control is indispensable for ensuring that the final
products or services meet or exceed customer expectations. By maintaining high quality,
organizations can enhance customer satisfaction, build trust, and foster long-term
relationships. Satisfied customers are more likely to be repeat buyers and advocates for the
brand.
2. Compliance with Standards: Quality Control is needed to ensure that products or
services adhere to industry-specific standards and regulations. Meeting these standards not
only reflects a commitment to quality but also helps in avoiding legal issues and regulatory
penalties, ensuring ethical business practices.
3. Risk Mitigation: Another crucial is the role of Quality Control in risk reduction. It helps
in identifying and rectifying defects early in the production process, minimizing the
probability of costly recalls, product failures, and customer complaints. This, in turn,
safeguards the reputation of the company.
4. Cost Control: Quality Control is essential for controlling costs associated with defects and
errors. By detecting and addressing issues early on, organizations can avoid expensive
rework, minimize waste, and optimize resource utilization, contributing to overall operational
efficiency.
5. Continuous Improvement: Quality Control is necessary to instill a culture of continuous
improvement within an organization. Through the identification of areas for enhancement in
processes and products, Quality Control promotes ongoing learning and adaptation, fostering
innovation and competitiveness.
Why is Quality Control Important?
1. Brand Reputation: Maintaining a high level of quality through Quality Control practices
contributes significantly to building and sustaining a positive brand reputation. Consistency
in delivering reliable products or services enhances consumer trust, leading to brand loyalty
and positive word-of-mouth.
2. Customer Loyalty: Quality Control is important for fostering customer loyalty. When
customers experience consistent quality, they are more likely to remain loyal to a brand.
Loyalty, in turn, results in repeat business and increased customer lifetime value.
3. Competitive Advantage: Quality Control provides a distinct competitive advantage in the
market. Organizations that prioritize and achieve superior quality stand out from their
competitors, attracting discerning customers who are willing to pay a premium for reliability
and excellence.
4. Risk Mitigation: Quality Control is essential for risk mitigation. By identifying and
addressing potential issues before they escalate, organizations can prevent reputational
damage, legal complications, and financial losses. A robust Quality Control system acts as a
safety net against uncertainties.
5. Continuous Improvement: Quality Control contributes to a culture of continuous
improvement by systematically analyzing processes and outputs. This ongoing evaluation and
refinement result in increased efficiency, reduced waste, and the ability to adapt to changing
market conditions.

Types of Quality Control

1. Preventive Quality Control: Preventive QC focuses on identifying and addressing

potential issues before they occur in the production process. This involves implementing
measures such as employee training, proper equipment maintenance, and process
optimization to minimize the likelihood of defects.
2. Detective Quality Control: Detective QC involves identifying and correcting issues
during or after the production process. This may include inspections, testing, and monitoring
to catch defects that may have occurred despite preventive measures. The goal is to detect
and address problems promptly.
3. Statistical Quality Control: Statistical QC utilizes statistical methods to monitor and
control processes. This involves collecting and analyzing data to identify variations and
trends, allowing organizations to make informed decisions and adjustments to maintain
consistent quality.
4. On-site Quality Control: On-site QC involves conducting inspections and tests at the
production site. This ensures that products meet quality standards before they are released to
the market. On-site QC is particularly crucial in industries where variations in production
conditions can impact quality.
5. Off-site Quality Control: Off-site QC refers to inspections and tests conducted away from
the production site. This could involve sending samples to a third-party laboratory for testing,
and providing an independent assessment of product quality to ensure objectivity and
transparency.

Quality Control Process

1. Define Standards: Establishing clear and detailed quality standards is the initial step in
the Quality Control (QC) process. These standards serve as benchmarks against which
products or services are mostly evaluated. Defining precise criteria ensures a common
understanding within the organization and provides a basis for consistent quality assessment.
2. Plan Quality Control Activities: Once standards are in place, a comprehensive plan is
developed to outline the specific QC activities that need to be conducted. This plan includes
the frequency of inspections, testing protocols, and the responsibilities of various team
members. Planning ensures that QC efforts are systematic, thorough, and aligned with
organizational goals.
3. Execute Quality Control Activities: The planned QC activities are implemented during
the production process. This involves inspections, tests, and measurements conducted
according to the predetermined plan. Regular and systematic execution of these activities
helps in identifying deviations from established standards and ensures that quality is
monitored throughout the entire production cycle.
4. Evaluate Results: Data collected from inspections and tests are thoroughly evaluated to
determine whether the products or services meet the defined quality standards. This
evaluation may involve statistical analysis, trend identification, and comparison against
benchmarks. Understanding the results allows for informed decision-making regarding the
acceptability of the output.
5. Take Corrective Action: Based on the evaluation, any identified deviations or non-
conformities trigger corrective actions. These actions can range from immediate adjustments
in the production process to long-term process improvements. The goal is not only to address
current issues but also to prevent their recurrence in future productions.

What are the Benefits of Quality Control?

1. Consistency: One of the primary benefits of QC is the establishment and maintenance of

consistency in the quality of products or services. By adhering to predefined standards,
organizations ensure that each output meets the same level of excellence, fostering reliability
and predictability.
2. Cost Savings: QC contributes to cost savings by identifying and addressing defects early
in the production process. Early detection minimizes the need for expensive rework, reduces
waste, and optimizes resource utilization. As a result, operational costs associated with poor
quality are significantly lowered.
3. Customer Satisfaction: QC plays a pivotal role in enhancing customer satisfaction.
Products or services that consistently meet or exceed quality standards lead to satisfied
customers. This satisfaction not only ensures repeat business but also contributes to positive
word-of-mouth, attracting new customers.
4. Market Credibility: The consistent delivery of high-quality products or services enhances
the market credibility of an organization. A positive reputation for quality builds trust among
consumers, partners, and stakeholders. This credibility can be a powerful differentiator in a
competitive business landscape.
5. Continuous Improvement: QC fosters a culture of continuous improvement within an
organization. By regularly evaluating results and implementing corrective actions, companies
can identify areas for enhancement in processes and products. This commitment to ongoing
improvement ensures adaptability and competitiveness in the market.

Quality Control Roles and Responsibilities

1. Quality Control Manager: The Quality Control Manager oversees the entire QC process.
Responsibilities include defining quality standards, developing QC plans, and ensuring the
effective execution of QC activities. The manager also plays a crucial role in communicating
quality expectations across the organization.
2. Inspector/Tester: Inspectors and testers are responsible for conducting on-site inspections
and tests. They closely examine products or services to ensure they meet established
standards. These individuals play a hands-on role in identifying any deviations and contribute
to the overall quality assurance process.
3. Quality Analyst: Quality analysts are involved in analyzing data and results obtained from
QC activities. They use statistical methods and data analysis tools to identify trends, patterns,
and areas for improvement. Their insights contribute to informed decision-making and long-
term quality enhancement.
4. Process Improvement Specialist: This role focuses on identifying opportunities for
process improvement based on QC data. Process improvement specialists collaborate with
various teams to implement changes that enhance efficiency, reduce defects, and contribute to
overall quality optimization.
5. Training Coordination: Training coordinators are responsible for developing and
implementing training programs related to QC. They ensure that team members are
adequately trained in QC procedures, standards, and methodologies. Continuous training
contributes to a skilled and knowledgeable workforce.

Quality Control Methods

1. Inspection: Inspection involves a visual examination of products or services to ensure they

meet predefined quality standards. This method is commonly used in manufacturing,
construction, and various industries where the physical attributes of the product are critical.
2. Testing: Testing involves subjecting products or services to various tests to assess their
performance, durability, or functionality. This method is prevalent in industries such as
electronics, automotive, and software development, where the functionality and reliability of
products are paramount.
3. Statistical Sampling: Statistical sampling involves selecting a representative sample from
a larger population for testing. This method is widely used to conclude the entire production
batch based on the analysis of a smaller, statistically significant sample.
4. On-site Quality Control: On-site QC involves conducting inspections and tests directly at
the production site. This method ensures real-time monitoring of the production process,
allowing for immediate corrective actions if deviations from quality standards are identified.
5. Off-site Quality Control: Off-site QC involves sending samples or products to external
laboratories or third-party quality assurance providers for testing. This method provides an
independent assessment of quality and is often used when objectivity and impartiality are
crucial.

Quality Control Careers

1. Quality Control Engineer: Quality Control Engineers are professionals responsible for
designing, implementing, and managing quality control systems. They ensure adherence to
quality standards, analyze data, and identify areas for improvement in production processes.
2. Quality Inspector: Quality Inspectors play a hands-on role in conducting inspections and
tests on products during or after the production process. They are responsible for identifying
defects, ensuring compliance with standards, and maintaining quality records.
3. Data Analyst in Quality Control: Data Analysts in Quality Control focus on analyzing
data collected from QC activities. They use statistical methods and data analysis tools to
identify trends, patterns, and areas for improvement, contributing valuable insights to the
decision-making process.
4. Quality Assurance Coordinator: While related to Quality Control, Quality Assurance
Coordinators focus on developing and implementing overall quality assurance processes.
They work to prevent defects and ensure that processes are designed to produce consistent
and high-quality outputs.
5. Quality Control Manager: Quality Control Managers oversee the entire QC process
within an organization. They define quality standards, develop QC plans, and ensure effective
execution. Managers also play a key role in communicating quality expectations across the
organization.

Quality Control Vs. Quality Assurance

Basis Quality Control (QC) Quality Assurance (QA)

Emphasizes preventing
Emphasizes detecting and
Focus defects and improving
correcting defects.
processes.

Applied during or after the Applied before or during

Stage of Process
production process. the development process.

Involves checking Involves setting standards

Responsibility
products or services. and creating processes.

Ensures processes are

Ensures the end product
Goal designed for quality
meets quality standards.
outcomes.
 Basis Quality Control (QC) Quality Assurance (QA)

Narrow focus on specific Broad focus on overall

Scope
outputs. process improvement.

Frequently Asked Questions (FAQs)

1. Is Quality Control the same as Quality Assurance?

Answer:
No, QC and QA are distinct but related processes. QC focuses on detecting and correcting
defects in the final product, while QA focuses on preventing defects by establishing and
improving processes.
2. How does Quality Control contribute to profitability?
Answer:
QC contributes to profitability by reducing defects and rework, minimizing operational costs,
and enhancing customer satisfaction. High-quality products often lead to increased sales and
customer loyalty.
3. Can Quality Control be automated?
Answer:
Yes, certain QC processes can be automated using technologies such as machine vision,
sensors, and artificial intelligence. Automation helps improve efficiency and accuracy in
quality control.
4. What is the role of statistical methods in Quality Control?
Answer:
Statistical methods in QC, such as Six Sigma, help analyze data to identify patterns,
variations, and areas for improvement. These methods provide a quantitative approach to
ensuring consistent quality.
5. How does Quality Control benefit customer satisfaction?
Answer:
QC ensures that products or services consistently meet or exceed quality standards, leading
to higher customer satisfaction. Satisfied customers are more likely to be loyal and
recommend the brand to others.

Quality Assurance

What Is Quality Assurance?

The quality assurance process helps a business ensure its products meet the quality standards
set by the company or its industry. Another way to understand quality assurance (QA) is as a
company’s process for improving the quality of its products.

Many businesses view their QA program as a promise to internal stakeholders and customers
that the company will deliver high-quality products that provide a positive user experience.

What’s the Difference Between Quality Assurance vs. Quality Control?

Quality assurance is a broad process for preventing quality failures. The QA team is involved
in all stages of a product’s development: production, testing, packaging, and delivery. In
contrast, quality control (QC) is a narrower process. QC focuses on detecting mistakes,
errors, or missed requirements in a product.

The two key differences between QA and QC are:

1. QA is proactive vs. QC is reactive.

The QA team operates proactively. They seek to uncover and address the sources of quality
problems, such as human error or a business using the wrong materials. Whereas the QC
team is reactive, checking the product for mistakes or components not built to specification.

Here is another way to understand this distinction: QC seeks to catch quality errors, while QA
seeks to uncover and fix the issues that lead to quality errors.

2. QC takes place after development, while QA is ongoing.

The QC team performs their tests after the product team has built the product. So they are
looking only to catch errors and bugs before the company makes the product available to
customers. On the other hand, the QA team is working throughout the development process,
making sure each aspect of the product is on track to deliver a high-quality customer
experience.

What is risk management?

Risk management is the process of identifying, assessing and controlling financial, legal,
strategic and security risks to an organization’s capital and earnings. These threats, or risks,
could stem from a wide variety of sources, including financial uncertainty, legal liabilities,
strategic management errors, accidents and natural disasters.
Why is risk management important?

If an unforeseen event catches your organization unaware, the impact could be minor, such as
a small impact on your overhead costs. In a worst-case scenario, though, it could be
catastrophic and have serious ramifications, such as a significant financial burden or even the
closure of your business.

To reduce risk, an organization needs to apply resources to minimize, monitor and control the
impact of negative events while maximizing positive events. A consistent, systemic and
integrated approach to risk management can help determine how best to identify, manage and
mitigate significant risks.

A successful risk assessment program must meet legal, contractual, internal, social and
ethical goals, as well as monitor new technology-related regulations. By focusing attention on
risk and committing the necessary resources to control and mitigate risk, a business protects
itself from uncertainty, reduce costs and increase the likelihood of business continuity and
success.

Three important steps of the risk management process are risk identification, risk analysis and
assessment, and risk mitigation and monitoring.
Identifying risks
Risk identification is the process of identifying and assessing threats to an organization, its
operations and its workforce. For example, risk identification can include assessing IT
security threats such as malware and ransomware, accidents, natural disasters and other
potentially harmful events that could disrupt business operations.
Risk analysis and assessment
Risk analysis involves establishing the probability that a risk event might occur and the
potential outcome of each event. Risk evaluation compares the magnitude of each risk and
ranks them according to prominence and consequence.
Risk mitigation and monitoring
Risk mitigation refers to the process of planning and developing methods and options to
reduce threats to project objectives. A project team might implement risk mitigation
strategies to identify, monitor and evaluate risks and consequences inherent to completing a
specific project, such as new product creation. Risk mitigation also includes the actions put
into place to deal with issues and effects of those issues regarding a project.
Risk management is a nonstop process that adapts and changes over time. Repeating and
continually monitoring the processes can help assure maximum coverage of known and
unknown risks.

Risk response strategies and treatment

There are five commonly accepted strategies for addressing risk. The process begins with an
initial consideration of risk avoidance then proceeds to 3 additional avenues of addressing
risk (transfer, spreading and reduction). Ideally, these three avenues are employed in concert
with one another as part of a comprehensive strategy. Some residual risk may remain.

What are the most common responses to risk?

Risk avoidance

Avoidance is a method for mitigating risk by not participating in activities that may
negatively affect the organization. Not making an investment or starting a product line are
examples of such activities as they avoid the risk of loss.

Risk reduction

This method of risk management attempts to minimize the loss, rather than completely
eliminate it. While accepting the risk, it stays focused on keeping the loss contained and
preventing it from spreading. An example of this in health insurance is preventive care.

Risk sharing

When risks are shared, the possibility of loss is transferred from the individual to the group.
A corporation is a good example of risk sharing—several investors pool their capital and each
only bears a portion of the risk that the enterprise may fail.
Transferring risk

Contractually transferring a risk to a third-party, such as, insurance to cover possible property
damage or injury shifts the risks associated with the property from the owner to the insurance
company.

Risk acceptance and retention

After all risk sharing, risk transfer and risk reduction measures have been implemented, some
risk will remain since it is virtually impossible to eliminate all risk (except through risk
avoidance). This is called residual risk.

Limitations and risk management standards

Risk management standards set out a specific set of strategic processes that start with the
objectives of an organization and intend to identify risks and promote the mitigation of risks
through best practice.

Standards are often designed by agencies who are working together to promote common
goals, to help to ensure high-quality risk management processes. For example, the ISO
31 000 standard on risk management is an international standard that provides principles and
guidelines for effective risk management.

While adopting a risk management standard has its advantages, it is not without challenges.
The new standard might not easily fit into what you are doing already, so you could have to
introduce new ways of working. And the standards might need customizing to your industry
or business.

Software Reliability

Software Reliability means Operational reliability. It is described as the ability of a system

or component to perform its required functions under static conditions for a specific period.

Software reliability is also defined as the probability that a software system fulfills its
assigned task in a given environment for a predefined number of input cases, assuming that
the hardware and the input are free of error.

Software Reliability is an essential connect of software quality, composed with functionality,

usability, performance, serviceability, capability, installability, maintainability, and
documentation. Software Reliability is hard to achieve because the complexity of software
turn to be high. While any system with a high degree of complexity, containing software, will
be hard to reach a certain level of reliability, system developers tend to push complexity into
the software layer, with the speedy growth of system size and ease of doing so by upgrading
the software.

Project size Estimation Techniques – Software Engineering

Project size estimation is a crucial aspect of software engineering, as it helps in planning
and allocating resources for the project. Here are some of the popular project size
estimation techniques used in software engineering:

 Expert Judgment: In this technique, a group of experts in the relevant field estimates
the project size based on their experience and expertise. This technique is often used
when there is limited information available about the project.
 Analogous Estimation: This technique involves estimating the project size based on the
similarities between the current project and previously completed projects. This
technique is useful when historical data is available for similar projects.
 Bottom-up Estimation: In this technique, the project is divided into smaller modules or
tasks, and each task is estimated separately. The estimates are then aggregated to arrive
at the overall project estimate.
 Three-point Estimation: This technique involves estimating the project size using three
values: optimistic, pessimistic, and most likely. These values are then used to calculate
the expected project size using a formula such as the PERT formula.
 Function Points: This technique involves estimating the project size based on the
functionality provided by the software. Function points consider factors such as inputs,
outputs, inquiries, and files to arrive at the project size estimate.
 Use Case Points: This technique involves estimating the project size based on the
number of use cases that the software must support. Use case points consider factors
such as the complexity of each use case, the number of actors involved, and the number
of use cases.
 Parametric Estimation: For precise size estimation, mathematical models founded on
project parameters and historical data are used.
 COCOMO (Constructive Cost Model): It is an algorithmic model that estimates effort,
time, and cost in software development projects by taking into account a number of
different elements.
 Wideband Delphi: Consensus-based estimating method for balanced size estimations
that combines expert estimates from anonymous experts with cooperative conversations.
 Monte Carlo simulation: This technique, which works especially well for complicated
and unpredictable projects, estimates project size and analyses hazards using statistical
methods and random sampling.
Each of these techniques has its strengths and weaknesses, and the choice of technique
depends on various factors such as the project’s complexity, available data, and the expertise
of the team.

Importance of Project Size Estimation Techniques

 Resource Allocation: Appropriate distribution of financial and human resources is

ensured by accurate estimation.
 Risk management: Early risk assessment helps with mitigation techniques by taking
into account the complexity of the project.
 Time management: Facilitates the creation of realistic schedules and milestones for
efficient time management.
 Cost control and budgeting: Both the terms are closely related, which lowers the
possibility of cost overruns.
 Resource Allocation: Enables efficient task delegation and work allocation
optimization.
 Scope Definition: Defines the scope of a project, keeps project boundaries intact and
guards against scope creep.

Estimating the size of the Software

Estimation of the size of the software is an essential part of Software Project Management. It
helps the project manager to further predict the effort and time that will be needed to build
the project. Various measures are used in project size estimation. Some of these are:
 Lines of Code
 Number of entities in the ER diagram
 Total number of processes in detailed data flow diagram
 Function points
1. Lines of Code (LOC): As the name suggests, LOC counts the total number of lines of
source code in a project. The units of LOC are:
 KLOC- Thousand lines of code
 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind. The experts
use it to predict the required size of various components of software and then add them to get
the total size.
It’s tough to estimate LOC by analyzing the problem definition. Only after the whole code
has been developed can accurate LOC be estimated. This statistic is of little utility to project
managers because project planning must be completed before development activity can
begin.
Two separate source files having a similar number of lines may not require the same effort. A
file with complicated logic would take longer to create than one with simple logic. Proper
estimation may not be attainable based on LOC.
The length of time it takes to solve an issue is measured in LOC. This statistic will differ
greatly from one programmer to the next. A seasoned programmer can write the same logic in
fewer lines than a newbie coder.
Advantages
 Universally accepted and is used in many models like COCOMO.
 Estimation is closer to the developer’s perspective.
 Both people throughout the world utilize and accept it.
 At project completion, LOC is easily quantified.
 It has a specific connection to the result.
 Simple to use.
Disadvantages:
 Different programming languages contain a different number of lines.
 No proper industry standard exists for this technique.
 It is difficult to estimate the size using this technique in the early stages of the project.
 When platforms and languages are different, LOC cannot be used to normalize.
2. Number of entities in ER diagram: ER model provides a static view of the project. It
describes the entities and their relationships. The number of entities in ER model can be used
to measure the estimation of the size of the project. The number of entities depends on the
size of the project. This is because more entities needed more classes/structures thus leading
to more coding.
Advantages:
 Size estimation can be done during the initial stages of planning.
 The number of entities is independent of the programming technologies used.
 Disadvantages:
 No fixed standards exist. Some entities contribute more to project size than others.
 Just like FPA, it is less used in the cost estimation model. Hence, it must be converted to
LOC.

3. Total number of processes in detailed data flow diagram: Data Flow Diagram(DFD)
represents the functional view of software. The model depicts the main processes/functions
involved in software and the flow of data between them. Utilization of the number of
functions in DFD to predict software size. Already existing processes of similar type are
studied and used to estimate the size of the process. Sum of the estimated size of each process
gives the final estimated size.

Advantages:
 It is independent of the programming language.
 Each major process can be decomposed into smaller processes. This will increase the
accuracy of the estimation.

Disadvantages:
 Studying similar kinds of processes to estimate size takes additional time and effort.
 All software projects are not required for the construction of DFD.

4. Function Point Analysis: In this method, the number and type of functions supported by
the software are utilized to find FPC(function point count). The steps in function point
analysis are:
 Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find the Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).

Advantages:

 It can be easily used in the early stages of project planning.

 It is independent of the programming language.
 It can be used to compare different projects even if they use different
technologies(database, language, etc).

Disadvantages:

 It is not good for real-time systems and embedded systems.

 Many cost estimation models like COCOMO use LOC and hence FPC must be
converted to LOC.

Cost Estimation Models in Software Engineering


Cost estimation simply means a technique that is used to find out the cost estimates. The
cost estimate is the financial spend that is done on the efforts to develop and test software
in Software Engineering. Cost estimation models are some mathematical algorithms or
parametric equations that are used to estimate the cost of a product or a project. Various
techniques or models are available for cost estimation, also known as Cost Estimation
Models.

Cost Estimation Models as shown below :

Cost Estimation Models

1. Empirical Estimation Technique – Empirical estimation is a technique or model in

which empirically derived formulas are used for predicting the data that are a required
and essential part of the software project planning step. These techniques are usually
based on the data that is collected previously from a project and also based on some
guesses, prior experience with the development of similar types of projects, and
assumptions. It uses the size of the software to estimate the effort. In this technique, an
educated guess of project parameters is made. Hence, these models are based on
common sense. However, as there are many activities involved in empirical estimation
techniques, this technique is formalized. For example Delphi technique and Expert
Judgement technique.

2. Heuristic Technique – Heuristic word is derived from a Greek word that means “to
discover”. The heuristic technique is a technique or model that is used for solving
problems, learning, or discovery in the practical methods which are used for achieving
immediate goals. These techniques are flexible and simple for taking quick decisions
through shortcuts and good enough calculations, most probably when working with
complex data. But the decisions that are made using this technique are necessary to be
optimal. In this technique, the relationship among different project parameters is
expressed using mathematical equations. The popular heuristic technique is given
by Constructive Cost Model (COCOMO). This technique is also used to increase or
speed up the analysis and investment decisions.

3. Analytical Estimation Technique – Analytical estimation is a type of technique that is

used to measure work. In this technique, firstly the task is divided or broken down into
its basic component operations or elements for analyzing. Second, if the standard time is
available from some other source, then these sources are applied to each element or
component of work. Third, if there is no such time available, then the work is estimated
based on the experience of the work. In this technique, results are derived by making
certain basic assumptions about the project. Hence, the analytical estimation technique
has some scientific basis. Halstead’s software science is based on an analytical
estimation model.
 Other Cost Estimation Models
1. Function Point Analysis (FPA): This technique counts the number and complexity of
functions that a piece of software can perform to determine how functional and
sophisticated it is. The effort needed for development, testing and maintenance can be
estimated using this model.
2. Putnam Model: This model is a parametric estimation model that estimates effort,
time and faults by taking into account the size of the the programme, the expertise of the
development team and other project-specific characteristics.
3. Price-to-Win Estimation: Often utilized in competitive bidding, this model is
concerned with projecting the expenses associated with developing a particular software
project in order to secure a contract. It involves looking at market dynamics and
competitors.
4. Models Based on Machine Learning: Custom cost estimating models can be built
using machine learning techniques including neural networks, regression analysis and
decision trees. These models are based on past project data. These models are flexible
enough to adjust to changing data and project-specific features.
5. Function Points Model (IFPUG): A standardized technique for gauging the
functionality of software using function points is offered by the International Function
Point Users Group (IFPUG). It is employed to calculate the effort required for software
development and maintenance.

COCOMO Model – Software Engineering


Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e., the number of
Lines of Code. This article focuses on discussing the Cocomo Model in detail.

What is the Cocomo Model?

The Cocomo Model is a procedural cost estimate model for software projects and is often
used as a process of reliably predicting the various parameters associated with making a
project such as size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981
and is based on the study of 63 projects, which makes it one of the best-documented models.
The key parameters that define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort and schedule:
1. Effort: Amount of labor that will be required to complete a task. It is measured in
person-months units.
2. Schedule: This simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of time
such as weeks, and months.
1. Organic
A software project is said to be an organic type if the team size required is adequately small,
the problem is well understood and has been solved in the past and also the team members
have a nominal experience regarding the problem.
2. Semi-detached
A software project is said to be a Semi-detached type if the vital characteristics such as team
size, experience, and knowledge of the various programming environments lie in between
organic and embedded. The projects classified as Semi-Detached are comparatively less
familiar and difficult to develop compared to the organic ones and require more experience
better guidance and creativity. Eg: Compilers or different Embedded Systems can be
considered Semi-Detached types.
3. Embedded
A software project requiring the highest level of complexity, creativity, and experience
requirement falls under this category. Such software requires a larger team size than the other
two models and also the developers need to be sufficiently experienced and creative to
develop such complex models.

Detailed Structure of COCOMO Model

Detailed COCOMO incorporates all characteristics of the intermediate version with an

assessment of the cost driver’s impact on each step of the software engineering process. The
detailed model uses different effort multipliers for each cost driver attribute. 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:

1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
 Phases of COCOMO Model

Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of the constant to
be used in subsequent calculations. These characteristics of different system types are
mentioned below. Boehm’s definition of organic, semidetached, and embedded systems:

Importance of the COCOMO Model

1. Cost Estimation: To help with resource planning and project budgeting, COCOMO
offers a methodical approach to software development cost estimation.
2. Resource Management: By taking team experience, project size, and complexity into
account, the model helps with efficient resource allocation.
3. Project Planning: COCOMO assists in developing practical project plans that include
attainable objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO assists in identifying
and mitigating potential hazards by including risk elements.
5. Support for Decisions: During project planning, the model provides a quantitative
foundation for choices about scope, priorities, and resource allocation.
6. Benchmarking: To compare and assess various software development projects to
industry standards, COCOMO offers a benchmark.
7. Resource Optimization: The model helps to maximize the use of resources, which
raises productivity and lowers costs.

Types of COCOMO Model

1. Basic Model
E = a(KLOC)^b
Time = c(Effort)^d
Person required = Effort/ time
The above formula is used for the cost estimation of the basic COCOMO model and also is
used in the subsequent models.

2. Intermediate Model
The basic Cocomo model assumes that the effort is only a function of the number of lines of
code and some constants evaluated according to the different software systems. However, in
reality, no system’s effort and schedule can be solely calculated based on Lines of Code. For
that, various other factors such as reliability, experience, and Capability. These factors are
known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost
estimation. Classification of Cost Drivers and their Attributes:
Product attributes:
1. Required software reliability extent
2. Size of the application database
3. The complexity of the product
4. Run-time performance constraints
5. Memory constraints
6. The volatility of the virtual machine environment
7. Required turnabout time
8. Analyst capability
9. Software engineering capability
10. Application experience
11. Virtual machine experience
12. Programming language experience
13. Use of software tools
14. Application of software engineering methods
15. Required development schedule

Advantages of the COCOMO Model

1. Systematic cost estimation: Provides a systematic way to estimate the cost and effort of
a software project.
 2. Helps to estimate cost and effort: This can be used to estimate the cost and effort of a
software project at different stages of the development process.
3. Helps in high-impact factors: Helps in identifying the factors that have the greatest
impact on the cost and effort of a software project.
4. Helps to evaluate the feasibility of a project: This can be used to evaluate the
feasibility of a software project by estimating the cost and effort required to complete it.

Disadvantages of the COCOMO Model

1. Assumes project size as the main factor: Assumes that the size of the software is the
main factor that determines the cost and effort of a software project, which may not
always be the case.
2. Does not count development team-specific characteristics: Does not take into account
the specific characteristics of the development team, which can have a significant impact
on the cost and effort of a software project.
3. Not enough precise cost and effort estimate: This does not provide a precise estimate
of the cost and effort of a software project, as it is based on assumptions and averages.

For both software engineers and project managers, COCOMO is an applicable and useful tool
at a time when effective project planning is essential to success. Its continued application and
adaption in a variety of settings show how valuable it is in the always-changing field of
software development.

Short note on Project Scheduling


A schedule in your project’s time table actually consists of sequenced activities and
milestones that are needed to be delivered under a given period of time.
Project schedule simply means a mechanism that is used to communicate and know about
that tasks are needed and has to be done or performed and which organizational resources
will be given or allocated to these tasks and in what time duration or time frame work is
needed to be performed. Effective project scheduling leads to success of project, reduced
cost, and increased customer satisfaction. Scheduling in project management means to list out
activities, deliverables, and milestones within a project that are delivered. It contains more
notes than your average weekly planner notes. The most common and important form of
project schedule is Gantt chart.

Process :
The manager needs to estimate time and resources of project while scheduling project. All
activities in project must be arranged in a coherent sequence that means activities should be
arranged in a logical and well-organized manner for easy to understand. Initial estimates of
project can be made optimistically which means estimates can be made when all favorable
things will happen and no threats or problems take place.
The total work is separated or divided into various small activities or tasks during project
schedule. Then, Project manager will decide time required for each activity or task to get
completed. Even some activities are conducted and performed in parallel for efficient
performance. The project manager should be aware of fact that each stage of project is not
problem-free.
Problems arise during Project Development Stage :
 People may leave or remain absent during particular stage of development.
 Hardware may get failed while performing.
 Software resource that is required may not be available at present, etc.
The project schedule is represented as set of chart in which work-breakdown structure and
dependencies within various activities are represented. To accomplish and complete project
within a given schedule, required resources must be available when they are needed.
Therefore, resource estimation should be done before starting development.
Resources required for Development of Project :
 Human effort
 Sufficient disk space on server
 Specialized hardware
 Software technology
 Travel allowance required by project staff, etc.
Advantages of Project Scheduling :
There are several advantages provided by project schedule in our project management:
 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.

What is a Timeline Chart?

A timeline chart is a visual representation of a series of events and can describe

literally everything that happened or will happen in a given period of time. It
doesn’t matter if it is significant events in World War II or planned activities in
a marketing campaign.

The main aim of timeline chart is to make it easier to capture a process as a

sequence of events and – as such – to understand all dependencies within a
project, estimating the time that it takes every step or money that will be needed
to complete it.
 Timeline charts are commonly used to oversee team workload and grasping
the overall progress in time. Additionally, timeline chart can highlight critical
events and display milestones, and visualize the ownerships of particular stages
or tasks.

Examples of timeline chart:

 Standard timeline chart

 Gantt chart
 Time series graph

Verification and Validation in Software Engineering


Verification and Validation is the process of investigating whether a software system
satisfies specifications and standards and fulfills the required purpose. Barry
Boehm described verification and validation as the following:

Verification: Are we building the product right?

Validation: Are we building the right product?
Verification
Verification is the process of checking that software achieves its goal without any bugs. It is
the process to ensure whether the product that is developed is right or not. It verifies whether
the developed product fulfills the requirements that we have. Verification is simply known
as Static Testing.
Static Testing
Verification Testing is known as Static Testing and it can be simply termed as checking
whether we are developing the right product or not and also whether our software is fulfilling
the customer’s requirement or not. Here are some of the activities that are involved in
verification.
 Inspections
 Reviews
 Walkthroughs
 Desk-checking

Validation

Validation is the process of checking whether the software product is up to the mark or in
other words product has high-level requirements. It is the process of checking the validation
of the product i.e. it checks what we are developing is the right product. it is a validation of
actual and expected products. Validation is simply known as Dynamic Testing.

Dynamic Testing
Validation Testing is known as Dynamic Testing in which we examine whether we have
developed the product right or not and also about the business needs of the client. Here are
some of the activities that are involved in Validation.
1. Black Box Testing
2. White Box Testing
3. Unit Testing
4. Integration Testing

Questions For Practice

1. Software validation mainly checks for inconsistencies between [UGC NET 2019]
(A) Use cases and user requirements
(B) Implementation and system design blueprints
(C) Detailed specifications and user requirements
(D) Function specifications and use cases
Answer: Correct Answer is (C).
For more, refer to UGC-NET | NTA UGC NET 2019 June – II | Question 26
2. Complete each of the following sentences in List-1 on the left-hand side by filling in
the word or phrase from List-2 on the right-hand side that best completes the sentence.
[UGC-NET 2017]
List-1 List-2

i. Determining whether you have built the right

A. Software Testing
system is called _______.

ii. Determining whether you have built the system

B. Software Verification
right is called _______.

C. Software debugging the

iii. ______ is the process of demonstrating.
existence of defects

iv. ______ is the process of discovering the cause of

D. Software Validation
a defect and fixing it.

(A) i – B, ii – D, iii – A, iv – C
(B) i – B, ii – D, iii – C, iv – A
(C) i – D, ii – B, iii – C, iv – A
(D) i – D, ii – B, iii – A, iv – C
Solution: Correct Answer is (D).
3. Which type of testing is typically associated with software verification?
(A) Regression testing
(B) Usability testing
(C) Alpha testing
(D) User acceptance testing
Solution: Correct Answer is (A).

Frequently Asked Questions

 1. How does automated testing fit into the verification and validation process?
Answer:
Tools and Scropts present in Automated Testing helps in improving the efficiency of
verification and validation. It helps in automating repetitive test cases, reducing human error,
and providing rapid feedback on code changes.
2. List some challenges in Verification and Validation Process?
Answer:
Some of the challenges in verification and validation: Some of the challenges in verification
and Validation is listed below. the creation of test cases, handling difficult complex
interaction, clear and unambiguous requirements, creating comprehensive test cases, handling
complex software interactions, managing testing environments, and dealing with time and
resources.
Software Testing – Bug vs Defect vs Error vs Fault vs Failure

Software Testing defines a set of procedures and methods that check whether the actual
software product matches with expected requirements, thereby ensuring that the product is
Defect free. There are a set of procedures that needs to be in mind while testing the software
manually or by using automated procedures. The main purpose of software testing is to
identify errors, deficiencies, or missing requirements with respect to actual requirements.
Software Testing is Important because if there are any bugs or errors in the software, they can
be identified early and can be solved before the delivery of the software product. The article
focuses on discussing the difference between bug, defect, error, fault, and failure.
What is a Bug?
A bug refers to defects which means that the software product or the application is not
working as per the adhered requirements set. When we have any type of logical error, it
causes our code to break, which results in a bug. It is now that the Automation/ Manual Test
Engineers describe this situation as a bug.
 A bug once detected can be reproduced with the help of standard bug-reporting
templates.
 Major bugs are treated as prioritized and urgent especially when there is a risk of user
dissatisfaction.
 The most common type of bug is a crash.
 Typos are also bugs that seem tiny but are capable of creating disastrous results.
What is a Defect?
A defect refers to a situation when the application is not working as per the requirement and
the actual and expected result of the application or software are not in sync with each other.
 The defect is an issue in application coding that can affect the whole program.
 It represents the efficiency and inability of the application to meet the criteria and
prevent the software from performing the desired work.
 The defect can arise when a developer makes major or minor mistakes during the
development phase.
What is an Error?
Error is a situation that happens when the Development team or the developer fails to
understand a requirement definition and hence that misunderstanding gets translated into
buggy code. This situation is referred to as an Error and is mainly a term coined by the
developers.
 Errors are generated due to wrong logic, syntax, or loop that can impact the end-user
experience.
 It is calculated by differentiating between the expected results and the actual results.
 It raises due to several reasons like design issues, coding issues, or system specification
issues and leads to issues in the application.
What is a Fault?
Sometimes due to certain factors such as Lack of resources or not following proper steps
Fault occurs in software which means that the logic was not incorporated to handle the errors
in the application. This is an undesirable situation, but it mainly happens due to invalid
documented steps or a lack of data definitions.
 It is an unintended behavior by an application program.
 It causes a warning in the program.
 If a fault is left untreated it may lead to failure in the working of the deployed code.
 A minor fault in some cases may lead to high-end error.
 There are several ways to prevent faults like adopting programming techniques,
development methodologies, peer review, and code analysis.
What is a Failure?
Failure is the accumulation of several defects that ultimately lead to Software failure and
results in the loss of information in critical modules thereby making the system unresponsive.
Generally, such situations happen very rarely because before releasing a product all possible
scenarios and test cases for the code are simulated. Failure is detected by end-users once they
face a particular issue in the software.
 Failure can happen due to human errors or can also be caused intentionally in the system
by an individual.
 It is a term that comes after the production stage of the software.
 It can be identified in the application when the defective part is executed.
A simple diagram depicting Bug vs Defect vs Fault vs Failure:

Bug vs Defect vs Error vs Fault vs Failure

Some of the vital differences between bug, defect, fault, error, and failure are listed in the
below table:

Basis Bug Defect Fault Error Failure

A bug refers A Fault is a An Error is a Failure is the

A Defect is a
to defects state that mistake made in accumulation
deviation
which means causes the the code due to of several
between the
that the software to which defects that
actual and
Definiti software fail and compilation or ultimately
expected output
on product or the therefore it execution fails, lead to
Basis Bug Defect Fault Error Failure

application is does not Software

not working achieve its failure and
as per the necessary results in the
adhered function. loss of
requirements information
set in critical
modules
thereby
making the
system
unresponsive.

The defect is
The failure is
identified by
found by the
The Testers
Human Developers and test engineer
Test And is resolved
mistakes lead automation test during the
Engineers by developers
to fault. engineers development
in the
cycle of
Raised development
SDLC
by phase of SDLC.

 Business
Logic
Faults
Defects are  Syntactic
 Function
classified as Error
al and
follows:  UI screen
Logical
Based on error
Faults
 Logical Priority:  Error
 Graphica
bugs  High handling
l User
 Algorith  Medium error
Interface NA
mic bugs  Low  Flow control
(GUI)
 Resource Based on error
Faults
bugs Severity:  Calculation
 Performa
 Critical error
nce
 Major  Hardware
Faults
 Minor error
 Security
 Trivial
Differe Faults
nt  Hardwar
types e Faults

Reason  Missing  Receiving  Wrong  Error in  Environ

s Logic & design of code. ment
 Basis Bug Defect Fault Error Failure

behind  Erroneous providing the data  Inability to variables

Logic incorrect definitio compile/exec  System
 Redundan input n ute a Errors
t codes  Coding/Lo processe program  Human
gical Error s.  Ambiguity in Error
leading to  An code logic
the irregulari  Misundersta
breakdown ty in nding of
of software Logic or requirements
gaps in  Faulty
the design and
software architecture
leads to  Logical error
the non-
functioni
ng of the
software.

 Implemen  Peer
ting Test-  Implementi review
driven ng Out-of- of the
developm the-box Test  Conduct peer
ent. programmi documen reviews and
 Adjusting ng ts and code-reviews
enhanced methods. requirem  Need for
developm  Proper ents. validation of
ent usage of  Verifyin bug fixes
practices primary g the and
and and correct correctne enhancing
evaluatio software ss of the overall
Way to n of coding software quality of the
prevent cleanline practices. design
the ss of the and
reasons code. coding.

Difference between Unit Testing and Integration Testing


Unit Testing: Unit Testing is a type of software testing where individual software
components are tested. Unit Testing of the software product is carried out during the
development of an application. An individual component may be either an individual
function or a procedure. Unit Testing is typically performed by the developer. It is a testing
method using which every independent module are tested to determine if there is any issue by
the developer himself.
Integration Testing: Integration testing is the process of testing the interface between two
software units or modules. Its focus is on determining the correctness of the interface.
Integration testing aims to expose faults in the interaction between integrated units. Once all
the modules have been unit tested, integration testing is performed.

Difference between Unit and Integration Testing:

S.
No. Unit Testing Integration Testing

In unit testing, each module of the In integration testing, all modules of

1.
software is tested separately. the software are tested combined.

In unit testing tester knows the internal Integration testing doesn’t know the
2.
design of the software. internal design of the software.

Unit testing is performed first of all Integration testing is performed after

3.
testing processes. unit testing and before system testing.

4. Unit testing is white box testing. Integration testing is black box testing.

Unit testing is performed by the Integration testing is performed by the

5.
developer. tester.

Detection of defects in unit testing is Detection of defects in integration

6.
easy. testing is difficult.

It tests parts of the project without It tests only after the completion of all
7.
waiting for others to be completed. parts.

8. Unit testing is less costly. Integration testing is more costly.

Unit testing is responsible to observe Error detection takes place when

9. only the functionality of the individual modules are integrated to create an
units. overall system.

10. Module specification is done initially. Interface specification is done initially.

The proper working of your code with The proper working of your code with
11. the external dependencies is not the external dependencies is ensured by
ensured by unit testing. integration testing.
 S.
No. Unit Testing Integration Testing

12. Maintenance is cost effective. Maintenance is expensive.

Fast execution as compared to Its speed is slow because of the

13.
integration testing. integration of modules.

Integration testing results in the

Unit testing results in in-depth exposure
14. integration structure’s detailed
to the code.
visibility.

Differences between Black Box Testing and White Box Testing


Software Testing is the most important part of SDLC. The primary objective of software
testing is to identify defects, and errors and check the quality of software. Two key
techniques to achieve this goal this are black box testing and white box testing. Black box
testing and white box testing are the two most commonly used techniques in software testing,
they have different perspectives and methods to ensure the quality of software.
What is Black Box Testing?
Black-box testing is a type of software testing in which the tester is not concerned with the
internal knowledge or implementation details of the software but rather focuses on validating
the functionality based on the provided specifications or requirements. The tester only
focuses on the input and output of the software.
What is White Box Testing?
White box testing techniques analyze the internal structures the used data structures, internal
design, code structure, and the working of the software rather than just the functionality as in
black box testing. It is also called glass box testing or clear box testing or structural testing.
White Box Testing is also known as transparent testing or open box testing.

Difference between Black Box Testing and White Box Testing

Parameters Black Box Testing White Box Testing

Black Box Testing is a way of White Box Testing is a way of

software testing in which the testing the software in which the
internal structure or the program or tester has knowledge about the
the code is hidden and nothing is internal structure or the code or
Definition known about it. the program of the software.

Testing Black box testing is mainly focused White box testing is mainly
Parameters Black Box Testing White Box Testing

objectives on testing the functionality of the focused on ensuring that the

software, ensuring that it meets the internal code of the software is
requirements and specifications. correct and efficient.

Black box testing uses methods

White box testing uses methods
like equivalence
like control flow testing, data
partitioning, boundary value
flow testing and statement
analysis, and error guessing to
coverage testing.
Testing methods create test cases.

Black box testing does not require

any knowledge of the internal White box testing requires
workings of the software, and can knowledge of programming
be performed by testers who are not languages, software architecture
familiar with programming and design patterns.
Knowledge level languages.

White box testing is used for

Black box testing is generally used
testing the software at the unit
for testing the software at the
level, integration level and
functional level.
Scope system level.

Implementation of code is not Code implementation is

Implementation needed for black box testing. necessary for white box testing.

Black Box Testing is mostly done White Box Testing is mostly

Done By by software testers. done by software developers.

Black Box Testing can be referred

White Box Testing is the inner or
to as outer or external software
the internal software testing.
Terminology testing.

Black Box Testing is a functional White Box Testing is a structural

Testing Level test of the software. test of the software.

Black Box testing can be initiated White Box testing of software is

Testing based on the requirement started after a detail design
Initiation specifications document. document.
Parameters Black Box Testing White Box Testing

No knowledge of programming is It is mandatory to have

Programming required. knowledge of programming.

Black Box Testing is the behavior White Box Testing is the logic
Testing Focus testing of the software. testing of the software.

Black Box Testing is applicable to White Box Testing is generally

the higher levels of testing of applicable to the lower levels of
Applicability software. software testing.

Alternative Black Box Testing is also called White Box Testing is also called
Names closed testing. as clear box testing.

Time Black Box Testing is least time White Box Testing is most time
Consumption consuming. consuming.

Suitable for
Black Box Testing is not suitable or White Box Testing is suitable for
Algorithm
preferred for algorithm testing. algorithm testing.
Testing

Data domains along with inner or

Can be done by trial and error ways
internal boundaries can be better
and methods.
Approach tested.

Search something on google by By input to check and verify

Example using keywords loops

Types of Black Box Testing: Types of White Box Testing:

 Functional Testing  Path Testing
 Non-functional testing  Loop Testing
Types  Regression Testing  Condition testing

It is comparatively more
It is less exhaustive as compared to
exhaustive than black box
white box testing.
Exhaustiveness testing.

Frequently Asked Questions (FAQs) on Differences between Black Box Testing vs

White Box Testing
When to use black box testing?
 Black Box Testing is commonly used to evaluate the functionality, security, performance, and
other aspects of an application.
Is Black Box Testing QA?
Black Box Testing is mostly done by QA Team.
Is Black Box Testing TDD?
No, Black Box Testing is BDD and White Box Testing is TDD.
Basis Path Testing in Software Testing


Prerequisite – Path Testing Basis Path Testing is a white-box testing technique based on the
control structure of a program or a module. Using this structure, a control flow graph is
prepared and the various possible paths present in the graph are executed as a part of testing.
Therefore, by definition, Basis path testing is a technique of selecting the paths in the control
flow graph, that provide a basis set of execution paths through the program or module. Since
this testing is based on the control structure of the program, it requires complete knowledge
of the program’s structure. To design test cases using this technique, four steps are followed :
1. Construct the Control Flow Graph
2. Compute the Cyclomatic Complexity of the Graph
3. Identify the Independent Paths
4. Design Test cases from Independent Paths
Let’s understand each step one by one. 1. Control Flow Graph – A control flow graph (or
simply, flow graph) is a directed graph which represents the control structure of a program or
module. A control flow graph (V, E) has V number of nodes/vertices and E number of edges
in it. A control graph can also have :
 Junction Node – a node with more than one arrow entering it.
 Decision Node – a node with more than one arrow leaving it.
 Region – area bounded by edges and nodes (area outside the graph is also counted as a
region.).

Below are the notations used while constructing a flow graph :

 Sequential Statements –
 If – Then – Else –

 Do – While –
 While – Do –
 Switch – Case –

Cyclomatic Complexity – The cyclomatic complexity V(G) is said to be a measure of the

logical complexity of a program. It can be calculated using three different formulae :
1. Formula based on edges and nodes :
V(G) = e - n + 2*P
1. Where, e is number of edges, n is number of vertices, P is number of connected
components. For example, consider first graph given above,
where, e = 4, n = 4 and p = 1
So,
Cyclomatic complexity V(G)
=4-4+2*1
=2
1. Formula based on Decision Nodes :
V(G) = d + P
1. where, d is number of decision nodes, P is number of connected nodes. For example,
consider first graph given above,
where, d = 1 and p = 1

So,
Cyclomatic Complexity V(G)
=1+1
=2
1. Formula based on Regions :
V(G) = number of regions in the graph
1. For example, consider first graph given above,
Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for Region 2)
=2
Hence, using all the three above formulae, the cyclomatic complexity obtained remains same.
All these three formulae can be used to compute and verify the cyclomatic complexity of the
flow graph. Note –
1. For one function [e.g. Main( ) or Factorial( ) ], only one flow graph is constructed. If in a
program, there are multiple functions, then a separate flow graph is constructed for each
one of them. Also, in the cyclomatic complexity formula, the value of ‘p’ is set
depending of the number of graphs present in total.
2. If a decision node has exactly two arrows leaving it, then it is counted as one decision
node. However, if there are more than 2 arrows leaving a decision node, it is computed
using this formula :
d=k-1
1. Here, k is number of arrows leaving the decision node.
Independent Paths : An independent path in the control flow graph is the one which
introduces at least one new edge that has not been traversed before the path is defined. The
cyclomatic complexity gives the number of independent paths present in a flow graph. This is
because the cyclomatic complexity is used as an upper-bound for the number of tests that
should be executed in order to make sure that all the statements in the program have been
executed at least once. Consider first graph given above here the independent paths would be
 2 because number of independent paths is equal to the cyclomatic complexity. So, the
independent paths in above first given graph :
 Path 1:
A -> B
 Path 2:
C -> D
Note – Independent paths are not unique. In other words, if for a graph the cyclomatic
complexity comes out be N, then there is a possibility of obtaining two different sets of paths
which are independent in nature. Design Test Cases : Finally, after obtaining the
independent paths, test cases can be designed where each test case represents one or more
independent paths. Advantages : Basis Path Testing can be applicable in the following cases:
1. More Coverage – Basis path testing provides the best code coverage as it aims to
achieve maximum logic coverage instead of maximum path coverage. This results in an
overall thorough testing of the code.
2. Maintenance Testing – When a software is modified, it is still necessary to test the
changes made in the software which as a result, requires path testing.
3. Unit Testing – When a developer writes the code, he or she tests the structure of the
program or module themselves first. This is why basis path testing requires enough
knowledge about the structure of the code.
4. Integration Testing – When one module calls other modules, there are high chances of
Interface errors. In order to avoid the case of such errors, path testing is performed to test
all the paths on the interfaces of the modules.
5. Testing Effort – Since the basis path testing technique takes into account the complexity
of the software (i.e., program or module) while computing the cyclomatic complexity,
therefore it is intuitive to note that testing effort in case of basis path testing is directly
proportional to the complexity of the software or program.

Control Structure Testing


Control structure testing is used to increase the coverage area by testing various control
structures present in the program. The different types of testing performed under control
structure testing are as follows-
1. Condition Testing
2. Data Flow Testing
3. Loop Testing

1. Condition Testing : Condition testing is a test cased design method, which ensures that
the logical condition and decision statements are free from errors. The errors present in
logical conditions can be incorrect boolean operators, missing parenthesis in a booleans
expression, error in relational operators, arithmetic expressions, and so on. The common
types of logical conditions that are tested using condition testing are-
1. A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are arithmetic expressions and
‘OP’ is an operator.
2. A simple condition like any relational expression preceded by a NOT (~) operator. For
example, (~E1) where ‘E1’ is an arithmetic expression and ‘a’ denotes NOT operator.
3. A compound condition consists of two or more simple conditions, Boolean operator, and
parenthesis. For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote arithmetic
expression and ‘&’ and ‘|’ denote AND or OR operators.
4. A Boolean expression consists of operands and a Boolean operator like ‘AND’, OR,
NOT. For example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’ denote operands
and | denotes OR operator.

2. Data Flow Testing : The data flow test method chooses the test path of a program based
on the locations of the definitions and uses all the variables in the program. The data flow test
approach is depicted as follows suppose each statement in a program is assigned a unique
statement number and that theme function cannot modify its parameters or global variables.
For example, with S as its statement number.
DEF (S) = {X | Statement S has a definition of X}
USE (S) = {X | Statement S has a use of X}
If statement S is an if loop statement, them its DEF set is empty and its USE set depends on
the state of statement S. The definition of the variable X at statement S is called the line of
statement S’ if the statement is any way from S to statement S’ then there is no other
definition of X. A definition use (DU) chain of variable X has the form [X, S, S’], where S
and S’ denote statement numbers, X is in DEF(S) and USE(S’), and the definition of X in
statement S is line at statement S’. A simple data flow test approach requires that each DU
chain be covered at least once. This approach is known as the DU test approach. The DU
testing does not ensure coverage of all branches of a program. However, a branch is not
guaranteed to be covered by DU testing only in rare cases such as then in which the other
construct does not have any certainty of any variable in its later part and the other part is not
present. Data flow testing strategies are appropriate for choosing test paths of a program
containing nested if and loop statements. 3. Loop Testing : Loop testing is actually a white
box testing technique. It specifically focuses on the validity of loop construction. Following
are the types of loops.
1. Simple Loop – The following set of test can be applied to simple loops, where the
maximum allowable number through the loop is n.
1. Skip the entire loop.
2. Traverse the loop only once.
3. Traverse the loop two times.
4. Make p passes through the loop where p<n.
5. Traverse the loop n-1, n, n+1 times.
2. Concatenated Loops – If loops are not dependent on each other, contact loops can be
tested using the approach used in simple loops. if the loops are interdependent, the steps
 are followed in nested loops.

3. Nested Loops – Loops within loops are called as nested loops. when testing nested
loops, the number of tested increases as level nesting increases. The following steps for
testing nested loops are as follows-
1. Start with inner loop. set all other loops to minimum values.
2. Conduct simple loop testing on inner loop.
3. Work outwards.
4. Continue until all loops tested.
4. Unstructured loops – This type of loops should be redesigned, whenever possible, to
reflect the use of unstructured the structured programming constructs.
Test case derivation techniques provide a structured approach to designing test cases that
effectively cover various aspects of the software under test. These techniques help testers to
identify test scenarios, input data, and expected results, ensuring that the software's behavior
aligns with the specified requirements.

Common Test Case Derivation Techniques:

1. Equivalence Partitioning: This technique divides the input data into partitions
or groups based on similar behavior. Test cases are designed to cover each
partition, ensuring that all possible input scenarios are considered.

2. Boundary Value Analysis: This technique focuses on testing the boundaries or

limits of input data ranges. Test cases are designed to cover the minimum,
maximum, and values just within and outside the boundaries, ensuring that the
software handles extreme values correctly.

3. Decision Table Testing: This technique utilizes a table format to represent

complex combinations of input conditions and their corresponding outputs. Test
cases are derived from the table, ensuring that all possible decision paths are
tested.
 4. State Transition Testing: This technique focuses on testing the transitions
between different states of the software. Test cases are designed to cover all
possible state transitions, ensuring that the software behaves correctly in each
state and during transitions.

Benefits of Test Case Derivation Techniques:

1. Improved Test Coverage: Derivation techniques ensure that test cases cover a
wide range of input scenarios, functionalities, and potential error conditions.

2. Early Defect Detection: By identifying and testing potential defects early in the
development cycle, derivation techniques help reduce the cost of fixing defects
later.

3. Enhanced Test Efficiency: Derivation techniques provide a systematic

approach to test case design, reducing redundancy and maximizing test
effectiveness.

Difference between Alpha and Beta Testing


Alpha Testing and Beta Testing are part of software development life cycle. Alpha and Beta
testing are types of User Acceptance Testing (UAT). Alpha Testing happens in the early
stages of SDLC and is performed internally by the development team while Beta testing
happens later in the SDLC, just before product release, and is performed by potential
customers, industry experts, or public beta testers.
What is Alpha Testing?
Alpha Testing is a type of software testing performed to identify bugs before releasing the
product to real users or to the public. Alpha Testing is one of the user acceptance tests. It is
the first stage of software testing, during which the internal development team tests the
program before making it available to clients or people outside the company.
Key points to remember:
Following are the key points related to Alpha Testing:
 Work Done by Developers: The internal development team, which consists of
developers and testers, usually conducts alpha testing in a controlled setting.
 Goal: Finding and fixing bugs, flaws, and usability issues is the main goal before
releasing the product for external users or wider testing.
 Little User Engagement: Alpha testers are few in number and frequently comprise
members of the development team or those intimately connected to the project.
 Environment: Alpha testing is typically carried out in a development environment or
laboratory that resembles actual settings.
What is Beta Testing?
Beta Testing is performed by real users of the software application in a real environment.
Beta testing is one type of User Acceptance Testing. A pre-release version of the product is
made available for testing to a chosen set of external users or customers during the second
phase of software testing.
Key Points to remember:
Following are the key points related to Beta Testing:
 Actions Taken by Users: Customers or other users outside the development team
participate in beta testing. The software is available to these users prior to its official
release.
 Goal: The primary objective is to get input from actual users in order to find any bugs,
usability difficulties, or areas that need to be improved before the product is formally
released.
 Greater User Participation: In order to capture a variety of viewpoints, a larger number
of users—including a varied range, can serve as beta testers.
 Environment: Real-world settings are used for beta testing to simulate how users will
interact with the program while performing daily duties.
Difference between Alpha and Beta Testing:
The difference between Alpha and Beta Testing is as follows:
Parameters Alpha Testing Beta Testing

Alpha testing uses both

Beta testing commonly uses
white box and black box
black-box testing.
Technique Used testing.

Alpha testing is performed

Beta testing is performed by
by testers who are usually
clients who are not part of
internal employees of the
the organization.
Performed by organization.

Alpha testing is performed Beta testing is performed at

Performed at at the developer’s site. the end-user of the product.

Reliability and security Reliability, security and

testing are not checked in robustness are checked
Reliability and Security alpha testing. during beta testing.

Beta testing also concentrates

Alpha testing ensures the on the quality of the product
quality of the product but collects users input on the
before forwarding to beta product and ensures that the
testing. product is ready for real time
Ensures users.

Alpha testing requires a

Beta testing doesn’t require a
testing environment or a
testing environment or lab.
Requirement lab.

Alpha testing may require a Beta testing requires only a

Execution long execution cycle. few weeks of execution.
 Parameters Alpha Testing Beta Testing

Most of the issues or

Developers can
feedback collected from the
immediately address the
beta testing will be
critical issues or fixes in
implemented in future
alpha testing.
Issues versions of the product.

Multiple test cycles are Only one or two test cycles

Test Cycles organized in alpha testing. are there in beta testing.

Frequently Asked Questions (FAQs) related to Difference between Alpha and Beta
Testing
What is the purpose of Alpha Testing?
The main purpose of alpha testing is to identify and fix bugs in software before performing
beta testing.
Who performs Beta testing?
Beta Testing is performed by potential customers, industry experts, or public beta testers.
What are the types of Beta Testing?
Types of Beta Testing are:
 Closed Beta Testing
 Open Beta Testing
 Focused Beta Testing

Regression Testing – Software Engineering


Regression Testing is the process of testing the modified parts of the code and the parts that
might get affected due to the modifications to ensure that no new errors have been introduced
in the software after the modifications have been made. Regression means the return of
something and in the software field, it refers to the return of a bug.
When to do regression testing?
 When new functionality is added to the system and the code has been modified to absorb
and integrate that functionality with the existing code.
 When some defect has been identified in the software and the code is debugged to fix it.
 When the code is modified to optimize its working.
Process of Regression testing
Firstly, whenever we make some changes to the source code for any reason like adding new
functionality, optimization, etc. then our program when executed fails in the previously
designed test suite for obvious reasons. After the failure, the source code is debugged to
identify the bugs in the program. After identification of the bugs in the source code,
appropriate modifications are made. Then appropriate test cases are selected from the already
existing test suite which covers all the modified and affected parts of the source code. We can
add new test cases if required. In the end, regression testing is performed using the selected
test cases.
 Process Regression testing

Techniques for the selection of Test cases for Regression Testing

 Select all test cases: In this technique, all the test cases are selected from the already
existing test suite. It is the simplest and safest technique but not very efficient.
 Select test cases randomly: In this technique, test cases are selected randomly from the
existing test suite, but it is only useful if all the test cases are equally good in their fault
detection capability which is very rare. Hence, it is not used in most of the cases.
 Select modification traversing test cases: In this technique, only those test cases are
selected that cover and test the modified portions of the source code and the parts that are
affected by these modifications.
 Select higher priority test cases: In this technique, priority codes are assigned to each
test case of the test suite based upon their bug detection capability, customer
requirements, etc. After assigning the priority codes, test cases with the highest priorities
are selected for the process of regression testing. The test case with the highest priority
has the highest rank. For example, a test case with priority code 2 is less important than a
test case with priority code 1.
 Selection of Test cases for Regression Testing

Tools for Regression testing

In regression testing, we generally select the test cases from the existing test suite itself and
hence, we need not compute their expected output, and it can be easily automated due to this
reason. Automating the process of regression testing will be very effective and time-saving.
The most commonly used tools for regression testing are:
 Selenium
 WATIR (Web Application Testing In Ruby)
 QTP (Quick Test Professional)
 RFT (Rational Functional Tester)
 Winrunner
 Silktest
Advantages of Regression Testing
 Automated unit testing
 Comprehensive test coverage
 System integration
 Faster test execution completion
 Improved developer productivity
 Parallel testing
 Reduced costs
 Regression testing improves product quality
 Reusability
 Scalability
 Time efficiency
Disadvantages of Regression Testing
 It can be time and resource-consuming if automated tools are not used.
 It is required even after very small changes in the code.
 Time and Resource Constraints.
 Among the significant risks associated with regression testing are the time and resources
required to perform it.
 Incomplete or Insufficient Test Coverage.
 False Positives and False Negatives.
 Test Data Management Challenges.
 Regression testing is like a safety net for software changes, making sure they do not bring in
new problems. It picks test cases from existing suites, sometimes focusing on modified parts.
Popular tools like Selenium and QTP automate this process. While it ensures thorough
testing, doing it manually can up time and encounter data management issues.

Frequently Asked Questions on Regression Testing

Who performs regression testing?
Answer:
A software quality assurance team.
What is a good example of regression?
Answer:
Age and height graph in linear regression model.
Is regression testing necessary?
Answer:
Yes, its a major requirement.

Performance Testing – Software Testing


Performance Testing is a type of software testing that ensures software applications perform
properly under their expected workload. It is a testing technique carried out to determine
system performance in terms of sensitivity, reactivity, and stability under a particular
workload.
What is performance testing?
Performance testing is a type of software testing that focuses on evaluating the performance
and scalability of a system or application. Performance testing aims to identify bottlenecks,
measure system performance under various loads and conditions, and ensure that the system
can handle the expected number of users or transactions.
Types of performance testing
Performance Testing is the process of analyzing the quality and capability of a product. It is a
testing method to determine the system’s performance in terms of speed, reliability, and
stability under varying workloads.
Performance testing is also known as Perf Testing. The types of Performance testing are as
follows:

1. Load testing

Load testing simulates a real-world load on the system to see how it performs under stress. It
helps identify bottlenecks and determine the maximum number of users or transactions the
system can handle. It checks the product’s ability to perform under anticipated user loads.
The objective is to identify performance congestion before the software product is launched
in the market.

2. Stress testing

Stress testing is a type of load testing that tests the system’s ability to handle a high load
above normal usage levels. It helps identify the breaking point of the system and any
potential issues that may occur under heavy load conditions. It involves testing a product
under extreme workloads to see whether it handles high traffic or not. The objective is to
identify the breaking point of a software product.

3. Spike testing

Spike testing is a type of load testing that tests the system’s ability to handle sudden spikes in
traffic. It helps identify any issues that may occur when the system is suddenly hit with a high
number of requests. It tests the product’s reaction to sudden large spikes in the load generated
by users.

4. Soak testing

Soak testing is a type of load testing that tests the system’s ability to handle a sustained load
over a prolonged period. It helps identify any issues that may occur after prolonged usage of
the system.

5. Endurance testing

Endurance testing is similar to soak testing, but it focuses on the long-term behavior of the
system under a constant load. It is performed to ensure the software can handle the expected
load over a long period.

6. Volume testing

In Volume testing, a large number of data is saved in a database and the overall software
system’s behavior is observed. The objective is to check the product’s performance under
varying database volumes.

7. Scalability testing

In Scalability testing, the software application’s effectiveness is determined by scaling up to

support an increase in user load. It helps in planning capacity additions to your software
system.

Why use performance testing?

 The objective of performance testing is to eliminate performance congestion.

 It uncovers what needs to be improved before the product is launched in the market.
 The objective of performance testing is to make software rapid.
 The objective of performance testing is to make software stable and reliable.
 The objective of performance testing is to evaluate the performance and scalability of a
system or application under various loads and conditions.
 It helps identify bottlenecks, measure system performance, and ensure that the system
can handle the expected number of users or transactions.
 It also helps to ensure that the system is reliable, stable, and can handle the expected load
in a production environment.

How to conduct performance testing?

Conducting performance testing involves several steps to ensure that a software application
can handle expected loads and perform well under stress. Here’s a simplified guide on how to
conduct performance testing:

performance testing process

Step 1: Set Up the Testing Environment First prepare the place where you will run the tests
for the performance testing. Make sure you have all the needed tools and understanding for
the setup, like what devices and software you will be using for the performance testing.
Step 2: Decide What to Measure Think about what you want to know from the tests. This
will include things like how fast the system responds to and how much it can handle the tests.
You can also look at successful similar systems to set your goals.
Step 3: Plan Your Tests to Figure out different scenarios to test, considering things like how
users might behave and what data you will use. This helps you create tests that cover a range
of situations and decide what data to collect.
Step 4: Set Up Your Tools Get everything ready for testing, including tools and ways to track
what’s happening during the tests.
Step 5: Create and Run Tests Make the tests based on your plan and run them. Keep track of
all the data you get from the tests.
Step 6: Look at the Results After each test, see what you find out. Adjust your tests based on
what you learn, and run them again to see if things change.
Step 7: Keep Testing Keep analyzing and adjusting your tests to get the best results. Repeat
the process until you are satisfied with the performance.

Advantages of Performance Testing

 Identifying bottlenecks: Performance testing helps identify bottlenecks in the system

such as slow database queries, insufficient memory, or network congestion. This helps
 developers optimize the system and ensure that it can handle the expected number of
users or transactions.
 Improved scalability: By identifying the system’s maximum capacity, performance
testing helps ensure that the system can handle an increasing number of users or
transactions over time. This is particularly important for web-based systems and
applications that are expected to handle a high volume of traffic.
 Improved reliability: Performance testing helps identify any potential issues that may
occur under heavy load conditions, such as increased error rates or slow response times.
This helps ensure that the system is reliable and stable when it is deployed to production.
 Reduced risk: By identifying potential issues before deployment, performance testing
helps reduce the risk of system failure or poor performance in production.
 Cost-effective: Performance testing is more cost-effective than fixing problems that
occur in production. It is much cheaper to identify and fix issues during the testing phase
than after deployment.
 Improved user experience: By identifying and addressing bottlenecks, performance
testing helps ensure that users have a positive experience when using the system. This
can help improve customer satisfaction and loyalty.
 Better Preparation: Performance testing can also help organizations prepare for
unexpected traffic patterns or changes in usage that might occur in the future.
 Compliance: Performance testing can help organizations meet regulatory and industry
standards.
 Better understanding of the system: Performance testing provides a better understanding
of how the system behaves under different conditions, which can help in identifying
potential issue areas and improving the overall design of the system.
 Performance testing ensures the speed, load capability, accuracy, and other performances
of the system.
 It identifies, monitors, and resolves the issues if anything occurs.
 It ensures the great optimization of the software and also allows many users to use it at
the same time.
 It ensures the client as well as the end-customer’s satisfaction. Performance testing has
several advantages that make it an important aspect of software testing:

Disadvantages of Performance Testing

Performance testing also has some disadvantages, which include:

 Resource-intensive: Performance testing can be resource-intensive, requiring significant
hardware and software resources to simulate many users or transactions. This can make
performance testing expensive and time-consuming.
 Complexity: Performance testing can be complex, requiring specialized knowledge and
expertise to set up and execute effectively. This can make it difficult for teams with
limited resources or experience to perform performance testing.
 Limited testing scope: Performance testing is focused on the performance of the system
under stress, and it may not be able to identify all types of issues or bugs. It’s important
to combine performance testing with other types of testing such as functional testing,
regression testing, and acceptance testing.
 Inaccurate results: If the performance testing environment is not representative of the
production environment or the performance test scenarios do not accurately simulate
real-world usage, the results of the test may not be accurate.
 Difficulty in simulating real-world usage: It’s difficult to simulate real-world usage,
and it’s hard to predict how users will interact with the system. This makes it difficult to
know if the system will handle the expected load.
 Complexity in analyzing the results: Performance testing generates a large amount of
data, and it can be difficult to analyze the results and determine the root cause of
performance issues.
 Sometimes, users may find performance issues in the real-time environment.
 Team members who are writing test scripts or test cases in the automation tool should
have a high level of knowledge.
 Team members should have high proficiency in debugging the test cases or test scripts.
 Low performances in the real environment may lead to the loss of a large number of
users

What is Cloud-based Performance Testing?

Cloud-based Performance Testing simulates real-world user traffic and uses cloud
computing platforms to evaluate the scalability and performance of online applications.
Utilizing the scalability and flexibility of cloud infrastructure provides advantages over
conventional methods and helps organizations locate performance bottlenecks and effectively
optimize application performance.
Cloud-based Performance Testing allows for the quick iteration and ongoing improvement of
software systems, enabling the delivery of dependable and high-performing applications in
today’s digital ecosystem. It does this by distributing virtual users across multiple locations
and providing real-time information.

Performance Testing Tools

1. Apache JMeter
2. Open STA (Open, Systems Testing Architecture)
3. Load Runner
4. Web Load
5. Gatling
6. BlazeMeter

Performance Testing Attributes

 Speed: It determines whether the software product responds rapidly.

 Scalability: It determines the amount of load the software product can handle at a time.
 Stability: It determines whether the software product is stable in case of varying
workloads.
 Reliability: It determines whether the software product is secure or not.

Performance testing evaluates the system performance under different conditions, by

checking the speed, scalability, stability, and reliability with testing. Its complexities and
resource requirements will give benefits like identifying bottlenecks, improving scalability,
reducing risk, and improving the user experience. Cloud-based tools like Apache JMeter and
Load Runner will improve the way of testing.

Frequently Asked Questions on Performance Testing

What is performance and its types?
 Contextual and task
How to start performance testing?
1. Step 1: Identify the Testing Environment.
2. Step 2: Identify the Performance Metrics.
3. Step 3: Plan and Design Performance Tests.
4. Step 4: Configure the Test Environment.
5. Step 5: Implement the Test Design.
6. Step 6: Run the Tests.
7. Step 7: Analyze, Tune and Retest.

What is Stress Testing in Software Testing?


Stress Testing is a software testing technique that determines the robustness of software by
testing beyond the limits of normal operation. Stress testing is particularly important for
critical software but is used for all types of software. Stress testing emphasizes robustness,
availability, and error handling under a heavy load rather than what is correct behavior under
normal situations.

Stress testing is defined as a type of software testing that verifies the stability and reliability
of the system. This test particularly determines the system’s robustness and error handling
under burdensome load conditions. It even tests beyond the normal operating point and
analyses how the system works under extreme conditions. Stress testing is performed to
ensure that the system does not crash under crunch situations. Stress testing is also known
as Endurance Testing or Torture Testing.

Characteristics of Stress Testing

1. Identification of Risk: Stress testing’s main objective is to locate and evaluate a

system’s possible hazards and weaknesses.
2. Quantitative and Qualitative Analysis: While numerical data are crucial, it’s also
critical to comprehend the qualitative characteristics of the system’s response and
potential weak points.
3. Variable Parameters: Stress testing includes changing variables including interest rates,
market conditions, transaction volumes and outside influences that could have an impact
on the system.
4. Cross-Functional Involvement: Many departments within an organization must work
together and participate in stress testing. This cross-functional strategy makes sure that
the stress testing procedure benefits from a variety of viewpoints and specialties.
5. Open and Honest Communication: Stress testing necessitates open and honest
communication regarding the goal, approach, and outcomes of the testing procedure.

Need For Stress Testing

 To accommodate the sudden surges in traffic: It is important to perform stress testing

to accommodate abnormal traffic spikes. For example, when there is a sale
announcement on the e-commerce website there is a sudden increase in traffic. Failure to
accommodate such needs may lead to a loss of revenue and reputation.
 Display error messages in stress conditions: Stress testing is important to check
whether the system is capable to display appropriate error messages when the system is
under stress conditions.
 The system works under abnormal conditions: Stress testing checks whether the
system can continue to function in abnormal conditions.
 Prepared for stress conditions: Stress testing helps to make sure there are sufficient
contingency plans in case of sudden failure due to stress conditions. It is better to be
prepared for extreme conditions by executing stress testing.

Purpose of Stress Testing

 Analyze the behavior of the application after failure: The purpose of stress testing is
to analyze the behavior of the application after failure and the software should display
the appropriate error messages while it is under extreme conditions.
 System recovers after failure: Stress testing aims to make sure that there are plans for
recovering the system to the working state so that the system recovers after failure.
 Uncover Hardware issues: Stress testing helps to uncover hardware issues and data
corruption issues.
 Uncover Security Weakness: Stress testing helps to uncover the security vulnerabilities
that may enter into the system during the constant peak load and compromise the system.
 Ensures data integrity: Stress testing helps to determine the application’s data integrity
throughout the extreme load, which means that the data should be in a dependable state
even after a failure.

Stress Testing Process

The stress testing process is divided into 5 steps:

1. Planning the stress test: This step involves gathering the system data, analyzing the
system, and defining the stress test goals.
2. Create Automation Scripts: This step involves creating the stress testing automation
scripts and generating the test data for the stress test scenarios.
3. Script Execution: This step involves running the stress test automation scripts and
storing the stress test results.
4. Result Analysis: This phase involves analyzing stress test results and identifying the
bottlenecks.
5. Tweaking and Optimization: This step involves fine-tuning the system and optimizing
the code with the goal meet the desired benchmarks.
 Stress Testing

Types of Stress Testing

1. Server-client Stress Testing: Server-client stress testing also known as distributed stress
testing is carried out across all clients from the server.
2. Product Stress Testing: Product stress testing concentrates on discovering defects
related to data locking and blocking, network issues, and performance congestion in a
software product.
3. Transactional Stress Testing: Transaction stress testing is performed on one or more
transactions between two or more applications. It is carried out for fine-tuning and
optimizing the system.
4. Systematic Stress Testing: Systematic stress testing is integrated testing that is used to
perform tests across multiple systems running on the same server. It is used to discover
defects where one application data blocks another application.
5. Analytical Stress Testing: Analytical or exploratory stress testing is performed to test
the system with abnormal parameters or conditions that are unlikely to happen in a real
 scenario. It is carried out to find defects in unusual scenarios like a large number of users
logged at the same time or a database going offline when it is accessed from a website.
6. Application Stress Testing: Application stress testing also known as product stress
testing is focused on identifying the performance bottleneck, and network issues in a
software product.
Stress Testing Tools
1. Jmeter: Apache JMeter is a stress testing tool is an open-source, pure Java-based
software that is used to stress test websites. It is an Apache project and can be used for
load testing for analyzing and measuring the performance of a variety of services.
2. LoadNinja: LoadNinja is a stress testing tool developed by SmartBear that enables users
to develop codeless load tests, substitutes load emulators with actual browsers, and helps
to achieve high speed and efficiency with browser-based metrics.
3. WebLoad: WebLoad is a stress testing tool that combines performance, stability, and
integrity as a single process for the verification of mobile and web applications.
4. Neoload: Neoload is a powerful performance testing tool that simulates large numbers of
users and analyzes the server’s behavior. It is designed for both mobile and web
applications. Neoload supports API testing and integrates with different CI/ CD
applications.
5. SmartMeter: SmartMeter is a user-friendly tool that helps to create simple tests without
coding. It has a graphical user interface and has no necessary plugins. This tool
automatically generates advanced test reports with complete and detailed test results.
Metrics of Stress Testing
Metrics are used to evaluate the performance of the stress and it is usually carried out at the
end of the stress scripts or tests. Some of the metrics are given below.
1. Pages Per Second: Number of pages requested per second and number of pages loaded
per second.
2. Pages Retrieved: Average time is taken to retrieve all information from a particular
page.
3. Byte Retrieved: Average time is taken to retrieve the first byte of information from the
page.
4. Transaction Response Time: Average time is taken to load or perform transactions
between the applications.
5. Transactions per Second: It takes count of the number of transactions loaded per
second successfully and it also counts the number of failures that occurred.
6. Failure of Connection: It takes count of the number of times that the client faced
connection failure in their system.
7. Failure of System Attempts: It takes count of the number of failed attempts in the
system.
8. Rounds: It takes count of the number of test or script conditions executed by the clients
successfully and it keeps track of the number of rounds failed.
Benefits of Stress Testing
 Determines the behavior of the system: Stress testing determines the behavior of the
system after failure and ensures that the system recovers quickly.
 Ensure failure does not cause security issues: Stress testing ensures that system failure
doesn’t cause security issues.
 Makes system function in every situation: Stress testing makes the system work in
normal as well as abnormal conditions in an appropriate way.
 Improving Decision Making: Decision-making processes can benefit from the
insightful information that stress testing offers.
  Increasing Stakeholder confidence: Providing clear information about the outcomes of
stress tests helps boost stakeholder confidence. Organizations that show a proactive
approach to risk management are valued by investors, customers, and other stakeholders,
since it cultivates credibility and confidence.
Limitations of Stress Testing
1. Manual stress testing is complicated: The manual process of stress testing takes a
longer time to complete and it is a complicated process.
2. Good scripting knowledge required: Good scripting knowledge for implementing the
script test cases for the particular tool is required.
3. Need for external resources: There is a need for external resources to implement stress
testing. It leads to an extra amount of resources and time.
4. Constantly licensed tool: In the case of a licensed stress testing tool, it charges more
than the average amount of cost.
5. Additional tool required in case of open-source stress testing tool: In the case of
some open-source tools, there is a need for a load testing tool additionally for setting up
the stress testing environment.
6. Improper test script implementation results in wastage: If proper stress scripts or test
cases are not implemented then there will be a chance of failure of some resources and
wastage of time.
Stress testing is an essential and proactive risk management strategy that gives businesses
important information about their ability to withstand adverse circumstances and their weak
points. The method is putting financial institutions, systems, or processes through harsh
situations in order to find vulnerabilities, evaluate risks and improve overall capability.

CHANGE CONTROL

Definition. :Change control is the process through which all requests to change the approved
baseline of a project, programme or portfolio are captured, evaluated and then approved,
rejected or deferred.

VERSION CONTROL

Version control, also known as source control, is the practice of tracking and managing
changes to software code. Version control systems are software tools that help software teams
manage changes to source code over time.

Reuse Maturity Model


Software Reuse is the process of creating software systems from existing software systems,
rather than building software system from scratch.” REUSE MATURITY MODEL : It is
based on the experience within software development organization as well as experience with
and observations of other development organizations. LEVEL-1 : Single Project Source
Based Reuse – At the very first maturity level, organizations placed all their source code
within a single project. After this, the single pool of source code will hold multiple
applications as depicted in the following figure :
 Figure : Level-1

Project A is home to two applications A and B. There is no need to copy source files or
compiled files from one project to another because there is only one project. But there is a
limit that how well this practice will scale. When number of applications or number of
developers increases, to maintain the single source code will become difficult. LEVEL-2 :
Multi Project Source Based Reuse – In this stage, source code is divided into multiple
projects and practice source-based reuse between projects. In this scenario, source-based
reuse copies source developed in one project into another project. Main target of such reuse is
utilities, which can be developed in one project and can be used in the another project. It is as
shown in the following figure :

Figure : Level-2

Project A is home to application A and project B is home to application B. The code which is
common to both the projects is copied into both projects. Problem with this is that, after
copying, reused source code has to link back to the original. This cause all sorts of
maintenance problems, since bug fixes will have to be applied to every project that reuse
copied code. Also, two host projects evolve reused code will evolve with them, which makes
maintenance more difficult. LEVEL-3 : Ad hoc Binary Reuse – This is next step after level
2. Organizations are advance to level and will realize drawback of level 2. Under this
approach, project boundaries realign and there is no longer mirror boundaries. Projects at this
level, can correspond to applications. Utility source code that was copied from one project to
another at previous level is now placed in its own project and has its own lifecycle
independent of the application projects. Application projects include binary artifacts of
 utilities project, and a dependency relationship between projects is established. Maintenance
of utilities project is greatly simplified because rather than maintaining multiple diverging
copies of utilities, only a single version needs to b maintained. Also application requires
additional features, thus application features become available to all applications using
utilities as shown in the following figure :

Figure : Level-3

But in this, there are no release procedures or dependency management procedures. Adding
new features makes it impossible to know exact version of utilities used in application. Also,
with this when a bug is discovered it is difficult to know what version of code based=
contained bug. After a fix is implemented, it is difficult to know whether newest version will
be compatible with all applications projects that need utilities library. LEVEL-4 :
Controlled Binary Reuse and the Reuse/Release Equivalence Principle – It is based on ad
hoc binary reuse. The project boundaries remain same, with application projects and
component projects. At this level, each release of a project is controlled and tracked with a
version number. At this level, when the bug is discovered, the exact version of the component
with the bug can be identified.

Re-engineering – Software Engineering


Software Re-engineering is a process of software development that is done to improve the
maintainability of a software system. Re-engineering is the examination and alteration of a
system to reconstitute it in a new form. This process encompasses a combination of sub-
processes like reverse engineering, forward engineering, reconstructing, etc.
What is Re-engineering?
Re-engineering, also known as software re-engineering, is the process of analyzing,
designing, and modifying existing software systems to improve their quality, performance,
and maintainability.
1. This can include updating the software to work with new hardware or software
platforms, adding new features, or improving the software’s overall design and
architecture.
2. Software re-engineering, also known as software restructuring or software renovation,
refers to the process of improving or upgrading existing software systems to improve
their quality, maintainability, or functionality.
3. It involves reusing the existing software artifacts, such as code, design, and
documentation, and transforming them to meet new or updated requirements.
Objective of Re-engineering
The primary goal of software re-engineering is to improve the quality and maintainability of
the software system while minimizing the risks and costs associated with the redevelopment
of the system from scratch. Software re-engineering can be initiated for various reasons, such
as:
1. To describe a cost-effective option for system evolution.
2. To describe the activities involved in the software maintenance process.
3. To distinguish between software and data re-engineering and to explain the problems of
data re-engineering.
Overall, software re-engineering can be a cost-effective way to improve the quality and
functionality of existing software systems, while minimizing the risks and costs associated
with starting from scratch.
Process of Software Re-engineering
The process of software re-engineering involves the following steps:

1. Planning: The first step is to plan the re-engineering process, which involves identifying
the reasons for re-engineering, defining the scope, and establishing the goals and
objectives of the process.
2. Analysis: The next step is to analyze the existing system, including the code,
documentation, and other artifacts. This involves identifying the system’s strengths and
weaknesses, as well as any issues that need to be addressed.
3. Design: Based on the analysis, the next step is to design the new or updated software
system. This involves identifying the changes that need to be made and developing a
plan to implement them.
4. Implementation: The next step is to implement the changes by modifying the existing
code, adding new features, and updating the documentation and other artifacts.
5. Testing: Once the changes have been implemented, the software system needs to be
tested to ensure that it meets the new requirements and specifications.
6. Deployment: The final step is to deploy the re-engineered software system and make it
available to end-users.
Why Perform Re-engineering?
Re-engineering can be done for a variety of reasons, such as:
1. To improve the software’s performance and scalability: By analyzing the existing
code and identifying bottlenecks, re-engineering can be used to improve the software’s
performance and scalability.
2. To add new features: Re-engineering can be used to add new features or functionality
to existing software.
3. To support new platforms: Re-engineering can be used to update existing software to
work with new hardware or software platforms.
4. To improve maintainability: Re-engineering can be used to improve the software’s
overall design and architecture, making it easier to maintain and update over time.
5. To meet new regulations and compliance: Re-engineering can be done to ensure that
the software is compliant with new regulations and standards.
6. Improving software quality: Re-engineering can help improve the quality of software
by eliminating defects, improving performance, and enhancing reliability and
maintainability.
7. Updating technology: Re-engineering can help modernize the software system by
updating the technology used to develop, test, and deploy the system.
8. Enhancing functionality: Re-engineering can help enhance the functionality of the
software system by adding new features or improving existing ones.
 9. Resolving issues: Re-engineering can help resolve issues related to scalability, security,
or compatibility with other systems.
Steps involved in Re-engineering
1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering

Steps of Re-Engineering

Re-engineering Cost Factors

1. The quality of the software to be re-engineered.
2. The tool support available for re-engineering.
3. The extent of the required data conversion.
4. The availability of expert staff for re-engineering.
Factors Affecting Cost of Re-engineering
Re-engineering can be a costly process, and there are several factors that can affect the
cost of re-engineering a software system:
1. Size and complexity of the software: The larger and more complex the software
system, the more time and resources will be required to analyze, design, and modify it.
2. Number of features to be added or modified: The more features that need to be added
or modified, the more time and resources will be required.
3. Tools and technologies used: The cost of re-engineering can be affected by the tools
and technologies used, such as the cost of software development tools and the cost of
hardware and infrastructure.
4. Availability of documentation: If the documentation of the existing system is not
available or is not accurate, then it will take more time and resources to understand the
system.
 5. Team size and skill level: The size and skill level of the development team can also
affect the cost of re-engineering. A larger and more experienced team may be able to
complete the project faster and with fewer resources.
6. Location and rate of the team: The location and rate of the development team can also
affect the cost of re-engineering. Hiring a team in a lower-cost location or with lower
rates can help to reduce the cost of re-engineering.
7. Testing and quality assurance: Testing and quality assurance are important aspects of
re-engineering, and they can add significant costs to the project.
8. Post-deployment maintenance: The cost of post-deployment maintenance such as bug
fixing, security updates, and feature additions can also play a role in the cost of re-
engineering.
In summary, the cost of re-engineering a software system can vary depending on a variety of
factors, including the size and complexity of the software, the number of features to be added
or modified, the tools and technologies used, and the availability of documentation and the
skill level of the development team. It’s important to carefully consider these factors when
estimating the cost of re-engineering a software system.
Advantages of Re-engineering
1. Reduced Risk: As the software is already existing, the risk is less as compared to new
software development. Development problems, staffing problems and specification
problems are the lots of problems that may arise in new software development.
2. Reduced Cost: The cost of re-engineering is less than the costs of developing new
software.
3. Revelation of Business Rules: As a system is re-engineered , business rules that are
embedded in the system are rediscovered.
4. Better use of Existing Staff: Existing staff expertise can be maintained and extended
accommodate new skills during re-engineering.
5. Improved efficiency: By analyzing and redesigning processes, re-engineering can lead
to significant improvements in productivity, speed, and cost-effectiveness.
6. Increased flexibility: Re-engineering can make systems more adaptable to changing
business needs and market conditions.
7. Better customer service: By redesigning processes to focus on customer needs, re-
engineering can lead to improved customer satisfaction and loyalty.
8. Increased competitiveness: Re-engineering can help organizations become more
competitive by improving efficiency, flexibility, and customer service.
9. Improved quality: Re-engineering can lead to better quality products and services by
identifying and eliminating defects and inefficiencies in processes.
10. Increased innovation: Re-engineering can lead to new and innovative ways of doing
things, helping organizations to stay ahead of their competitors.
11. Improved compliance: Re-engineering can help organizations to comply with industry
standards and regulations by identifying and addressing areas of non-compliance.
Disadvantages of Re-engineering
Major architectural changes or radical reorganizing of the systems data management has to be
done manually. Re-engineered system is not likely to be as maintainable as a new system
developed using modern software Re-engineering methods.
1. High costs: Re-engineering can be a costly process, requiring significant investments in
time, resources, and technology.
2. Disruption to business operations: Re-engineering can disrupt normal business
operations and cause inconvenience to customers, employees and other stakeholders.
3. Resistance to change: Re-engineering can encounter resistance from employees who
may be resistant to change and uncomfortable with new processes and technologies.
 4. Risk of failure: Re-engineering projects can fail if they are not planned and executed
properly, resulting in wasted resources and lost opportunities.
5. Lack of employee involvement: Re-engineering projects that are not properly
communicated and involve employees, may lead to lack of employee engagement and
ownership resulting in failure of the project.
6. Difficulty in measuring success: Re-engineering can be difficult to measure in terms of
success, making it difficult to justify the cost and effort involved.
7. Difficulty in maintaining continuity: Re-engineering can lead to significant changes in
processes and systems, making it difficult to maintain continuity and consistency in the
organization.
Software re-engineering is a systematic process aimed at improving existing software
systems. It involves analyzing, restructuring, and sometimes rebuilding software to enhance
its functionality, adapt it to new requirements, or migrate it to a new platform. By employing
techniques such as reverse engineering and forward engineering, reengineering helps ensure
that software remains relevant, maintainable, and efficient.

Frequently Asked Questions (FAQs) on Re-engineering

1. What is the difference between software reengineering and reverse engineering?

Reverse engineering involves dissecting a product to understand its inner workings, without
necessarily intending to modify it immediately while Re-engineering specifically involves
modifying or transforming a product into a new form or structure.
2. Why is software re-engineering important?
Software Re-engineering is important because it enables the reuse of software components
from existing systems. It also improve the software’s performance and scalability. Re-
engineering can be used to add new features or functionality to existing software.
3. What is Data Re-engineering?
Data re-engineering involves the process of restructuring or transforming existing data
systems, databases, or data architectures to improve their efficiency, reliability, or usability.

Reverse Engineering – Software Engineering


Software Reverse Engineering is a process of recovering the design, requirement
specifications, and functions of a product from an analysis of its code. It builds a program
database and generates information from this. This article focuses on discussing reverse
engineering in detail.

What is Reverse Engineering?

Reverse engineering can extract design information from source code, but the abstraction
level, the completeness of the documentation, the degree to which tools and a human analyst
work together, and the directionality of the process are highly variable.

Objective of Reverse Engineering:

1. Reducing Costs: Reverse engineering can help cut costs in product development by
finding replacements or cost-effective alternatives for systems or components.
2. Analysis of Security: Reverse engineering is used in cybersecurity to examine exploits,
vulnerabilities, and malware. This helps in understanding of threat mechanisms and the
development of practical defenses by security experts.
3. Integration and Customization: Through the process of reverse engineering,
developers can incorporate or modify hardware or software components into pre-existing
systems to improve their operation or tailor them to meet particular needs.
4. Recovering Lost Source Code: Reverse engineering can be used to recover the source
code of a software application that has been lost or is inaccessible or at the very least, to
produce a higher-level representation of it.
5. Fixing bugs and maintenance: Reverse engineering can help find and repair flaws or
provide updates for systems for which the original source code is either unavailable or
inadequately documented.

Reverse Engineering Goals:

1. Cope with Complexity: Reverse engineering is a common tool used to understand and
control system complexity. It gives engineers the ability to analyze complex systems and
reveal details about their architecture, relationships and design patterns.
2. Recover lost information: Reverse engineering seeks to retrieve as much information as
possible in situations where source code or documentation are lost or unavailable.
Rebuilding source code, analyzing data structures and retrieving design details are a few
examples of this.
3. Detect side effects: Understanding a system or component’s behavior requires analyzing
its side effects. Unintended implications, dependencies, and interactions that might not
be obvious from the system’s documentation or original source code can be found with
the use of reverse engineering.
4. Synthesis higher abstraction: Abstracting low-level features in order to build higher-
level representations is a common practice in reverse engineering. This abstraction
makes communication and analysis easier by facilitating a greater understanding of the
system’s functionality.
5. Facilitate Reuse: Reverse engineering can be used to find reusable parts or modules in
systems that already exist. By understanding the functionality and architecture of a
system, developers can extract and repurpose components for use in other projects,
improving efficiency and decreasing development time.

Reverse Engineering to Understand Data:

Reverse engineering of data occurs at different levels of abstraction .It is often the first
reengineering task.
1. At the program level, internal program data structures must often be reverse engineered
as part of an overall reengineering effort.
2. At the system level, global data structures (e.g., files, databases) are often reengineered
to accommodate new database management paradigms (e.g., the move from flat file to
relational or object-oriented database systems).

Internal Data Structures

Reverse engineering techniques for internal program data focus on the definition of classes of
objects.
1. This is accomplished by examining the program code with the intent of grouping related
program variables.
2. In many cases, the data organization within the code identifies abstract data types.
3. For example, record structures, files, lists, and other data structures often provide an
initial indicator of classes.

Database Structures
A database allows the definition of data objects and supports some method for establishing
relationships among the objects. Therefore, reengineering one database schema into another
requires an understanding of existing objects and their relationships.
The following steps define the existing data model as a precursor to reengineering a new
database model:
1. Build an initial object model.
2. Determine candidate keys (the attributes are examined to determine whether they are
used to point to another record or table; those that serve as pointers become candidate
keys).
3. Refine the tentative classes.
4. Define generalizations.

Reverse Engineering to Understand Processing:

To understand processing begins with an attempt to understand and then extract procedural
abstractions represented by the source code. To understand procedural abstractions, the code
is analyzed at varying levels of abstraction :system, program, component, pattern, and
statement.
1. Each of the programs that make up the application system represents a functional
abstraction at a high level of detail. A block diagram, representing the interaction
between these functional abstractions, is created.
2. Each component performs some subfunction and represents a defined procedural
abstraction. A processing narrative for each component is developed.
For large systems, reverse engineering is generally accomplished using a
semiautomated(partial automation) approach. Automated tools can be used to help you
understand the semantics of existing code. The output of this process is then passed to
restructuring and forward engineering tools to complete the reengineering process.

Steps of Software Reverse Engineering:

1. Collection Information: This step focuses on collecting all possible information (i.e.,
source design documents, etc.) about the software.
2. Examining the Information: The information collected in step-1 is studied so as to get
familiar with the system.
3. Extracting the Structure: This step concerns identifying program structure in the form
of a structure chart where each node corresponds to some routine.
4. Recording the Functionality: During this step processing details of each module of the
structure, charts are recorded using structured language like decision table, etc.
5. Recording Data Flow: From the information extracted in step-3 and step-4, a set of data
flow diagrams is derived to show the flow of data among the processes.
6. Recording Control Flow: The high-level control structure of the software is recorded.
7. Review Extracted Design: The design document extracted is reviewed several times to
ensure consistency and correctness. It also ensures that the design represents the
program.
8. Generate Documentation: Finally, in this step, the complete documentation including
SRS, design document, history, overview, etc. is recorded for future use.

Reverse Engineering Tools:

 Reverse engineering tools accept source code as input and produce a variety of structural,
procedural, data, and behavioral design. Reverse engineering if done manually would
consume a lot of time and human labor and hence must be supported by automated tools.
Some of the tools are given below:
1. CIAO and CIA: A graphical navigator for software and web repositories and a
collection of Reverse Engineering tools.
2. Rigi: A visual software understanding tool.
3. Bunch: A software clustering/modularization tool.
4. GEN++: An application generator to support the development of analysis tools for the
C++ language.
5. PBS: Software Bookshelf tools for extracting and visualizing the architecture of
programs.

Introduction of Software Design Process


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. Hence, this phase aims to transform the SRS document into a design
document.
The following items are designed and documented during the design phase:
1. Different modules are required.
2. Control relationships among modules.
3. Interface among different modules.
4. Data structure among the different modules.
5. Algorithms are required to be implemented among the individual modules.

Objectives of Software Design

1. Correctness: A good design should be correct i.e., it should correctly implement all the
functionalities of the system.
2. Efficiency: A good software design should address the resources, time, and cost
optimization issues.
3. Flexibility: A good software design should have the ability to adapt and accommodate
changes easily. It includes designing the software in a way, that allows for modifications,
enhancements, and scalability without requiring significant rework or causing major
disruptions to the existing functionality.
4. Understandability: A good design should be easily understandable, it should be
modular, and all the modules are arranged in layers.
5. Completeness: The design should have all the components like data structures,
modules, external interfaces, etc.
6. Maintainability: A good software design aims to create a system that is easy to
understand, modify, and maintain over time. This involves using modular and well-
structured design principles e.g.,(employing appropriate naming conventions and
providing clear documentation). Maintainability in Software and design also enables
developers to fix bugs, enhance features, and adapt the software to changing
requirements without excessive effort or introducing new issues.

Software Design Concepts

Concepts are defined as a principal idea or invention that comes into our mind or in thought
to understand something. 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, and
the logic, or thinking behind how you will design software. It allows the software engineer to
create the model of the system software or product that is to be developed or built. 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:

Points to be Considered While Designing Software

1. Abstraction (Hide Irrelevant data): Abstraction simply means to hide the details to
reduce complexity and increase efficiency or quality. Different levels of Abstraction are
necessary and must be applied at each stage of the design process so that any error that is
present can be removed to increase the efficiency of the software solution and to refine
the software solution. The solution should be described in broad ways that cover a wide
range of different things at a higher level of abstraction and a more detailed description
of a solution of software should be given at the lower level of abstraction.
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. It is necessary to divide the software into components
known as modules because nowadays, there are different software available like
Monolithic software that is hard to grasp for software engineers. So, modularity in design
has now become a trend and is also important. If the system contains fewer components
then it would mean the system is complex which requires a lot of effort (cost) but if we
can divide the system into components then the cost would be small.
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. These components
interact with each other and use the data of the structure in architecture.
4. Refinement (removes impurities): Refinement simply means to refine something to
remove any impurities if present and increase the quality. The refinement concept of
software design is a process of developing or presenting the software or system in a
detailed manner which means elaborating a system or software. Refinement 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. Information Hiding (Hide the Information): Information hiding simply means to hide
the information so that it cannot be accessed by an unwanted party. In software design,
information hiding is achieved by designing the modules in a manner that the
information gathered or contained in one module is hidden and can’t be accessed by any
other modules.
7. Refactoring (Reconstruct something): Refactoring simply means reconstructing
something in such a way that it does not affect the behavior of any other features.
Refactoring in software design means reconstructing the design to reduce complexity and
simplify it without impacting the behavior or its functions. Fowler has defined
 refactoring as “the process of changing a software system in a way that it won’t impact
the behavior of the design and improves the internal structure”.

Different levels of Software Design

There are three different levels of software design. They are:
1. Architectural Design: The architecture of a system can be viewed as the overall
structure of the system and the way in which structure provides conceptual integrity of
the system. The architectural design identifies the software as a system with many
components interacting with each other. At this level, the designers get the idea of the
proposed solution domain.
2. Preliminary or high-level design: Here the problem is decomposed into a set of
modules, the control relationship among various modules identified, and also the
interfaces among various modules are identified. The outcome of this stage is called the
program architecture. Design representation techniques used in this stage are structure
chart and UML.
3. Detailed design: Once the high-level design is complete, a detailed design is undertaken.
In detailed design, each module is examined carefully to design the data structure and
algorithms. The stage outcome is documented in the form of a module specification
document.

Why are Abstractions Important in System Design?


As we all know abstraction is the process of capturing the essential characteristics of a
system, object, or concept while omitting irrelevant or non-essential details. It allows
developers to view complex systems through a simplified lens, facilitating comprehension,
modularity, and efficiency. By abstracting away the complexities, designers can create
scalable and maintainable systems that are easier to reason about and extend.
In system design, abstractions act as a tool for designing systems in order to solve complex
systems into simpler ones. We forcefully select some parts of the system and purposefully
leave out others so as to simplify. They are purposefully laid out as they play a pivotal role in
simplifying complex concepts and enabling efficient development. Abstractions provide a
high-level representation of underlying components, allowing developers to focus on
functionality without being burdened by intricate implementation details. In this article, we
will see the importance of abstractions in system design, particularly highlighting their
significance in database management and distributed systems.
Database Abstraction: In the realm of database management systems (DBMS), abstraction
plays a crucial role in separating the logical and physical layers. The database abstraction
layer acts as an intermediary between the application and the underlying database, shielding
developers from the intricacies of the storage engine. This separation enables developers to
focus on business logic and data modeling, rather than being bogged down by low-level
implementation details.
Advantages of database abstraction:
1. It enhances portability by decoupling the application from the specific database vendor.
With an abstracted interface, developers can switch databases seamlessly without
significant changes to the application code. Second, abstraction allows for improved
performance optimizations. By isolating the application logic from the intricacies of the
storage engine, developers can employ techniques like caching, query optimization, and
indexing without impacting the overall application design.
2. Abstraction fosters code maintainability and collaboration. Developers can work
concurrently on different components of the application, ensuring modularity and
reducing dependencies. With a well-defined database abstraction layer, changes in the
underlying database schema can be accommodated without affecting the entire
application, thereby reducing the risk of regressions and facilitating agile development
practices.

Abstractions in Distributed Systems

In the context of distributed systems, abstractions play a vital role in managing complexity
and enabling scalability. Distributed systems are composed of multiple interconnected
components, often running on different machines and communicating over networks.
Abstractions help in encapsulating the complexity of distributed communication, fault
tolerance, and resource management.

Important of Abstractions in System Design

1. Abstractions allow developers to focus on the core functionalities and design principles
without getting overwhelmed by implementation details.
2. Abstractions enable system designers to think in terms of interfaces and contracts rather
than specific implementations. This promotes loose coupling between system
components, allowing for easier replacement or upgrade of underlying technologies
without impacting the overall system design.
3. Abstractions also aid in managing complexity by providing a simplified mental model of
the system. By hiding unnecessary details and exposing only relevant functionalities,
abstractions allow developers to reason about the system at a higher level of abstraction.
4. Abstractions facilitate system scalability by providing a modular and extensible
framework. Through well-defined abstractions, developers can encapsulate complex
functionalities and scale individual components independently.

Advantages of Abstractions in distributed systems

1. One essential abstraction in distributed systems is the concept of a message queue or a
message broker. A message queue abstracts the communication between different
components, allowing them to send and receive messages asynchronously. By providing
a standardized interface, it simplifies the coordination and synchronization of distributed
processes, enabling fault tolerance and load balancing.
2. Another critical abstraction in distributed systems is the concept of a distributed file
system. Distributed file systems abstract the storage and retrieval of files across multiple
machines, providing a unified view of a distributed storage infrastructure. This
abstraction enables applications to scale horizontally by distributing data across multiple
nodes while ensuring fault tolerance and data consistency.
3. Abstractions in distributed systems also facilitate fault tolerance and resilience.
Techniques like replication, sharding, and load balancing are implemented as
abstractions, hiding the complexities of failure recovery and ensuring system availability
and reliability. By providing a clear separation between the application logic and the
distributed system infrastructure, abstractions enable developers to reason about the
system’s behavior and optimize its performance.

Abstractions play a crucial role in system design by simplifying complex concepts,

providing modular frameworks, and enabling efficient development. Whether in the
context of database management or distributed systems, abstractions offer significant
benefits such as portability, performance optimization, scalability, and maintainability.
 By abstracting away implementation details, system designers can focus on higher-level
functionalities, foster code reusability, and build robust and flexible systems.

Architectural Design – Software Engineering


The software needs an architectural design to represent the design of the software. IEEE
defines architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of
these many architectural styles.

System Category Consists of

 A set of components(eg: a database, computational modules) that will perform a function
required by the system.
 The set of connectors will help in coordination, communication, and cooperation
between the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties of the
system.
The use of architectural styles is to establish a structure for all the components of the system.

Taxonomy of Architectural Styles

1] Data centered architectures:
 A data store will reside at the center of this architecture and is accessed frequently by the
other components that update, add, delete, or modify the data present within the store.
 The figure illustrates a typical data-centered style. The client software accesses a central
repository. Variations of this approach are used to transform the repository into a
blackboard when data related to the client or data of interest for the client change the
notifications to client software.
 This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the architecture
without the permission or concern of other clients.
 Data can be passed among clients using the blackboard mechanism.

Advantages of Data centered architecture:

 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy
 Data centered architecture

2] Data flow architectures:

 This kind of architecture is used when input data is transformed into output data through
a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and filter and it
has a set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain form
and produces data output to the next filter of a specified form. The filters don’t require
any knowledge of the working of neighboring filters.
 If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

Advantages of Data Flow architecture:

 It encourages upkeep, repurposing, and modification.
 With this design, concurrent execution is supported.

Disadvantage of Data Flow architecture:

 It frequently degenerates to batch sequential system
 Data flow architecture does not allow applications that require greater user engagement.
 It is not easy to coordinate two different but related streams

Data Flow architecture

3] Call and Return architectures

It is used to create a program that is easy to scale and modify. Many sub-styles exist within
this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.
4] Object Oriented architecture
The components of a system encapsulate data and the operations that must be applied to
manipulate the data. The coordination and communication between the components are
established via the message passing.
Characteristics of Object Oriented architecture:
 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture:
 It enables the designer to separate a challenge into a collection of autonomous objects.
 Other objects are aware of the implementation details of the object, allowing changes to
be made without having an impact on other objects.

5] Layered architecture
 A number of different layers are defined with each layer performing a well-defined set of
operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
 At the outer layer, components will receive the user interface operations and at the inner
layers, components will perform the operating system interfacing(communication and
coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication system.
 Layered architecture

Software Design Patterns Tutorial


Software design patterns are communicating objects and classes that are customized to solve
a general design problem in a particular context. Software design patterns are general,
reusable solutions to common problems that arise during the design and development of
software. They represent best practices for solving certain types of problems and provide a
way for developers to communicate about effective design solutions.

Understanding and applying these patterns can significantly enhance your software
development skills. For those looking to deepen their knowledge and application of software
design patterns, our comprehensive system design course offers a structured approach to
mastering these essential concepts. By learning from real-world examples and expert insights,
you can develop the expertise to effectively implement these patterns in your projects.
Types of Creational Design Patterns:
1. Factory Method Design Pattern
The Factory Method pattern is used to create objects without specifying the exact class of
object that will be created. This pattern is useful when you need to decouple the creation of
an object from its implementation.
2. Abstract Factory Method Design Pattern
Abstract Factory pattern is almost similar to Factory Pattern and is considered as another
layer of abstraction over factory pattern. Abstract Factory patterns work around a super-
factory which creates other factories.
3. Singleton Method Design Pattern
The Singleton method or Singleton Design pattern is one of the simplest design patterns. It
ensures a class only has one instance, and provides a global point of access to it.
4. Prototype Method Design Pattern
Prototype allows us to hide the complexity of making new instances from the client. The
concept is to copy an existing object rather than creating a new instance from scratch,
something that may include costly operations. The existing object acts as a prototype and
contains the state of the object.
5. Builder Method Design Pattern
Builder pattern aims to “Separate the construction of a complex object from its representation
so that the same construction process can create different representations.” It is used to
construct a complex object step by step and the final step will return the object.
Structural Design Patterns
Structural Design Patterns are concerned with how classes and objects are composed to form
larger structures. Structural class patterns use inheritance to compose interfaces or
implementations.
Types of Structural Design Patterns:

1. Adapter Method Design Pattern

The adapter pattern convert the interface of a class into another interface clients expect.
Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
2. Bridge Method Design Pattern
The bridge pattern allows the Abstraction and the Implementation to be developed
independently and the client code can access only the Abstraction part without being
concerned about the Implementation part.
3. Composite Method Design Pattern
Composite pattern is a partitioning design pattern and describes a group of objects that is
treated the same way as a single instance of the same type of object. The intent of a
composite is to “compose” objects into tree structures to represent part-whole hierarchies.
4. Decorator Method Design Pattern
It allows us to dynamically add functionality and behavior to an object without affecting the
behavior of other existing objects within the same class. We use inheritance to extend the
behavior of the class. This takes place at compile-time, and all the instances of that class get
the extended behavior.
5. Facade Method Design Pattern
Facade Method Design Pattern provides a unified interface to a set of interfaces in a
subsystem. Facade defines a high-level interface that makes the subsystem easier to use.
6. Flyweight Method Design Pattern
This pattern provides ways to decrease object count thus improving application required
objects structure. Flyweight pattern is used when we need to create a large number of similar
objects.
7. Proxy Method Design Pattern
Proxy means ‘in place of’, representing’ or ‘in place of’ or ‘on behalf of’ are literal meanings
of proxy and that directly explains Proxy Design Pattern. Proxies are also called surrogates,
handles, and wrappers. They are closely related in structure, but not purpose, to Adapters and
Decorators.
Behavioral Design Patterns
Behavioral Patterns are concerned with algorithms and the assignment of responsibilities
between objects. Behavioral patterns describe not just patterns of objects or classes but also
the patterns of communication between them. These patterns characterize complex control
flow that’s difficult to follow at run-time.
Types of Behavioral Design Patterns:

1. Chain Of Responsibility Method Design Pattern

Chain of responsibility pattern is used to achieve loose coupling in software design where a
request from the client is passed to a chain of objects to process them. Later, the object in the
chain will decide themselves who will be processing the request and whether the request is
required to be sent to the next object in the chain or not.
2. Command Method Design Pattern
The Command Pattern is a behavioral design pattern that turns a request into a stand-alone
object, containing all the information about the request. This object can be passed around,
stored, and executed at a later time
3. Interpreter Method Design Pattern
Interpreter pattern is used to defines a grammatical representation for a language and
provides an interpreter to deal with this grammar.
4. Mediator Method Design Pattern
It enables decoupling of objects by introducing a layer in between so that the interaction
between objects happen via the layer.
5. Memento Method Design Patterns
It is used to restore state of an object to a previous state. As your application is progressing,
you may want to save checkpoints in your application and restore back to those checkpoints
later. Intent of Memento Design pattern is without violating encapsulation, capture and
externalize an object’s internal state so that the object can be restored to this state later.
6. Observer Method Design Pattern
It defines a one-to-many dependency between objects, so that when one object (the subject)
changes its state, all its dependents (observers) are notified and updated automatically.
7. State Method Design Pattern
A state design pattern is used when an Object changes its behavior based on its internal state.
If we have to change the behavior of an object based on its state, we can have a state variable
in the Object and use the if-else condition block to perform different actions based on the
state.
8. Strategy Method Design Pattern
The Strategy Design Pattern allows the behavior of an object to be selected at runtime. It is
one of the Gang of Four (GoF) design patterns, which are widely used in object-oriented
programming. The Strategy pattern is based on the idea of encapsulating a family of
algorithms into separate classes that implement a common interface.
9. Template Method Design Pattern
Template method design pattern is to define an algorithm as a skeleton of operations and
leave the details to be implemented by the child classes. The overall structure and sequence
of the algorithm are preserved by the parent class.
10. Visitor Method Design Pattern
It is used when we have to perform an operation on a group of similar kind of Objects. With
the help of visitor pattern, we can move the operational logic from the objects to another
class.

Frequently Asked Questions About Software Design Patterns

1. What are software design patterns?

 Software design patterns are reusable solutions to common problems that arise during
software development. They are templates for solving recurring design issues and
provide a way to create flexible, scalable, and maintainable software systems.
2. Why are design patterns important in software development?
 Design patterns promote best practices, enhance code readability, and facilitate code
reuse. They help in creating software that is modular, extensible, and easier to maintain,
reducing development time and efforts.
3. How do design patterns differ from algorithms?
 Design patterns focus on solving recurring design problems at the architectural or
structural level, emphasizing the organization of code. Algorithms, on the other hand, are
step-by-step procedures for solving specific problems at the computational level.
4. What are the common types of design patterns?
 Design patterns are categorized into three main types: creational, structural, and
behavioral. Creational patterns deal with object creation, structural patterns with object
composition, and behavioral patterns with object collaboration and responsibility.
5. Can you provide examples of creational design patterns?
 Examples include Singleton (ensuring a class has only one instance), Factory Method
(creating objects without specifying the exact class), and Abstract Factory (providing an
interface for creating families of related or dependent objects).
6. How do design patterns enhance code flexibility?
 Design patterns promote loose coupling between components, making it easier to replace
or extend parts of the system without affecting others. This flexibility is crucial for
adapting to changing requirements.
7. When should I use design patterns?
 Design patterns should be used when you encounter recurring problems in software
design. They are particularly beneficial in complex systems where a systematic and
proven approach to design is required.
8. Are design patterns language-specific?
 No, design patterns are not tied to a specific programming language. They are conceptual
solutions that can be implemented in various languages. However, the syntax and
implementation details may vary.
9. How can I learn and master design patterns?
 Start by understanding the basic principles of design patterns. Practice implementing
them in your projects and study real-world examples. Books, online tutorials, and
practical application in projects contribute to mastering design patterns.
10. Are design patterns applicable in all software projects?
 While design patterns offer valuable solutions to common design problems, their
applicability depends on the context and complexity of the project. In simpler projects,
some patterns may be unnecessary, while in larger projects, they can be instrumental in
maintaining a scalable and organized codebase.
11. What’s the difference between a design pattern and an anti-pattern?
 Design patterns are proven solutions to common problems, promoting best practices. In
contrast, anti-patterns are common pitfalls or bad practices that can lead to poor software
design and should be avoided.
12. Can design patterns be overused?
 Yes, overusing design patterns without considering the context and complexity of the
project can lead to unnecessarily complex code. It’s important to apply design patterns
judiciously, where they add value and improve code structure.
13. Can I create my own design patterns?
 Yes, you can create custom design patterns based on your project’s specific needs.
However, it’s crucial to ensure that the pattern addresses a recurring problem and follows
the principles of good design.
14. How do design patterns relate to code smell?
 Design patterns help eliminate code smells (indications of poor design) by providing
proven solutions to common problems. Recognizing and addressing code smells is
essential for creating maintainable and efficient software.
15. Are there design patterns for database design?
 While traditional design patterns may not directly apply to database design, principles
like normalization and denormalization can be considered as design patterns for creating
efficient and scalable database structures.
16. Can design patterns be used in microservices architecture?
 Yes, design patterns can be applied in microservices architecture to address common
challenges such as service discovery, communication between services, and fault
tolerance. Patterns like the Service Registry and Circuit Breaker are relevant.
17. How do design patterns impact system performance?
 Properly applied design patterns can enhance system performance by promoting efficient
code organization and reducing redundancy. However, poorly chosen or overused
patterns may introduce unnecessary complexity, potentially impacting performance.
18. Do junior developers need to learn design patterns?
 While not mandatory, learning design patterns can significantly benefit junior developers
by providing them with proven solutions to common problems. It can expedite the
learning process and contribute to writing more maintainable code.
19. How do design patterns contribute to code documentation?
  Design patterns inherently document solutions to common design problems. When
developers are familiar with design patterns, the code becomes self-documenting,
making it easier for others to understand and contribute to the project.
20. Can design patterns be applied retroactively to existing codebases?
 Yes, design patterns can be applied retroactively, but the process may involve refactoring
existing code. It’s crucial to assess the impact of introducing a pattern and ensure that it
aligns with the overall architecture.
21. Are there design patterns for web development?
 Yes, many design patterns are applicable in web development. Patterns like MVC,
Observer, and Singleton are commonly used to organize and structure code in both
frontend and backend development.
22. How do design patterns differ from architectural patterns?
 Design patterns address specific design issues at a lower level, focusing on object
creation, composition, and interaction. Architectural patterns, on the other hand, deal
with higher-level structures of an entire application or system.
23. Can design patterns be used in functional programming?
 Yes, design patterns can be adapted for functional programming paradigms. Functional
design patterns focus on composing functions to solve problems and promote
immutability and statelessness.
24. What role do design patterns play in code maintainability during team
collaboration?
 Design patterns contribute to code maintainability by providing a common vocabulary
and structure. When a team is familiar with design patterns, collaboration becomes more
efficient, and team members can understand and reason about the codebase more easily.
25. Are there design patterns specifically for real-time systems?
 Yes, real-time systems often utilize design patterns tailored to address their unique
challenges. Patterns like the Observer pattern can be applied to handle real-time event
notification and synchronization.

Separation of Concerns (SoC)


Separation of Concerns (SoC) is a fundamental principle in software engineering and
design aimed at breaking down complex systems into smaller, more manageable parts. The
goal is to organize a system’s components in a way that each part addresses a single concern,
or a cohesive aspect of functionality, rather than mixing multiple concerns together. This
approach enhances modularity, maintainability, and scalability of software systems.

What does SoC stand for?

SoC stands for “Separation of Concerns“
The term “Separation of Concerns” (SoC) originates from the field of software engineering
and design, but its name draws inspiration from broader principles found in systems theory
and problem-solving methodologies. The term “concern” refers to any distinct aspect or
responsibility within a system.
Why it’s called “Separation of Concerns” ?
1. Separation: The word “separation” emphasizes the act of isolating or distinguishing
different concerns within a system. By separating concerns, software engineers aim to
 create clearer boundaries and reduce the interdependence between different parts of the
system.
2. Concerns: In the context of software, a “concern” represents a specific aspect of
functionality, behaviour, or responsibility within the system. For example, concerns
might include user interface presentation, data storage and retrieval, business logic
processing, error handling, security, etc. Each concern represents a cohesive aspect that
can be managed independently.
Bringing these two concepts together, “Separation of Concerns” highlights the practice of
organizing a software system in a way that each part (or component) addresses a single
concern, without mixing multiple concerns together. This approach enhances modularity,
maintainability, and scalability of software systems by making them easier to understand,
modify, and extend over time.

What is SoC?
In the context of software development, Separation of Concerns is a design principle aimed at
breaking down complex systems into smaller, more manageable parts. The goal is to organize
a system’s components in a way that each part addresses a single concern or aspect of
functionality, rather than mixing multiple concerns together. This approach enhances
modularity, maintainability, and scalability of software systems.

Origin of Separation of Concerns (SoC)

The concept of Separation of Concerns (SoC) originated in the field of software engineering.
It has its roots in early computing and programming practices but gained prominence as a
recognized principle during the evolution of software engineering methodologies.
While the precise origin of the term “Separation of Concerns” is not attributed to a specific
individual or moment, the underlying principles have been evident in various programming
paradigms and methodologies over the years. Here’s a brief overview of its evolution:

1. Structured Programming Era (1960s-1970s): In the early days of programming, there

was a focus on writing code that was structured, organized, and easy to understand. This
era saw the development of structured programming languages like ALGOL, Pascal, and
later, C. The emphasis was on breaking down programs into smaller, more manageable
functions or procedures, which can be seen as an early form of separating concerns.

2. Object-Oriented Programming (OOP) Paradigm (1980s): The concept of Separation

of Concerns became more prominent with the rise of Object-Oriented Programming
(OOP). OOP introduced the idea of encapsulating data and behavior within objects,
which naturally led to the separation of concerns between different objects. The Single
Responsibility Principle (SRP), a key tenet of OOP, further emphasized the importance
of designing classes that have a single responsibility.

3. Software Engineering Practices (1990s-Present): As software systems became larger

and more complex, the need for better design principles became apparent. Separation of
Concerns emerged as a fundamental principle in software engineering methodologies
such as Structured Design, Modular Programming, and later, Component-Based
Development. It became recognized as a guiding principle for designing modular,
maintainable, and scalable software systems.

4. Design Patterns and Architectural Patterns: The concept of SoC is also reflected in
various design patterns and architectural patterns used in software development. Patterns
 such as Model-View-Controller (MVC), Layered Architecture, and Microservices
Architecture promote the separation of concerns by defining clear boundaries between
different components or layers of a system.

The concept of Separation of Concerns (SoC) has evolved over time as a response to the
growing complexity of software systems and the need for better design practices. Here’s an
overview of its evolution:

1. Early Programming Practices (1950s-1960s):

 In the early days of computing, programs were often written in machine code or
low-level languages, with little emphasis on organization or modularity.
 As programming languages evolved, developers began to adopt structured
programming practices, which encouraged breaking down programs into smaller,
more manageable units. This laid the foundation for separating concerns, albeit in a
rudimentary form.

2. Structured Programming Era (1960s-1970s):

 The structured programming movement, led by computer scientists like Edsger
Dijkstra, Tony Hoare, and Niklaus Wirth, promoted the use of structured control
flow constructs such as loops and conditionals to improve code readability and
maintainability.
 Structured programming languages like ALGOL, Pascal, and later C provided
constructs for modularizing code into functions and procedures, enabling developers
to separate different concerns into distinct modules.

3. Object-Oriented Programming (OOP) Paradigm (1980s):

 The rise of Object-Oriented Programming (OOP) introduced new principles for
managing complexity, including encapsulation, inheritance, and polymorphism.
 OOP encouraged the organization of code into objects, each responsible for a
specific concern or aspect of functionality. This naturally led to a clearer separation
of concerns, with each object encapsulating its data and behavior.

4. Formalized Design Principles (1990s-Present):

 In the 1990s, as software systems became larger and more complex, formalized
design principles and methodologies emerged to address the challenges of software
engineering.
 Principles such as the Single Responsibility Principle (SRP), Dependency Inversion
Principle (DIP), and Interface Segregation Principle (ISP), introduced by Robert C.
Martin (Uncle Bob) and others, emphasized the importance of separating concerns
and designing modular, loosely coupled systems.

5. Architectural Patterns and Frameworks:

 Architectural patterns such as Model-View-Controller (MVC), Layered
Architecture, and Microservices Architecture provide blueprints for organizing
systems into distinct layers or components, each addressing a specific concern.
 Frameworks and libraries built around these patterns provide developers with tools
and conventions for implementing separation of concerns effectively in their
applications.

6. Continued Evolution and Adoption:

  The evolution of software engineering practices, along with advances in
programming languages, tools, and technologies, continues to shape the way
separation of concerns is implemented in modern software systems.
 As software development methodologies evolve, SoC remains a fundamental
principle guiding developers in designing modular, maintainable, and scalable
software systems.
Overall, the evolution of Separation of Concerns reflects a gradual progression toward more
organized, modular, and maintainable software designs, driven by the need to manage
complexity and improve software quality.

Why is separation of concerns important?

Separation of Concerns (SoC) is important in software engineering for several reasons:

1. Modularity: SoC encourages breaking down complex systems into smaller, more
manageable parts, each addressing a single concern. This modular approach makes it
easier to understand, develop, and maintain software systems, as developers can focus on
individual components without being overwhelmed by the system as a whole.
2. Maintainability: By separating concerns, changes and updates to one aspect of the
system are less likely to impact other parts. This reduces the risk of unintended side
effects and makes it easier to maintain and evolve the software over time. Additionally,
when modifications are required, developers can locate and modify the relevant module
without affecting the entire system.
3. Scalability: SoC promotes a design that allows for easy scalability. As the requirements
of a system change or grow, new concerns can be addressed by adding or modifying
individual modules without necessitating extensive changes to other parts of the system.
This flexibility allows software systems to adapt to evolving needs efficiently.
4. Reusability: Separating concerns often leads to the creation of reusable components.
Once a concern has been isolated into a distinct module, it can be reused across different
parts of the system or even in entirely different projects. This reduces development time
and effort and promotes consistency across applications.
5. Parallel Development: SoC facilitates parallel development by providing clear
boundaries between different parts of the system. Multiple developers can work on
separate concerns concurrently without stepping on each other’s toes, leading to more
efficient development workflows and shorter time-to-market.
6. Understanding and Debugging: With concerns separated into distinct modules, it
becomes easier to understand and debug software systems. Developers can focus on one
concern at a time, isolating and analyzing issues without being distracted by unrelated
functionality. This leads to faster diagnosis and resolution of problems.

Overall, Separation of Concerns is a foundational principle in software engineering that

contributes to the creation of modular, maintainable, and scalable software systems. By
organizing code in a way that isolates different concerns, developers can build software that
is easier to develop, understand, and evolve over time.

Why is Separation of Concerns important for a Software Developer?

Separation of Concerns (SoC) is important for software developers for several reasons:
1. Clarity and Understandability: SoC promotes clear organization within software
systems, making it easier for developers to understand the codebase. By separating
concerns into distinct modules or components, developers can focus on understanding
 and working with one aspect of the system at a time, reducing cognitive overload and
improving comprehension.
2. Maintainability and Extensibility: Software systems are often subject to change,
whether due to bug fixes, feature enhancements, or evolving requirements. SoC
facilitates maintainability and extensibility by localizing changes to specific concerns.
Developers can modify or extend individual modules without affecting other parts of the
system, reducing the risk of unintended consequences and making maintenance tasks
more manageable.
3. Collaboration: In collaborative development environments, SoC provides clear
boundaries between different areas of responsibility, enabling multiple developers to
work concurrently on separate concerns without interfering with each other’s work. This
promotes productivity and facilitates smoother collaboration among team members.
4. Reusability: By isolating concerns into modular components, SoC encourages the
creation of reusable code. Once a concern has been implemented in a separate module, it
can be reused across multiple parts of the system or even in different projects, reducing
development time and effort and promoting consistency and standardization.
5. Testing and Debugging: SoC simplifies testing and debugging processes by enabling
developers to focus on individual concerns in isolation. Unit testing becomes more
straightforward as developers can write focused tests for each module, ensuring that it
behaves correctly under different conditions. When issues arise, developers can debug
specific concerns without being distracted by unrelated functionality, leading to faster
diagnosis and resolution of problems.
Overall, SoC is essential for software developers as it promotes clearer, more maintainable,
and more extensible codebases, facilitates collaboration, encourages code reuse, and
simplifies testing and debugging processes. By adhering to SoC principles, developers can
build software systems that are easier to develop, understand, maintain, and extend over time.
How SoC can be applied to programming functions?
Applying Separation of Concerns (SoC) to programming functions involves organizing the
functionality within each function in a way that separates different concerns or
responsibilities. Here are some techniques for applying SoC to programming functions:
1. Single Responsibility Principle (SRP): Each function should ideally have a single
responsibility or concern. This means that a function should focus on performing one
specific task or action. For example, a function responsible for calculating the total price
of items in a shopping cart should not also handle formatting the output for display.
2. Clear and Descriptive Naming: Functions should have clear and descriptive names that
reflect their purpose or concern. This makes it easier for developers to understand the
function’s behavior without needing to inspect its implementation. Good naming
conventions help maintain readability and promote SoC by clearly delineating the
responsibilities of each function.
3. Encapsulating Logic: Functions should encapsulate related logic within themselves
while keeping unrelated concerns separate. For example, if a function needs to perform
data validation before processing input, the validation logic should be encapsulated
within the function itself rather than spread across multiple functions or modules.
4. Avoiding Side Effects: Functions should ideally be free of side effects, meaning they
should not modify any state outside their scope or have unintended consequences beyond
their intended purpose. This promotes SoC by ensuring that each function’s behavior is
predictable and isolated from other parts of the system.
5. Modularization and Composition: Complex tasks can often be broken down into
smaller, more manageable functions, each addressing a specific concern. These functions
 can then be composed together to achieve the desired behavior, following the principles
of modularization and separation of concerns.
6. Testing and Debugging: Applying SoC to functions makes it easier to write focused
unit tests that verify each concern independently. By isolating concerns within functions,
developers can test each concern in isolation, facilitating easier debugging and
maintenance.
By applying these techniques, developers can design functions that are modular,
maintainable, and testable, ultimately leading to more robust and scalable software systems.
SoC for System Design
Applying Separation of Concerns (SoC) to system design involves organizing the various
components and layers of a system in a way that separates different concerns or aspects of
functionality. Here’s how SoC can be applied to system design:
1. Layered Architecture: Divide the system into layers, each responsible for a specific
concern or aspect of functionality. Common layers include presentation/UI, business
logic, data access, and infrastructure. This promotes modularity and allows for easier
maintenance and scalability.
2. Microservices Architecture: Decompose the system into smaller, independent services,
each responsible for a specific business function or domain. Each microservice
encapsulates its own data storage, business logic, and user interface, promoting
autonomy and scalability.
3. Component-Based Design: Design the system as a collection of reusable, self-contained
components, each addressing a specific concern. Components can be combined and
composed to build larger systems, promoting reusability and maintainability.
4. Service-Oriented Architecture (SOA): Organize the system into loosely coupled,
interoperable services that communicate through standardized interfaces. Each service
encapsulates a specific concern and can be independently deployed and scaled.
5. Clear Interfaces and Contracts: Define clear interfaces and contracts between different
components or layers of the system. This helps to encapsulate implementation details and
promotes loose coupling between modules, making the system more adaptable to change.
6. Domain-Driven Design (DDD): Identify and model the core domains and business
concerns of the system. Use bounded contexts to encapsulate each domain’s logic and
define clear boundaries between different areas of responsibility.
7. Separate Cross-Cutting Concerns: Identify and separate cross-cutting concerns, such
as logging, security, and error handling, from the core business logic of the system. Use
aspect-oriented programming (AOP) or other techniques to modularize and encapsulate
these concerns.
8. Modularization and Composition: Break down the system into smaller, more
manageable modules or components, each addressing a specific concern. These modules
can then be composed together to form the complete system, following the principles of
modularization and separation of concerns.
9. Testing and Debugging: Apply SoC principles to testing and debugging by isolating
concerns within different parts of the system. Write focused tests that verify each
concern independently, making it easier to identify and diagnose issues.
By applying these principles, developers and architects can design systems that are modular,
maintainable, scalable, and adaptable to change, ultimately leading to more robust and
successful software solutions.
Application of SoC.
The application of Separation of Concerns (SoC) spans various aspects of software
development, including architecture, design, coding, and testing. Here are some specific ways
SoC is applied in each of these areas:
1. Architecture:
 Layered Architecture: Separating concerns into layers such as presentation,
business logic, and data access.
 Microservices Architecture: Decomposing the system into independent services,
each responsible for a specific concern.
 Service-Oriented Architecture (SOA): Organizing the system into loosely
coupled, interoperable services.
2. Design:
 Modularization: Breaking down the system into smaller, manageable modules,
each addressing a specific concern.
 Clear Interfaces: Defining clear interfaces between components to encapsulate
implementation details and promote loose coupling.
 Domain-Driven Design (DDD): Identifying and modeling core domains and
encapsulating domain logic within bounded contexts.
3. Coding:
 Single Responsibility Principle (SRP): Ensuring that functions, classes, and
modules have a single responsibility or concern.
 Encapsulation: Encapsulating related logic and data within functions, classes, or
modules while keeping unrelated concerns separate.
 Clear Naming: Using clear and descriptive names for functions, variables, and
classes to convey their purpose and responsibility.
4. Testing:
 Unit Testing: Writing focused unit tests that verify each concern independently.
 Integration Testing: Testing the interactions between modules or components to
ensure they work together as expected.
 Test Isolation: Isolating concerns within tests to make it easier to identify and
diagnose issues.
5. Debugging:
 Isolation: Isolating concerns within code to narrow down the source of bugs or
issues.
 Tracing and Logging: Separating logging and tracing concerns from business logic
to facilitate debugging.
 Error Handling: Handling errors and exceptions separately from core functionality
to improve error diagnosis and resolution.
6. Maintenance and Evolution:
 Change Isolation: Localizing changes to specific concerns, making it easier to
modify and maintain the system.
 Versioning and Dependency Management: Managing dependencies and
versioning to ensure changes in one concern do not affect others.
 Refactoring: Refactoring code to improve separation of concerns and
maintainability over time.
Advantages of SoC:
1. Modularity: SoC promotes breaking down complex systems into smaller, more
manageable parts, making it easier to understand, develop, and maintain software.
2. Maintainability: By separating concerns, changes and updates to one aspect of the
system are less likely to impact other parts. This reduces the risk of unintended side
effects and makes maintenance tasks more straightforward.
3. Scalability: SoC facilitates scalability by allowing different concerns or components of a
system to be scaled independently. This helps accommodate increased workload or
functionality without affecting the entire system.
 4. Reusability: Separating concerns often leads to the creation of reusable components.
Once a concern has been isolated into a distinct module, it can be reused across different
parts of the system or even in entirely different projects, reducing development time and
effort.
5. Clarity and Understanding: SoC enhances code readability and comprehension by
organizing code according to its purpose or functionality. This makes it easier for
developers to understand and work with the system, leading to faster development and
fewer errors.
6. Encapsulation: SoC encourages encapsulating related functionality within modules or
components, making it easier to manage complexity and reduce dependencies between
different parts of the system.
Disadvantages of SoC:
1. Overhead: Achieving a high level of separation of concerns can sometimes lead to
increased complexity and overhead, especially in systems with many interacting
components. This can result in higher development and maintenance costs.
2. Coordination Overhead: In systems with highly separated concerns, coordinating
interactions between different components or modules can become more challenging.
This may require additional effort to ensure proper communication and integration
between different parts of the system.
3. Performance Impact: Overly fine-grained separation of concerns can sometimes result
in performance overhead due to increased function calls, data transfers, or context
switches between different components.
4. Potential for Misuse: While SoC promotes modularity and encapsulation, there’s a risk
that developers may misinterpret the principle and overcomplicate the system by creating
too many layers or modules. This can lead to unnecessary abstraction and reduced code
maintainability.
5. Learning Curve: Adopting SoC requires developers to understand and apply the
principle effectively, which may involve a learning curve, especially for junior
developers or those new to software engineering best practices.
6. Increased Indirection: Achieving SoC often involves introducing layers of abstraction
or indirection between different parts of the system. While this can promote flexibility
and modularity, it can also make code more difficult to follow and debug, especially for
developers unfamiliar with the system’s architecture.
SoC vs Single Responsibility Principle (SRP):
SoC: Focuses on organizing code into distinct modules or components, each addressing a
specific concern, to improve modularity and maintainability.
SRP: Focuses on ensuring that a class or module has only one reason to change, i.e., it should
have a single responsibility. While SoC addresses concerns at a higher level of abstraction,
SRP deals with responsibilities at the level of individual classes or modules.

SoC vs Don’t Repeat Yourself (DRY):

SoC: Concerned with organizing code to separate different concerns or aspects of
functionality, reducing complexity and improving maintainability.
DRY: Focuses on reducing redundancy in code by ensuring that each piece of knowledge or
logic within a system has a single, unambiguous representation. While SoC focuses on
organizing code based on functionality, DRY focuses on avoiding duplication within code
implementations.
SoC vs Open/Closed Principle (OCP):
SoC: Separates concerns to allow for easier modification and extension of the system without
impacting other parts.
OCP: States that software entities should be open for extension but closed for modification.
While SoC addresses the organization of code into distinct concerns, OCP focuses on
designing modules and components that can be extended without modifying existing code.
SoC vs Dependency Inversion Principle (DIP):
SoC: Promotes loose coupling between different concerns or components of a system,
allowing them to be developed, tested, and maintained independently.
DIP: States that high-level modules should not depend on low-level modules but instead both
should depend on abstractions. SoC focuses on organizing code based on concerns, while
DIP focuses on decoupling high-level and low-level modules to improve flexibility and
testability.
SoC vs Single Source of Truth (SSOT):
SoC: Separates concerns to ensure that each part of a system is responsible for a distinct
aspect of functionality, reducing complexity and improving maintainability.
SSOT: Advocates for having a single, authoritative source of data or information within a
system to ensure consistency and accuracy. While SoC focuses on organizing code based on
functionality, SSOT focuses on managing data with a single, authoritative source.
Comparison of Separation of Concerns (SoC) with other related principles
Here’s a comparison of Separation of Concerns (SoC) with other related principles in a table
format:
Principle Description Focus

Organizes code into distinct modules or

Separation of components, each addressing a specific Organizing code based
Concerns (SoC) concern to improve modularity, on functionality
maintainability, and scalability.

Ensures that a class or module has only

Single Assigning a single
one reason to change, focusing on a
Responsibility responsibility to each
single responsibility to improve
Principle (SRP) class/module
cohesion and maintainability.

Reduces redundancy in code by ensuring

Avoiding duplication
Don’t Repeat that each piece of knowledge or logic
within code
Yourself (DRY) within a system has a single,
implementations
unambiguous representation.

States that software entities should be

Allowing for extension
Open/Closed open for extension but closed for
without modifying
Principle (OCP) modification, promoting modular and
existing code
extensible designs.

Encourages loose coupling between

Dependency
components by depending on Decoupling high-level
Inversion
abstractions rather than concrete and low-level modules
Principle (DIP)
implementations, promoting flexibility
 Principle Description Focus

and testability.

Advocates for having a single,

Managing data with a
Single Source of authoritative source of data or
single, authoritative
Truth (SSOT) information within a system to ensure
source
consistency and accuracy.

while each of these principles addresses different aspects of software design and
development, they often complement each other and are applied together to create well-
designed, maintainable, and scalable software systems. SoC plays a foundational role in
organizing code and architecture to improve clarity, modularity, and maintainability, while
other principles address more specific aspects of software design and development.

Modularity and its Properties


The module simply means the software components that are been created by dividing the
software. The software is divided into various components that work together to form a single
functioning item but sometimes they can perform as a complete function if not connected
with each other. This process of creating software modules is known as Modularity in
software engineering. It simply measures the degree to which these components are made up
than can be combined. Some of the projects or software designs are very complex that it’s not
easy to understand its working and functioning. In such cases, modularity is a key weapon
that helps in reducing the complexity of such software or projects. The basic principle of
Modularity is that “Systems should be built from cohesive, loosely coupled components
(modules)” which means s system should be made up of different components that are united
and work together in an efficient way and such components have a well-defined function. To
define a modular system, several properties or criteria are there under which we can evaluate
a design method while considering its abilities. These criteria are defined by Meyer. Some of
them are given below:
1. Modular Decomposability – Decomposability simply means to break down something
into smaller pieces. Modular decomposability means to break down the problem into
different sub-problems in a systematic manner. Solving a large problem is difficult
sometimes, so the decomposition helps in reducing the complexity of the problem, and
sub-problems created can be solved independently. This helps in achieving the basic
principle of modularity.
2. Modular Composability – Composability simply means the ability to combine modules
that are created. It’s actually the principle of system design that deals with the way in
which two or more components are related or connected to each other. Modular
composability means to assemble the modules into a new system that means to connect
the combine the components into a new system.
3. Modular Understandability – Understandability simply means the capability of being
understood, quality of comprehensible. Modular understandability means to make it
easier for the user to understand each module so that it is very easy to develop software
and change it as per requirement. Sometimes it’s not easy to understand the process
 models because of its complexity and its large size in structure. Using modularity
understandability, it becomes easier to understand the problem in an efficient way
without any issue.
4. Modular Continuity – Continuity simply means unbroken or consistent or uninterrupted
connection for a long period of time without any change or being stopped. Modular
continuity means making changes to the system requirements that will cause changes in
the modules individually without causing any effect or change in the overall system or
software.
5. Modular Protection – Protection simply means to keep something safe from any harms,
to protect against any unpleasant means or damage. Modular protection means to keep
safe the other modules from the abnormal condition occurring in a particular module at
run time. The abnormal condition can be an error or failure also known as run-time
errors. The side effects of these errors are constrained within the module.

INFORMATION HIDING
In computer science, information hiding is the principle of segregation of the design decisions
in a computer program that are most likely to change, thus protecting other parts of the
program from extensive modification if the design decision is changed.

FUNCTIONAL INDEPENDENCE
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.
Benefits of Independent modules/functions in a software design:
Since the functionality of the software have been broken down into atomic levels, thus
developers get a clear requirement of each and every functions and hence designing of the
software becomes easy and error free.
As the modules are independent they have limited or almost no dependency on other
modules. So, making changes in a module without affecting the whole system is possible
in this approach.
Error propagation from one module to another and further in whole system can be
neglected and it saves time during testing and debugging.
Independence of modules of a software system can be measured using 2 criteria
: Cohesion, and Coupling. These are explained as following below.
 Figure – Cohesion and Coupling between 2 modules
Cohesion:
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
A good software design requires high cohesion and low coupling.

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:

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 [Link] 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.

Data design is the first design activity, which results in less complex, modular and efficient
program structure. The information domain model developed during analysis phase is
transformed into data structures needed for implementing the software. The data objects,
attributes, and relationships depicted in entity relationship diagrams and
the information stored in data dictionary provide a base for data design activity. During the
data design process, data types are specified along with the integrity rules required for the
data. For specifying and designing efficient data structures, some principles should be
followed. These principles are listed below.

1. The data structures needed for implementing the software as well-as the operations
that can be applied on them should be identified.
2. A data dictionary should be developed to depict how different data objects interact
with each other and what constraints are to be imposed on the elements of data
structure.
3. Stepwise refinement should be used in data design process and detailed design
decisions should be made later in the process.
4. Only those modules that need to access data stored in a data structure directly should
be aware of the representation of the data structure.
5. A library containing the set of useful data structures along with the operations that can
be performed on them should be maintained.
6. Language used for developing the system should support abstract data types.

The structure of data can be viewed at three levels, namely, program component level,
application level, and business level. At the program component level, the design of data
structures and the algorithms required to manipulate them is necessary, if high-quality
software is desired. At the application level, it is crucial to convert the data model into
a database so that the specific business objectives of a system could be achieved. At
the business level, the collection of information stored in different databases should be
 reorganized into data warehouse, which enables data mining that has an influential impact
on the business.

Architectural Design – Software Engineering


The software needs an architectural design to represent the design of the software. IEEE
defines architectural design as “the process of defining a collection of hardware and software
components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of
these many architectural styles.
System Category Consists of
 A set of components(eg: a database, computational modules) that will perform a function
required by the system.
 The set of connectors will help in coordination, communication, and cooperation
between the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties of the
system.
The use of architectural styles is to establish a structure for all the components of the system.
Taxonomy of Architectural Styles
1] Data centered architectures:
 A data store will reside at the center of this architecture and is accessed frequently by the
other components that update, add, delete, or modify the data present within the store.
 The figure illustrates a typical data-centered style. The client software accesses a central
repository. Variations of this approach are used to transform the repository into a
blackboard when data related to the client or data of interest for the client change the
notifications to client software.
 This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the architecture
without the permission or concern of other clients.
 Data can be passed among clients using the blackboard mechanism.
Advantages of Data centered architecture:
 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy

Data centered architecture

2] Data flow architectures:
 This kind of architecture is used when input data is transformed into output data through
a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and filter and it
has a set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of a certain form
and produces data output to the next filter of a specified form. The filters don’t require
any knowledge of the working of neighboring filters.
 If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.
Advantages of Data Flow architecture:
 It encourages upkeep, repurposing, and modification.
 With this design, concurrent execution is supported.
Disadvantage of Data Flow architecture:
 It frequently degenerates to batch sequential system
 Data flow architecture does not allow applications that require greater user engagement.
 It is not easy to coordinate two different but related streams

Data Flow architecture

3] Call and Return architectures

It is used to create a program that is easy to scale and modify. Many sub-styles exist within
this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to present in a main
program or sub program architecture distributed among multiple computers on a
network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.
4] Object Oriented architecture
The components of a system encapsulate data and the operations that must be applied to
manipulate the data. The coordination and communication between the components are
established via the message passing.
Characteristics of Object Oriented architecture:
 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture:
 It enables the designer to separate a challenge into a collection of autonomous objects.
 Other objects are aware of the implementation details of the object, allowing changes to
be made without having an impact on other objects.
5] Layered architecture
 A number of different layers are defined with each layer performing a well-defined set of
operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
 At the outer layer, components will receive the user interface operations and at the inner
layers, components will perform the operating system interfacing(communication and
coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication system.
 User Interface Design – Software Engineering

The user interface is the front-end application view to which the user interacts to use the
software. The software becomes more popular if its user interface is:
1. Attractive
2. Simple to use
3. Responsive in a short time
4. Clear to understand
5. Consistent on all interface screens
Types of User Interface
1. Command Line Interface: The Command Line Interface provides a command prompt,
where the user types the command and feeds it to the system. The user needs to
remember the syntax of the command and its use.
2. Graphical User Interface: Graphical User Interface provides a simple interactive
interface to interact with the system. GUI can be a combination of both hardware and
software. Using GUI, the user interprets the software.
User Interface Design Process
 User Interface Design Process

The analysis and design process of a user interface is iterative and can be represented by a
spiral model. The analysis and design process of user interface consists of four framework
activities.
1. User, Task, Environmental Analysis, and Modeling
Initially, the focus is based on the profile of users who will interact with the system, i.e.,
understanding, skill and knowledge, type of user, etc., based on the user’s profile users are
made into categories. From each category requirements are gathered. Based on the
requirement’s developer understand how to develop the interface. Once all the requirements
are gathered a detailed analysis is conducted. In the analysis part, the tasks that the user
performs to establish the goals of the system are identified, described and elaborated. The
analysis of the user environment focuses on the physical work environment. Among the
questions to be asked are:
1. Where will the interface be located physically?
2. Will the user be sitting, standing, or performing other tasks unrelated to the interface?
3. Does the interface hardware accommodate space, light, or noise constraints?
4. Are there special human factors considerations driven by environmental factors?
2. Interface Design
The goal of this phase is to define the set of interface objects and actions i.e., control
mechanisms that enable the user to perform desired tasks. Indicate how these control
mechanisms affect the system. Specify the action sequence of tasks and subtasks, also called
a user scenario. Indicate the state of the system when the user performs a particular task.
Always follow the three golden rules stated by Theo Mandel. Design issues such as response
time, command and action structure, error handling, and help facilities are considered as the
design model is refined. This phase serves as the foundation for the implementation phase.
3. Interface Construction and Implementation
The implementation activity begins with the creation of a prototype (model) that enables
usage scenarios to be evaluated. As iterative design process continues a User Interface toolkit
that allows the creation of windows, menus, device interaction, error messages, commands,
and many other elements of an interactive environment can be used for completing the
construction of an interface.
4. Interface Validation
This phase focuses on testing the interface. The interface should be in such a way that it
should be able to perform tasks correctly, and it should be able to handle a variety of tasks. It
should achieve all the user’s requirements. It should be easy to use and easy to learn. Users
should accept the interface as a useful one in their work.
User Interface Design Golden Rules
The following are the golden rules stated by Theo Mandel that must be followed during the
design of the interface. Place the user in control:
1. Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: The user should be able to easily enter and exit the
mode with little or no effort.
2. Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some might
use touch screen, etc., Hence all interaction mechanisms should be provided.
3. Allow user interaction to be interruptible and undoable: When a user is doing a
sequence of actions the user must be able to interrupt the sequence to do some other
work without losing the work that had been done. The user should also be able to do
undo operation.
4. Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance to customize
the interface as user wants which allows different interaction mechanisms so that user
doesn’t feel bored while using the same interaction mechanism.
5. Hide technical internals from casual users: The user should not be aware of the
internal technical details of the system. He should interact with the interface just to do his
work.
6. Design for direct interaction with objects that appear on-screen: The user should be
able to use the objects and manipulate the objects that are present on the screen to
perform a necessary task. By this, the user feels easy to control over the screen.
Reduce the User’s Memory Load
1. Reduce demand on short-term memory: When users are involved in some complex
tasks the demand on short-term memory is significant. So the interface should be
designed in such a way to reduce the remembering of previously done actions, given
inputs and results.
2. Establish meaningful defaults: Always an initial set of defaults should be provided to
the average user, if a user needs to add some new features then he should be able to add
the required features.
 3. Define shortcuts that are intuitive: Mnemonics should be used by the user. Mnemonics
means the keyboard shortcuts to do some action on the screen.
4. The visual layout of the interface should be based on a real-world
metaphor: Anything you represent on a screen if it is a metaphor for a real-world entity
then users would easily understand.
5. Disclose information in a progressive fashion: The interface should be organized
hierarchically i.e., on the main screen the information about the task, an object or some
behavior should be presented first at a high level of abstraction. More detail should be
presented after the user indicates interest with a mouse pick.
Make the Interface Consistent
1. Allow the user to put the current task into a meaningful context: Many interfaces
have dozens of screens. So it is important to provide indicators consistently so that the
user know about the doing work. The user should also know from which page has
navigated to the current page and from the current page where it can navigate.
2. Maintain consistency across a family of applications: in The development of some set
of applications all should follow and implement the same design, rules so that
consistency is maintained among applications.
3. If past interactive models have created user expectations do not make changes unless
there is a compelling reason.
User interface design is a crucial aspect of software engineering, as it is the means by which
users interact with software applications. A well-designed user interface can improve the
usability and user experience of an application, making it easier to use and more effective.
Key Principles for Designing User Interfaces
1. User-centered design: User interface design should be focused on the needs and
preferences of the user. This involves understanding the user’s goals, tasks, and context
of use, and designing interfaces that meet their needs and expectations.
2. Consistency: Consistency is important in user interface design, as it helps users to
understand and learn how to use an application. Consistent design elements such as
icons, color schemes, and navigation menus should be used throughout the application.
3. Simplicity: User interfaces should be designed to be simple and easy to use, with clear
and concise language and intuitive navigation. Users should be able to accomplish their
tasks without being overwhelmed by unnecessary complexity.
4. Feedback: Feedback is significant in user interface design, as it helps users to
understand the results of their actions and confirms that they are making progress
towards their goals. Feedback can take the form of visual cues, messages, or sounds.
5. Accessibility: User interfaces should be designed to be accessible to all users, regardless
of their abilities. This involves considering factors such as color contrast, font size, and
assistive technologies such as screen readers.
6. Flexibility: User interfaces should be designed to be flexible and customizable, allowing
users to tailor the interface to their own preferences and needs.
Overall, user interface design is a key component of software engineering, as it can have a
significant impact on the usability, effectiveness, and user experience of an application.
Software engineers should follow best practices and design principles to create interfaces that
are user-centered, consistent, simple, and accessible.

What is Component Design?


Component design is all about taking complex software systems and making them into small,
reusable pieces or simply modules. These parts are responsible for directing certain
functionalities, so programming them is like building a puzzle with small pieces, which
eventually create more complex architectures. Component design exhibits a modularized
approach to software development where the units are organized systematically to facilitate
control of complexity and increase manageability.
 Elements being the fundamental building blocks of software architecture, they are mostly
responsible for enriching the software’s functionality or offering their services.
 When several features are executed in independent units called components, with this
approach modularity, reusability, and maintainability are ensured.
 This technique promotes flexibility and scalability, enabling the formation of dynamic
systems that are composed of more basic units that interlock each other.

Importance of Component-Based Design in Software Development

Component-based design leads to various beneficial outcomes at all the development life
stages of the software.
 It improves modularity, giving the possibility for all developers to work with different
parts separately without changing the whole system. This modularity enables code
reusability since components can be reused across several projects as this will save time
and effort.
 Component-based design is so important for maintainability as it results from being
broken down into different parts and depicts functionality, with which errors are easily
traced, and debugging, and testing are made possible.
 When it comes to scalability, component-based design forms another vital benefit. A
situation when a particular software system, as it turns out to be more complex, has to be
scalable enough, leads to making this ability the priority.
 Breaking down elements and establishing logical interfaces facilitate the creation of a
modular system that permits effortless integration of more capabilities without causing
the architecture to buckle. It highlights the fact that adaptable software systems can not
only be quickly modified but also evolve according to the changing requirements.
Characteristics of Component-Based Design
Below are the characteristics of component-based design:
 Modularity: Some parts of a program retain a certain function or service, essentially
serve as reusable software modules, interchangeable and therefore independent
components, enhancing flexibility in development, testing, and maintenance.
 Reusability: Component architectural features are envisioned to be adaptable to and
reusable on different projects giving rise to shorter development time and lower
overheads and making the work of developers much more easier and scientific.
 Interoperability: Components are connected through clearly defined interfaces,
ensuring that software systems maintain interaction continuity and carry out various
functions within their ecosystems.
 Encapsulation: Components have got encapsulated constructs, which precisely reveal
internal details at the interface level, through a provision of only a few interfaces
essential for interacting with other components, thus enforcing abstraction by hiding
underlying implementation details.
 Scalability: Component-based architectures simplify scalability by providing a way for
systems to grow organically via the addition or modification of components without the
impacting overall the architecture.
Types of Components
 UI Components
  User Interface components provide an easy and more convenient way to
encapsulate logic by combining presentational and visible elements such as
buttons, forms, and widgets.
 Service Components
 Service components are the base of business logic or application services, in
which they serve as the platform for activities such as data processing,
authentication, and communication with external systems.
 Data Components
 Through data abstraction and provision of interfaces for data access, data
components take care of database interaction issues and provide data
structures for querying, updating, and saving data.
 Infrastructure Components
 The hardware elements regard as fundamental services or resources like
logging, caching, security and communication protocols which a software
system depends on.
 Integration Components
 Integrated components for data communication and data exchange between
different systems or modules are the integration components, which enable
protocol translation, workflow orchestration, and data exchange.
 Reusable Components
 A reusable component, in turn, encapsulates common functionality or
algorithms that can be utilized across multiple projects as well as different
domains, which promotes code reuse and uniformity.
Principles of Component Design
Below are some important principles of component design:
 Single Responsibility Principle (SRP): Each element should have a comprehensive and
coherent task to ensure that the system is easily understandable, coherent, and stable.
 Open/Closed Principle (OCP): Module extendibility is an important aspect, while at the
same time when it comes to stability, developers should be able to extend or customize
functionality without the need to change the existing codebase.
 Interface Segregation Principle (ISP): Components must provide consistent interfaces,
which are purposeful to the specific needs of clients, and there shouldn’t be any excess
dependencies that are being carried along with it.
 Dependency Inversion Principle (DIP): Some parts need to be derived interfaces and
not implementation-specific ones, hence the functionality and exchangeability.
 Separation of Concerns (SoC): Components should broadly include different aspects of
job, such as display, business logic, and data accessing and these block does separate the
whole functionality to make it clear, maintainable and reusable.
Component Design Patterns
Component design patterns present the designer with patterns that can be reused to solve
typical problems that design architects face in the construction of component-based
architectures Such patterns carry guidance on the effective design and implementation of
components as well as the art of integrating these effectively. Some popular component
design patterns include:Some popular component design patterns include:
 Composite Pattern: The Composite pattern allows objects to be composed into tree
structures, treating individual objects and compositions of objects uniformly.
 Decorator Pattern: The decorator pattern provides the facility of dynamic enhancement
in the object behavior by wrapping decorators that are added to existing functionalities
without changing the interface.
 Adapter Pattern: Through Adapter pattern, interface incompatibility issues are solved
as a bridge is built that translates requests from one interface to another by using this
one.
 Factory Pattern: Factory pattern comprehends the process of preparing objects, with the
outcome of providing customers the ability to create objects without specifying their
concrete classes, hence facilitating flexibility and decoupling.
 Observer Pattern: The Observer pattern constitutes a unidirectional link between
objects, a one-to-many dependency, where objects notifying and updating other objects
automatically, as their state changes.
 Facade Pattern: The Facade pattern provides a simplified interface to a complex
system, encapsulating its intricate details and presenting a unified interface to clients.
 Singleton Pattern: The Singleton pattern, which ensures that a class has only one
instance and grants global access to that object, enables one to control centralized access
to shared objects and data.
Component Lifecycle Management
Component Lifecycle Management is a systematic approach to managing the lifecycle of
software components from their creation to decommissioning.
 Stage 1: Creation: Components either get initialized statically or dynamically at design
time based on the needs of the program and according to the entire program or system
architecture.
 Stage 2: Initialization: Components are set up, configured and prepared for use, usually
this include parameterization, allocation of resources and the side setup.
 Stage 3: Utilization: Components are utilized within the software system, fulfilling their
designated functionalities and interacting with other components as necessary.
 Stage 4: Maintenance: Components undergo maintenance activities such as updates,
bug fixes, and optimizations to ensure continued functionality and performance.
 Stage 5: Decommissioning: Components are decommissioned, or disposed, when they
are no longer needed, either from obsolescence, redundancy, or architectural changes.
Tools and Technologies for Component Design
 Component Frameworks: Components frameworks for instance, Angular, React, and
[Link] include a variety of pre-built components, templates, and utilities for building user
interfaces that users can interact.
 Dependency Injection Containers: Injection Containers of IoC nature like Spring IoC,
Guice and Dagger can take the control of inversion by managing the component
dependencies as well as the producing the instances for the dependent classes.
 Middleware Platforms: API middleware systems like Apache Camel or MuleSoft or
RabbitMQ connect different system and services by means of message routing,
transformation, and mediation.
 Component Repositories: These repositories like npm, Maven Central, and NuGet pool
together the storage, sharing, and discovery of libraries and reusable components.
 Component Testing Tools: Tools like Jest, JUnit, and Mockito are used for automated
testing of components; this lets their functionality, reliability and adherence to
specification to be verified.
Challenges of Component Design
Below are the challenges of component design:
 Granularity: Proper level of granularity is what designers of components need to choose
accurately, as excessively fine components tend to clutter and increase overhead, while
coarse grained ones are inappropriately inflexible and have a limited ability to reuse.
 Interoperability: Maintaining the seamless operation of components from unmixed
vendors or technologies may be a difficult task. For this reason standardized interfaces,
protocols and compatibility tests have to be carried out.
 Dependency Management: Keeping dependencies between the components, such as
versions, compatibility, and conflicts can be extremely difficult especially in the bigger
systems, which have a augmented number of dependencies.
 Performance Overhead: The component-based architectures may produce performance
overhead for its added levels of abstraction, communication and runtime dependency
which require meticulous optimization and profiling thus may result in runtime
performance issues.

Component design gets the credit for being the foundation of all modern software
developments plus bringing in a concept that spawns complex systems using the modular and
reusable elements. The component-based design that promotes modularity, reusable and
hidden code patterns, will allow developers to achieve agility, scalability, and
maintainability, which respectively provide a relevant solution to the modern software issues.