Software Engineering/CS3CO40

III Year-V Sem.

Session : Aug-Dec. 2024 (AY-2024-25)

Prepared By :
Mr. Pradeep Baniya
Asst. Prof.
CSE, Dept. MU Indore
 Unit-1
Introduction of Software
1. Problem and Prospects
2. Software development process
I. System Development Life Cycle
II. Process Models:- (Waterfall Model, Spiral Model and Other

Process Models)
3. Unified process Agile development
I. Agile Process- Extreme Programming
II. Other agile Process models (Lean, Kanban)
 Introduction of Software

The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written by developers

on any of various particular computer languages.

Computer programs and related documentation such as requirements, design models

and user manuals.

Engineering is the application of scientific and practical knowledge to invent,

design, build, maintain, and improve frameworks, processes, etc.
Introduction of Software
 Introduction of Software

Software Engineering is an engineering branch related to the evolution of software

product using well-defined scientific principles, techniques, and procedures. The
result of software engineering is an effective and reliable software product.
 Introduction of Software
Why is Software Engineering required?
 Introduction of Software

Why is Software Engineering required?

• Handling Big Projects: A corporation must use a software engineering methodology in

order to handle large projects without any issues.

• To manage the cost: Software engineering programmers plan everything and reduce all

those things that are not required.

• To decrease time: It will save a lot of time if you are developing software using a

software engineering technique.

• Reliable software: It is the company’s responsibility to deliver software products on

schedule and to address any defects that may exist.

 Introduction of Software

• Effectiveness: Effectiveness results from things being created in accordance with the

standards.
• Reduces complexity: Large challenges are broken down into smaller ones and solved one

at a time in software engineering. Individual solutions are found for each of these issues.
• Productivity: Because it contains testing systems at every level, proper care is done to

maintain software productivity.

 Introduction of Software
Problems : Difficulty of Software Engineering and Ways to Overcome Common
Software Engineering Challenges
1. Rapid Advancement of Technology
2. Growing Customer Demands
3. Time Constraints
4. Limited Infrastructure
5. Software Testing Conflicts
6. Changing Requirements
7. Limited Time and Resources
8. Security
9. Scalability
10. High Availability
 Software Development Process

• Definition: A software development process is a way to improve design and product

management by breaking software development work into smaller steps or sub-processes

that can be done in parallel or in-order.
• The Software Development Process is the structured approach to developing software for a

system or project, sometimes called the Software Development Life Cycle (SDLC).
• There are several approaches (see Software Development Approaches) that can be used to

include waterfall, spiral, and incremental development.

• These different approaches will focus the testing effort at different points in the

development process. However, each approach is composed of the same basic steps of
development.
 Purpose of Software Development Process

• A solid software development process ensures that high-quality software products are

made quickly and well. A well-thought-out and well-executed method has several
advantages:
1. Quality assurance

2. Consistency and repeatability

3. Collaboration and coordination

4. Risk management

5. Scalability and efficiency

6. Continuous improvement
 Purpose of Software Development Process
Software Development Process Steps
The software development process consists of four major steps.

Step 1: Planning
Step 2: Implementation
Step 3: Testing
Step 4: Deployment and Maintenance
 Software Development Life Cycle (SDLC)

Software Development Life Cycle

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.
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.
Software Development Life Cycle (SDLC)

SDLC Phases
 Software Development Life Cycle (SDLC)

Software Development Life Cycle

The different phases of SDLC include planning, requirements, design, development, testing,
deployment, and maintenance.

Several SDLC models exist, including the waterfall model, spiral model, V-shaped model,
iterative model and agile model. The use of SDLC enables programmers to work concurrently
and evaluate each part of the software development process effectively.

***It is important to note that SDLC is a process and not a technique.

 Software Development Life Cycle (SDLC)

Phases in SDLC
There are various phases in the Software Development Life Cycle (SDLC), which are as
follows:
1. Requirement Gathering Phase

2. Analysis Phase
3. Design Phase
4. Development Phase
5. Testing Phase

6. Deployment & Maintenance Phase

 Software Development Life Cycle (SDLC)
SDLC Models
There are many different SDLC Models for implementation in the software development
process. The most important and popular ones are:
1. Waterfall or Linear Sequential Model
2. Iterative Waterfall Model
3. Incremental
4. Evolutionary Model(Combination of Iterative and Incremental Model)
5. Spiral Model
6. Prototype Model
7. RAD Model
8. Component Assembly Model
SDLC Models
 SDLC Models

• When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:
1. When the requirements are constant and not changed regularly.

2. A project is short

3. Where the tools and technology used is consistent and is not changing

4. When resources are well prepared and are available to use.

 SDLC Models
• Advantages of Waterfall model

Today, Agile methodology is often used in place of the waterfall model. However, there are
advantages to the waterfall approach, such as the following:
1. enables large or changing teams to move toward a common goal that's been defined in the
requirements stage;
2. forces structured, disciplined organization;
3. simplifies understanding, following and arranging tasks;
4. facilitates departmentalization and managerial control based on the schedule or deadlines;
5. reinforces good coding habits to define before implementing design and then code;
6. enables early system design and specification changes to be easily done; and
7. clearly defines milestones and deadlines.
 SDLC Models
• Disadvantages of Waterfall model
1. Disadvantages of the waterfall model typically center around the risk associated with a lack of revision
and flexibility. Specific issues include the following:
2. Design isn't adaptive; when a flaw is found, the entire process often needs to start over.
3. Method doesn't incorporate mid process user or client feedback, and makes changes based on results.
4. Waterfall model delays testing until the end of the development lifecycle.
5. It doesn't consider error correction.
6. The methodology doesn't handle requests for changes, scope adjustments and updates well.
7. Waterfall doesn't let processes overlap for simultaneous work on different phases, reducing overall
efficiency.
8. No working product is available until the later stages of the project lifecycle.
9. Waterfall isn't ideal for complex, high-risk ongoing projects.
2. Iterative Waterfall Model
• When to use the Iterative Waterfall Model

1. Requirements are well known and stable.

2. Technology is understood.

3. Experienced development team.

• Iterative Waterfall Model strengths

1. Easy to understand, easy to use.

2. Provides a reference for inexperienced staff.

3. Milestones are well understood by the team.

4. It provides requirements stability.

5. Facilitates strong management controls.

• Iterative Waterfall Model deficiencies

1. All requirements must be known upfront.

2. Deliverables created for each phase are considered frozen.

3. It can give a false impression of progress as there is no output until the project’s

completion.
4. Integration is one big bang at the end.

5. Little opportunity for the customer to preview the system.

3. Incremental Model
• When to Use an Incremental Model

1. The incremental model can be used when:

2. the objectives of the entire system are clearly stated and recognized, though some details

can evolve at each increment over time.

3. there's a pressing need to get a product to market as soon as possible.

4. the consumer expects the product to be readily available as soon as possible.

5. there's a need to get a product to the market early.

6. new technology is being deployed.

7. the software team is inexperienced or unskilled.

8. a project's development timeline is prolonged.

9. there are some high-risk features and goals.

10. there are no resources with the necessary skills.

• Pros of the Incremental Model

The incremental model offers many advantages, including the ability to risk-manage progress
and increase efficiency. Here are a few other advantages of this approach:
1. Improved efficiency—The incremental model can help to increase efficiency by allowing

teams to plan and organize work more effectively. This approach can also help to reduce
the risk of bottlenecks or dependency issues.
2. Risk-managed progress—Teams can risk-manage progress by testing their project in

stages. This means that they can identify and address issues as they emerge and make
adjustments as necessary.
3. Clear reporting and tracking—The incremental model allows teams to clearly report and

track their progress, which can help to improve project visibility and collaboration across
teams.
• Pros of the Incremental Model

4. Feedback is possible— In the incremental model, the user or the customer can submit

feedback at each level to avoid sudden changes.

5. Meeting goals—Once the requirements are mapped out, all software goals and objectives

can be satisfied completely through incremental development.

• Cons of Incremental Model

The incremental model is not suitable for every project and comes with some inherent risks,
including:
1. This model has to be carefully planned and designed at the beginning, or the entire goal of
incrementing will be defeated.
2. There's a risk that teams will lose focus and their project will become uncoordinated.
3. The iteration stages are rigorous, and they don't overlap.
4. If teams don't take time to plan their work and organize their project, they may end up
delivering low-quality work and falling behind schedule.
5. It can lead to wasted effort, as teams may continually have to renegotiate and reprioritize
work, which can lead to inefficiencies.
6. When there's a problem in one unit, it has to be fixed in all units, which is time-consuming.
4. Evolutionary Model
Evolutionary Model :-
An evolutionary model involves breaking down the software development process into
smaller, manageable increments or iterations. Each iteration involves the completion of a
subset of the overall software requirements, allowing for continuous testing, feedback, and
refinement. This approach enables the software to evolve and improve over time, as new
requirements and insights emerge.
In simple words, “Iterative” + “Incremental model” = Evolutionary model.
• Advantages and Disadvantages

Advantages Disadvantages

Allows for incremental development May require more time and effort to
and improvement manage and coordinate changes

Enables early delivery of working Requires a high level of collaboration

software and communication among team
members

Facilitates continuous feedback and May not be suitable for projects with
collaboration with stakeholders strict deadlines or fixed budgets

Reduces the risk of project failure by Can result in a less predictable and more
identifying issues early on uncertain development process
5. Prototype Model
Prototype Model :-
• In this process model, the system is partially implemented before or during the analysis

phase thereby giving the customers an opportunity to see the product early in the life cycle.
• The process starts by interviewing the customers and developing the incomplete high-level

paper model.
• This document is used to build the initial prototype supporting only the basic functionality

as desired by the customer.

• Once the customer figures out the problems, the prototype is further refined to eliminate

them. The process continues until the user approves the prototype and finds the working
model to be satisfactory.
Steps of Prototype Model
• Requirement Gathering and Analysis

• Quick Decision

• Build a Prototype

• Assessment or User Evaluation

• Prototype Refinement

• Engineer Product
Advantage of Prototype Model
• Reduce the risk of incorrect user requirement

• Good where requirement are changing/uncommitted

• Regular visible process aids management

• Support early product marketing

• Reduce Maintenance cost.

• Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model
• An unstable/badly implemented prototype often becomes the final product.

• Require extensive customer collaboration

❖ Costs customer money

❖ Needs committed customer

❖ Difficult to finish if customer withdraw

• Difficult to know how long the project will last.

• Easy to fall back into the code and fix without proper requirement analysis, design,

customer evaluation, and feedback.

• Prototyping tools are expensive.

• Special tools & techniques are required to build a prototype.

• It is a time-consuming process.
6. Spiral Model
Spiral Model
Spiral Model = Concept of Waterfall lifecycle+ Iterative model.
• The spiral model, is an evolutionary software process model that couples the iterative

feature of prototyping with the controlled and systematic aspects of the linear sequential
model.
• It implements the potential for rapid development of new versions of the software.

• Using the spiral model, the software is developed in a series of incremental releases.

• During the early iterations, the additional release may be a paper model or prototype.

• During later iterations, more and more complete versions of the engineered system are

produced.
Spiral Model
Each cycle in the spiral is divided into four parts:
• Objective setting: Each cycle in the spiral starts with the identification of purpose for that

cycle, the various alternatives that are possible for achieving the targets, and the constraints
that exists.
• Risk Assessment and reduction: The next phase in the cycle is to calculate these various

alternatives based on the goals and constraints. The focus of evaluation in this stage is
located on the risk perception for the project.
• Development and validation: The next phase is to develop strategies that resolve

uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.
Spiral Model
Each cycle in the spiral is divided into four parts:

• Planning: Finally, the next step is planned. The project is reviewed, and a choice made

whether to continue with a further period of the spiral. If it is determined to keep, plans are
drawn up for the next step of the project.
Spiral Model
When to use Spiral Model?
• When deliverance is required to be frequent.

• When the project is large

• When requirements are unclear and complex

• When changes may require at any time

• Large and high budget projects

Spiral Model
Advantages
• High amount of risk analysis

• Useful for large and mission-critical projects.

Disadvantages
• Can be a costly model to use.

• Risk analysis needed highly particular expertise

• Doesn't work well for smaller projects

7. RAD Model
7. RAD Model
RAD Model
• The RAD model is a type of incremental process model in which there is an extremely

short development cycle.

• When the requirements are fully understood and the component-based construction

approach is adopted then the RAD model is used.

• Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build

or Construction, and finally Deployment.

• The critical feature of this model is the use of powerful development tools and techniques.

• A software project can be implemented using this model if the project can be broken down

into small modules wherein each module can be assigned independently to separate teams.
RAD Model
• These modules can finally be combined to form the final product. Development of each

module involves the various basic steps as in the waterfall model i.e. analyzing, designing,
coding, and then testing, etc. as shown in the previous figure.
• Another striking feature of this model is a short period i.e. the time frame for

delivery(time-box) is generally 60-90 days.

• Multiple teams work on developing the software system using the RAD model parallely.
When to use RAD Model?
• When the customer has well-known requirements, the user is involved throughout the life

cycle, the project can be time-boxed, the functionality delivered in increments, high
performance is not required, low technical risks are involved and the system can be
modularized.
• In these cases, we can use the RAD Model. when it is necessary to design a system that can

be divided into smaller units within two to three months.

• when there is enough money in the budget to pay for both the expense of automated tools

for code creation and designers for modeling.

Advantages:
• The use of reusable components helps to reduce the cycle time of the project.

• Feedback from the customer is available at the initial stages.

• Reduced costs as fewer developers are required.

• The use of powerful development tools results in better quality products in comparatively

shorter time spans.

• The progress and development of the project can be measured through the various stages.

• It is easier to accommodate changing requirements due to the short iteration time spans.

• Productivity may be quickly boosted with a lower number of employees.

Disadvantages:
• The use of powerful and efficient tools requires highly skilled professionals.

• The absence of reusable components can lead to the failure of the project.

• The team leader must work closely with the developers and customers to close the project

on time.
• The systems which cannot be modularized suitably cannot use this model.

• Customer involvement is required throughout the life cycle.

• It is not meant for small-scale projects as in such cases, the cost of using automated tools

and techniques may exceed the entire budget of the project.

• Not every application can be used with RAD.
Applications:
• This model should be used for a system with known requirements and requiring a short

development time.
• It is also suitable for projects where requirements can be modularized and reusable

components are also available for development.

• The model can also be used when already existing system components can be used in

developing a new system with minimum changes.

• This model can only be used if the teams consist of domain experts. This is because

relevant knowledge and the ability to use powerful techniques are a necessity.
• The model should be chosen when the budget permits the use of automated tools and

techniques required.
Limitations/Drawbacks:
• It requires multiple teams or a large number of people to work on the scalable projects.

• This model requires heavily committed developer and customers. If commitment is lacking

then RAD projects will fail.

• The projects using RAD model requires heavy resources.

• If there is no appropriate modularization then RAD projects fail. Performance can be

problem to such projects.

• The projects using RAD model find it difficult to adopt new technologies.
8. Component Assembly Model
Component Based Development Model:
• This model uses various characteristics of spiral model.
• This model is evolutionary by nature.

• Hence, software development can be done using iterative approach.

• In CBD model, multiple classes can be used. These classes are basically the prepackaged

components.
The model works in following manner:
• Step-1: First identify all the required candidate components, i.e., classes with the help of

application data and algorithms.

• Step-2: If these candidate components are used in previous software projects then they

must be present in the library.

Component Based Development Model:
• Step-3: Such preexisting components can be excited from the library and used for further

development.
• Step-4: But if the required component is not present in the library then build or create the

component as per requirement.

• Step-5: Place this newly created component in the library. This makes one iteration of the

system.
• Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of

iterations required to develop the complete application.

Characteristics of Component Assembly Model:
• Uses object-oriented technology.

• Components and classes encapsulate both data and algorithms.

• Components are developed to be reusable.

• Paradigm similar to spiral model, but engineering activity involves components.

• The system produced by assembling the correct components.

Rational Unified Process
Rational Unified Process (RUP)
• RUP is a software development process for object-oriented models.

• It is also known as the Unified Process Model. It is created by Rational corporation and

is designed and documented using UML (Unified Modeling Language).

• This process is included in IBM Rational Method Composer (RMC) product.

• IBM allows us to customize, design, and personalize the unified process. RUP is proposed

by Ivar Jacobson, Grady Bootch, and James Rambaugh.

• Some characteristics of RUP include use-case driven, Iterative (repetition of the process),

and Incremental (increase in value) by nature.

• RUP reduces unexpected development costs and prevents wastage of resources.
Phases of RUP
1. Inception –
• Communication and planning are the main ones.

• Identifies the scope of the project using a use-case model allowing managers to estimate

costs and time required.

• Customers’ requirements are identified and then it becomes easy to make a plan for the

project.
• The project plan, Project goal, risks, use-case model, and Project description, are made.

• The project is checked against the milestone criteria and if it couldn’t pass these criteria

then the project can be either canceled or redesigned.

Phases of RUP
2. Elaboration –
• Planning and modeling are the main ones.

• A detailed evaluation and development plan is carried out and diminishes the risks.

• Revise or redefine the use-case model (approx. 80%), business case, and risks.

• Again, checked against milestone criteria and if it couldn’t pass these criteria then again

project can be canceled or redesigned.

• Executable architecture baseline.

3. Construction –
• The project is developed and completed.

• System or source code is created and then testing is done.

• Coding takes place.

Phases of RUP
4. Transition –
• The final project is released to the public.

• Transit the project from development into production.

• Update project documentation.

• Beta testing is conducted.

• Defects are removed from the project based on feedback from the public.

5. Production –
• The final phase of the model.

• The project is maintained and updated accordingly.

Agile Development
What is Agile?
• Agile development is a phrase used in software development to describe
methodologies for incremental software development.

Agile software development is a conceptual framework for software

engineering that promotes development iterations throughout the life-cycle of
the project.

• Software developed during one unit of time is referred to as an iteration,

which may last from one to four weeks.

• Agile methods also emphasize working software as the primary measure of

progress
Agile Manifesto
Four Important Manifestos of Agile development :---
1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Principles Of Agile
1. Customer Satisfaction
2. Working Software
3. Measure Of Progress
4. Late Changes Are Welcome
5. Face_To_Face Communication
6. Motivated Individuals
7. Technical Excellence
8. Simplicity
9. Self_organizing
10. Regular Adoption
Characteristics Of Agile
1. Modularity
2. Iterative
3. Time-bound
4. Incremental
5. People oriented
6. Less defect
7. Collaborative
8. Motivating the team
 Advantages Of Agile Model
1. Customer Satisfaction.
2. People and interactions
3. Customers, developers and testers constantly interact with each other.
4. Working software is delivered frequently.
5. Face-to-face conversation.
6. Close, daily cooperation between business people and developers.
7. Continuous attention to technical good design.
8. Regular adaptation to changing circumstances.
9. Even late changes in requirements are welcomed
 Disadvantages Of Agile Model
1. In case of some software deliverables, especially the large ones, it is difficult to assess
the effort required at the beginning of the software development life cycle.
2. There is lack of emphasis on necessary designing and documentation.
3. The project can easily get taken off track if customer representative is not clear what
outcome that they want.
4. Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined
with experienced resources.
 Unit-2
Requirement Analysis, Stakeholders, Elicitation Techniques,
Requirement Modelling
1. Requirement Analysis, Stakeholders, Elicitation Techniques,

Requirement Modelling.
I. Use Cases, Activity Diagrams
II. Swimlane Diagrams, Data Modelling.

III. Data Flow Diagram.

IV. Class Based Modelling.

V. Requirement Tracking.
 Requirement Engineering
1. The process to gather the software requirements from client, analyze and document them
is known as requirement engineering.
2. The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –
1. Feasibility Study
2.Requirement Gathering
3. Software Requirement Specification
4. Software Requirement Validation
 Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not nipped in
the bud. Requirements can be checked against following conditions –
• If they can be practically implemented

• If they are valid and as per functionality and domain of software

• If there are any ambiguities

• If they are complete

• If they can be demonstrated

 Requirement Elicitation Process
Requirement elicitation process can be depicted using the folloiwng diagram:

• Requirements gathering - The developers discuss with the client and end users and know

their expectations from the software.

• Organizing Requirements - The developers prioritize and arrange the requirements in

order of importance, urgency and convenience.

 Requirement Elicitation Process
Requirement elicitation process can be depicted using the following diagram:
• Negotiation & discussion - If requirements are ambiguous or there are some conflicts in

requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
• The requirements come from various stakeholders. To remove the ambiguity and

conflicts, they are discussed for clarity and correctness. Unrealistic requirements are
compromised reasonably.
• Documentation - All formal & informal, functional and non-functional requirements are

documented and made available for next phase processing.

 Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake
in the software system development.
There are various ways to discover requirements.
▪ Interviews

Interviews are strong medium to collect requirements. Organization may conduct several
types of interviews such as:
1.Structured (closed) interviews, where every single information to gather is decided in
advance, they follow pattern and matter of discussion firmly.
2.Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
 Requirement Elicitation Techniques

3. Oral interviews
4. Written interviews
5. One-to-one interviews which are held between two persons across the table.
6. Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.

▪ Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
 Requirement Elicitation Techniques

▪ Questionnaires

A document with pre-defined set of objective questions and respective options is handed
over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
▪ Task analysis

Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied
and requirements of proposed system are collected.
 Requirement Elicitation Techniques
▪ Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.
▪ Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
▪ Observation

Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and
how execution problems are dealt. The team itself draws some conclusions which aid to
form requirements expected from the software.
 Requirement Elicitation Techniques
▪ Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret
the features of intended software product. It helps giving better idea of requirements. If there
is no software installed at client’s end for developer’s reference and the client is not aware of
its own requirements, the developer creates a prototype based on initially mentioned
requirements. The prototype is shown to the client and the feedback is noted. The client
feedback serves as an input for requirement gathering.
 Requirement Modelling
Introduction
Requirements modeling involves creating a graphical representation of a system’s
requirements. It provides a visual and structured approach to documenting requirements,
which helps to ensure that all stakeholders have a clear understanding of the system’s
functionalities and constraints. Effective requirements modelling can help to identify
potential issues early in the development process, which can save time and resources in the
long run.
 (UML)Unified Modelling Language
Introduction
UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems.

UML was created by the Object Management Group (OMG) and UML 1.0 specification
draft was proposed to the OMG in January 1997.

OMG is continuously making efforts to create a truly industry standard.

 (UML)Unified Modelling Language
Introduction
• UML stands for Unified Modeling Language.

• UML is different from the other common programming languages such as C++, Java,

COBOL, etc.
• UML is a pictorial language used to make software blueprints.

• UML can be described as a general purpose visual modeling language to visualize,

specify, construct, and document software system.

• Although UML is generally used to model software systems, it is not limited within this

boundary. It is also used to model non-software systems as well. For example, the process
flow in a manufacturing unit, etc.
 (UML)Unified Modelling Language
Goals of UML
• A picture is worth a thousand words, this idiom absolutely fits describing UML. It’s a

pictorial language used to make software blueprints.

• There are a number of goals for developing UML but the most important is to define

some general purpose modeling language, which all modelers can use and it also needs to
be made simple to understand and use.
• UML diagrams are not only made for developers but also for business users, common

people, and anybody interested to understand the system.

• In conclusion, the goal of UML can be defined as a simple modeling mechanism to model

all possible practical systems in today’s complex environment.

 (UML)Unified Modelling Language
A Conceptual Model of UML
• A conceptual model can be defined as a model which is made of concepts and their

relationships.
• A conceptual model is the first step before drawing a UML diagram. It helps to

understand the entities in the real world and how they interact with each other.
As UML describes the real-time systems, it is very important to make a conceptual model
and then proceed gradually. The conceptual model of UML can be mastered by learning the
following three major elements −
• UML building blocks

• Rules to connect the building blocks

• Common mechanisms of UML

 (UML)Unified Modelling Language
UML building blocks. The building blocks of UML can be defined as −
• Things

• Relationships

• Diagrams

Things are the most important building blocks of UML. Things can be −
• Structural

• Behavioral

• Grouping

• Annotational
 (UML)Unified Modelling Language
• Structural Things

Structural things define the static part of the model. They represent the physical and
conceptual elements.
Following are the brief descriptions of the structural things.
• Class − Class represents a set of objects having similar responsibilities.

• Interface − Interface defines a set of operations, which specify the responsibility of a

class.
• Collaboration −Collaboration defines an interaction between elements.
 (UML)Unified Modelling Language
• Use case −Use case represents a set of actions performed by a system for a specific goal.

• Component −Component describes the physical part of a system.

• Node − A node can be defined as a physical element that exists at run time.
 (UML)Unified Modelling Language
• Behavioral Things

• A behavioral thing consists of the dynamic parts of UML models. Following are the

behavioral things −
• Interaction − Interaction is defined as a behavior that consists of a group of messages

exchanged among elements to accomplish a specific task.

• State machine − State machine is useful when the state of an object in its life cycle is

important. It defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change
 (UML)Unified Modelling Language
• Grouping Things

• Grouping things can be defined as a mechanism to group elements of a UML model

together. There is only one grouping thing available −

• Package − Package is the only one grouping thing available for gathering structural and

behavioral things.

• Annotational Things

• Annotational things can be defined as a mechanism to capture remarks, descriptions, and

comments of UML model elements. Note - It is the only one Annotational thing available.
A note is used to render comments, constraints, etc. of an UML element.
 (UML)Unified Modelling Language
• Relationship

Relationship is another most important building block of UML. It shows how the elements
are associated with each other and this association describes the functionality of an
application.
There are four kinds of relationships available.
• Dependency

Dependency is a relationship between two things in which change in one element also
affects the other.
• Association

Association is basically a set of links that connects the elements of a UML model. It also
describes how many objects are taking part in that relationship.
 (UML)Unified Modelling Language
• Generalization

Generalization can be defined as a relationship which connects a specialized element with a

generalized element. It basically describes the inheritance relationship in the world of
objects.
• Realization

Realization can be defined as a relationship in which two elements are connected. One
element describes some responsibility, which is not implemented and the other one
implements them. This relationship exists in case of interfaces.
 UML Diagrams
• UML diagrams are the ultimate output of the entire discussion. All the elements,

relationships are used to make a complete UML diagram and the diagram represents a
system.

• The visual effect of the UML diagram is the most important part of the entire process. All

the other elements are used to make it complete.

• UML includes the following nine diagrams

 UML Diagrams
• Use case diagram

• Class diagram

• Object diagram

• Sequence diagram

• Collaboration diagram

• Activity diagram

• State chart diagram

• Deployment diagram

• Component diagram
 UML Diagrams
Use Case Diagram in UML
• A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that

represents the interaction between actors (users or external systems) and a system under
consideration to accomplish specific goals. It provides a high-level view of the system’s
functionality by illustrating the various ways users can interact with it.
Use Case Diagram Notations
 UML Diagrams
Use Case Diagram Notations
• UML notations provide a visual language that enables software developers, designers, and

other stakeholders to communicate and document system designs, architectures, and

behaviors in a consistent and understandable manner.
Actors
• Actors are external entities that interact with the system. These can include users, other

systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use
cases and receive the outcomes. Proper identification and understanding of actors are
crucial for accurately modeling system behavior.
 UML Diagrams
Use Cases
• Use cases are like scenes in the play. They represent specific things your system can do.

In the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Use cases are represented by ovals.
 UML Diagrams
Use Cases
• Use cases are like scenes in the play. They represent specific things your system can do.

In the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Use cases are represented by ovals.
System Boundary UML Diagrams
• The system boundary is a visual representation of the scope or limits of the system you are

modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that
are external to it. The system boundary is typically represented by a rectangular box that
surrounds all the use cases of the system.
Purpose of System Boundary:
• Scope Definition: It clearly outlines the boundaries of the system, indicating which

components are internal to the system and which are external actors or entities interacting
with the system.
• Focus on Relevance: The diagram can focus on illustrating the essential functionalities

provided by the system without unnecessary details about external entities.

Use Case Diagram Relationships UML Diagrams
• n a Use Case Diagram, relationships play a crucial role in depicting the interactions between

actors and use cases. These relationships provide a comprehensive view of the system’s
functionality and its various scenarios.
Association Relationship
• The Association Relationship represents a communication or interaction between an actor

and a use case. It is depicted by a line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality described by the use case.
Example: Online Banking System
1. Actor: Customer 2. Use Case: Transfer Funds
3. Association: A line connecting the “Customer” actor to the “Transfer Funds” use case,
indicating the customer’s involvement in the funds transfer process.
 UML Diagrams
Example: Online Banking System
1. Actor: Customer 2. Use Case: Transfer Funds
3. Association: A line connecting the “Customer” actor to the “Transfer Funds” use case,
indicating the customer’s involvement in the funds transfer process.
Include Relationship
UML Diagrams
• The Include Relationship indicates that a use case includes the functionality of another use

case. It is denoted by a dashed arrow pointing from the including use case to the included use
case. This relationship promotes modular and reusable design.
Example: Social Media Posting
Use Cases: Compose Post, Add Image
Include Relationship: The “Compose Post” use case includes the functionality of “Add
Image.” Therefore, composing a post includes the action of adding an image.
Extend Relationship
UML Diagrams
• The Extend Relationship illustrates that a use case can be extended by another use case under

specific conditions. It is represented by a dashed arrow with the keyword “extend.” This
relationship is useful for handling optional or exceptional behavior.
• Example: Social Media Posting
Example: Flight Booking System
UML Diagrams

Use Cases: Book Flight, Select Seat

Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case when
the user wants to choose a specific seat, but it is an optional step.
Generalization Relationship
UML Diagrams
• The Generalization Relationship establishes an “is-a” connection between two use cases,

indicating that one use case is a specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
• Use Cases: Rent Car, Rent Bike

• Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions of

the general use case “Rent Vehicle.”

 UML Diagrams
Class Diagram
• In object-oriented programming (OOP), a class is a blueprint or template for creating

objects. Objects are instances of classes, and each class defines a set of attributes (data
members) and methods (functions or procedures) that the objects created from that class
will possess. The attributes represent the characteristics or properties of the object,
while the methods define the behaviors or actions that the object can perform.
• UML Class Notation
UML Diagrams
• class notation is a graphical representation used to depict classes and their relationships in

object-oriented modeling.
 UML Diagrams
• UML Class Notation

1. Class Name: The name of the class is typically written in the top compartment of the
class box and is centered and bold.
2. Attributes: Attributes, also known as properties or fields, represent the data members of
the class. They are listed in the second compartment of the class box and often include the
visibility (e.g., public, private) and the data type of each attribute.
3. Methods, also known as functions or operations, represent the behavior or functionality
of the class. They are listed in the third compartment of the class box and include the
visibility (e.g., public, private), return type, and parameters of each method.
 UML Diagrams
4. Visibility Notation: Visibility notations indicate the access level of attributes and
methods. Common visibility notations include:
• + for public (visible to all classes)

• - for private (visible only within the class)

• # for protected (visible to subclasses)

• ~ for package or default visibility (visible to classes in the same package)

5. Parameter Directionality: In class diagrams, parameter directionality refers to the

indication of the flow of information between classes through method parameters. It helps to
specify whether a parameter is an input, an output, or both. This information is crucial for
understanding how data is passed between objects during method calls.
 UML Diagrams
There are three main parameter directionality notations used in class diagrams:
• In (Input):

An input parameter is a parameter passed from the calling object (client) to the called object
(server) during a method invocation.
It is represented by an arrow pointing towards the receiving class (the class that owns the
method).
• Out (Output):

An output parameter is a parameter passed from the called object (server) back to the calling
object (client) after the method execution.
It is represented by an arrow pointing away from the receiving class.
 UML Diagrams
• InOut (Input and Output): An InOut parameter serves as both input and output. It

carries information from the calling object to the called object and vice versa.
• It is represented by an arrow pointing towards and away from the receiving class.Out

(Output):
 UML Diagrams
• Relationships between classes: In class diagrams, relationships between classes describe

how classes are connected or interact with each other within a system. There are several
types of relationships in object-oriented modeling, each serving a specific purpose. Here
are some common types of relationships in class diagrams:
 UML Diagrams
1. Association: An association represents a bi-directional relationship between two
classes. It indicates that instances of one class are connected to instances of another
class. Associations are typically depicted as a solid line connecting the classes, with
optional arrows indicating the direction of the relationship.
The “Library” class can be considered the source class because it contains a reference to
multiple instances of the “Book” class. The “Book” class would be considered the target
class because it belongs to a specific library.
 UML Diagrams
2. Directed Association: A directed association in a UML class diagram represents a
relationship between two classes where the association has a direction, indicating that one
class is associated with another in a specific way.
• In a directed association, an arrowhead is added to the association line to indicate the

direction of the relationship. The arrow points from the class that initiates the association
to the class that is being targeted or affected by the association.
• Directed associations are used when the association has a specific flow or directionality,

such as indicating which class is responsible for initiating the association or which class
has a dependency on another.
 UML Diagrams
• Consider a scenario where a “Teacher” class is associated with a “Course” class in a

university system. The directed association arrow may point from the “Teacher” class to
the “Course” class, indicating that a teacher is associated with or teaches a specific
course.
• The source class is the “Teacher” class. The “Teacher” class initiates the association by

teaching a specific course.

• The target class is the “Course” class. The “Course” class is affected by the association as

it is being taught by a specific teacher.

 UML Diagrams
• Consider a scenario where a “Teacher” class is associated with a “Course” class in a

university system. The directed association arrow may point from the “Teacher” class to
the “Course” class, indicating that a teacher is associated with or teaches a specific
course.
 UML Diagrams
3. Aggregation
• Aggregation is a specialized form of association that represents a “whole-part”

relationship. It denotes a stronger relationship where one class (the whole) contains or is
composed of another class (the part). Aggregation is represented by a diamond shape on
the side of the whole class. In this kind of relationship, the child class can exist
independently of its parent class.
• Let’s understand aggregation using an example:

• The company can be considered as the whole, while the employees are the parts.

Employees belong to the company, and the company can have multiple employees.
However, if the company ceases to exist, the employees can still exist independently.
UML Diagrams
 UML Diagrams
4. Composition
• Composition is a stronger form of aggregation, indicating a more significant ownership

or dependency relationship. In composition, the part class cannot exist independently of

the whole class. Composition is represented by a filled diamond shape on the side of the
whole class.
Let’s understand Composition using an example:
• Imagine a digital contact book application. The contact book is the whole, and each

contact entry is a part. Each contact entry is fully owned and managed by the contact
book. If the contact book is deleted or destroyed, all associated contact entries are also
removed.
 UML Diagrams
This illustrates composition because the existence of the contact entries depends entirely on
the presence of the contact book. Without the contact book, the individual contact entries
lose their meaning and cannot exist on their own.
 UML Diagrams
5. Generalization(Inheritance)
Inheritance represents an “is-a” relationship between classes, where one class (the subclass
or child) inherits the properties and behaviors of another class (the superclass or parent).
Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the
subclass to the superclass.

In the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.
 UML Diagrams
The Bank Account class serves as the generalized representation of all types of bank
accounts, while the subclasses (Current Account, Savings Account, Credit Account)
represent specialized versions that inherit and extend the functionality of the base class.
 UML Diagrams
6. Realization (Interface Implementation)
Realization indicates that a class implements the features of an interface. It is often used in
cases where a class realizes the operations defined by an interface. Realization is depicted
by a dashed line with an open arrowhead pointing from the implementing class to the
interface.
Let’s consider the scenario where a “Person” and a “Corporation” both realizing an
“Owner” interface.
• Owner Interface: This interface now includes methods such as “acquire(property)” and

“dispose(property)” to represent actions related to acquiring and disposing of property.

 UML Diagrams
• Person Class (Realization): The Person class implements the Owner interface,

providing concrete implementations for the “acquire(property)” and “dispose(property)”

methods. For instance, a person can acquire ownership of a house or dispose of a car.
• Corporation Class (Realization): Similarly, the Corporation class also implements the

Owner interface, offering specific implementations for the “acquire(property)” and

“dispose(property)” methods. For example, a corporation can acquire ownership of real
estate properties or dispose of company vehicles.
 UML Diagrams
• Both the Person and Corporation classes realize the Owner interface, meaning they

provide concrete implementations for the “acquire(property)” and “dispose(property)”

methods defined in the interface.
 UML Diagrams
7. Dependency Relationship
• A dependency exists between two classes when one class relies on another, but the

relationship is not as strong as association or inheritance. It represents a more loosely

coupled connection between classes. Dependencies are often depicted as a dashed arrow.
Let’s consider a scenario where a Person depends on a Book.
• Person Class: Represents an individual who reads a book. The Person class depends on

the Book class to access and read the content.

• Book Class: Represents a book that contains content to be read by a person. The Book

class is independent and can exist without the Person class.

 UML Diagrams
The Person class depends on the Book class because it requires access to a book to read its
content. However, the Book class does not depend on the Person class; it can exist
independently and does not rely on the Person class for its functionality.
 UML Diagrams
State Machine Diagram
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions.
• State Machine diagrams are also referred to as State Machines Diagrams and State-Chart

Diagrams.
• These terms are often used interchangeably. So simply, a state machine diagram is used to

model the dynamic behavior of a class in response to time and changing external entities.
• We can say that each and every class has a state but we don’t model every class using

State Machine diagrams.

• We prefer to model the states with three or more states.
 UML Diagrams
State Machine Diagram
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions.
UML Diagrams
State Machine Diagram
 UML Diagrams
Activity Diagram
Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We can depict both sequential processing and
concurrent processing of activities using an activity diagram ie an activity diagram focuses on
the condition of flow and the sequence in which it happens.

We describe what causes a particular event using an activity diagram.

An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed.
They are used in business and process modeling where their primary use is to depict the
dynamic aspects of a system.
 UML Diagrams
Activity Diagram
• Activity Diagram Notations
 UML Diagrams
Activity Diagram
• Activity Diagram Notations
 UML Diagrams
Sequence Diagram
• The sequence diagram represents the flow of messages in the system and is also termed as

an event diagram. It helps in envisioning several dynamic scenarios.

• It portrays the communication between any two lifelines as a time-ordered sequence of

events, such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a vertical dotted
line that extends across the bottom of the page.
• It incorporates the iterations as well as branching.
 UML Diagrams
Purpose of a Sequence Diagram
• To model high-level interaction among active objects within a system.

• To model interaction among objects inside a collaboration realizing a use case.

• It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

• Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is positioned

at the top of the diagram
 Unit-3
Software Design
1. Principles of Software Design

2. Design Concepts

I. Problem Partitioning, Abstraction, Architecture

II. Modularity, Relationships, Top Down & Bottom up Approach

III. Design Model

IV. Component Design

V. User Interface Design

VI. Configuration Management

 Software Design

Design means to draw or plan something to show the look, functions and working of
it.

Software Design is also a process to plan or convert the software requirements into
a step that are needed to be carried out to develop a software system. There are
several principles that are used to organize and arrange the structural components of
Software design. Software Designs in which these principles are applied affect the
content and the working process of the software from the beginning.
 1. Principles of Software Design
These principles are :
Not Suffer from
“Tunnel Vision” 1 6 Should Accommodate
Change

Traceable to the
Analysis Model 2 7 Should Degrade
Gently

Should not “Reinvent

the Wheel” 3 8 Assessed for
Quality

Minimize the
“Intellectual Distance” 4 9 Review to
Minimize Errors

Exihibit Uniformity
and Integration 5 10 Design is not Coding, &
Coding is not Design
 1. Principles of Software Design

1. Should not suffer from “Tunnel Vision” –

While designing the process, it should not suffer from “tunnel vision” which means
that is should not only focus on completing or achieving the aim but on other effects
also.

2. Traceable to analysis model –

The design process should be traceable to the analysis model which means it should
satisfy all the requirements that software requires to develop a high-quality product.
 1. Principles of Software Design

3. Should not “Reinvent The Wheel” –

The design process should not reinvent the wheel that means it should not waste
time or effort in creating things that already exist. Due to this, the overall
development will get increased.

4. Minimize Intellectual distance –

The design process should reduce the gap between real-world problems and
software solutions for that problem meaning it should simply minimize intellectual
distance.
 1. Principles of Software Design

5. Exhibit uniformity and integration –

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

6. Accommodate change –
The software should be designed in such a way that it accommodates the change
implying that the software should adjust to the change that is required to be done as
per the user’s need.
 1. Principles of Software Design

7. Degrade gently –
The software should be designed in such a way that it degrades gracefully which
means it should work properly even if an error occurs during the execution.

8. Assessed for quality –

The design should be assessed or evaluated for the quality meaning that during the
evaluation, the quality of the design needs to be checked and focused on.
 1. Principles of Software Design

9. Review to discover errors –

The design should be reviewed which means that the overall evaluation should be
done to check if there is any error present or if it can be minimized.

10. Design is not coding and coding is not design –

Design means describing the logic of the program to solve any problem and coding
is a type of language that is used for the implementation of a design.
 2. Design Concepts

1. Problem Partitioning :
For small problem, we can handle the entire problem at once but for the significant problem,
divide the problems and conquer the problem it means to divide the problem into smaller
pieces so that each piece can be captured separately.
For software design, the goal is to divide the problem into manageable pieces.
Benefits of Problem Partitioning
I. Software is easy to understand II. Software becomes simple
III. Software is easy to test IV. Software is easy to modify
V. Software is easy to maintain VI. Software is easy to expand
 2. Design Concepts

1. Problem Partitioning :

These pieces cannot be entirely independent of each other as they together form the system.
They have to cooperate and communicate to solve the problem. This communication adds
complexity.
***Note : As the number of partition increases = Cost of partition and complexity
increases
 2. Design Concepts
2. Abstraction : An abstraction is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the implementation. Abstraction
can be used for existing element as well as the component being designed.
Here, there are two common abstraction mechanisms

• Functional Abstraction : A module is specified by the method it performs.

The details of the algorithm to accomplish the functions are not visible to the user of the
function. Functional abstraction forms the basis for Function oriented design approaches.

• Data Abstraction : Details of the data elements are not visible to the users of data. Data

Abstraction forms the basis for Object Oriented design approaches.

 2. Design Concepts
3. Architecture : The software needs the architectural design to represents the design of
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.
Each style will describe a system category that 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.
 2. Design Concepts
• 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.
 2. Design Concepts
• The figure illustrates a typical data centered style. The client software access a central

repository. Variation of this approach are used to transform the repository into a blackboard
when data related to client or data of interest for the client change the notifications to client
software.
 2. Design Concepts
• 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 blackboard mechanism.

Advantage 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

 2. Design Concepts
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.

 2. Design Concepts
• 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.

 2. Design Concepts

Advantages of Data Flow architecture

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

Disadvantages of Data Flow architecture

• It frequently degenerates to batch sequential system

• Data flow architecture does not allow applications that require greater user engagement.
 2. Design Concepts
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.

 2. Design Concepts
• 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.
 2. Design Concepts
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.

 2. Design Concepts
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. CLIENT

APPLICATION

PLATFORM

INFRASTRUCTURE

SERVER

The Layered Architecture

 2. Design Concepts
• 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 Organization for Standardization) communication system.
 2. Design Concepts
4. Modularity : Modularity specifies to the division of software into separate modules which
are differently named and addressed and are integrated later on in to obtain the completely
functional software. It is the only property that allows a program to be intellectually
manageable. Single large programs are difficult to understand and read due to a large number
of reference variables, control paths, global variables, etc.
The desirable properties of a modular system are:
• Each module is a well-defined system that can be used with other applications.

• Each module has single specified objectives.

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

• Modules should be easier to use than to build.

• Modules are simpler from outside than inside.

 2. Design Concepts
Advantages of Modularity
• It allows large programs to be written by several or different people

• It encourages the creation of commonly used routines to be placed in the library and used by

other programs.
• It simplifies the overlay procedure of loading a large program into main storage.

• It provides more checkpoints to measure progress.

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

• It produced the well designed and more readable program.

 2. Design Concepts
Disadvantages of Modularity
• Execution time maybe, but not certainly, longer

• Storage size perhaps, but is not certainly, increased

• Compilation and loading time may be longer

• Inter-module communication problems may be increased

• More linkage required, run-time may be longer, more source lines must be written, and

more documentation has to be done

 2. Design Concepts
Modular Design
Modular design reduces the design complexity and results in easier and faster implementation
by allowing parallel development of various parts of a system. We discuss a different section
of modular design in detail in this section:
1. Functional Independence: Functional independence is achieved by developing functions
that perform only one kind of task and do not excessively interact with other modules.
Independence is important because it makes implementation more accessible and faster. The
independent modules are easier to maintain, test, and reduce error propagation and can be
reused in other programs as well. Thus, functional independence is a good design feature
which ensures software quality.
 2. Design Concepts
It is measured using two criteria:
Cohesion: It measures the relative function strength of a module.
Coupling: It measures the relative interdependence among modules.
2. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules
should be specified that data include within a module is inaccessible to other modules that do
not need for such information.
The use of information hiding as design criteria for modular system provides the most
significant benefits when modifications are required during testing's and later during software
maintenance. This is because as most data and procedures are hidden from other parts of the
software,
 2. Design Concepts
Strategy of Design
A good system design strategy is to organize the program modules in such a method that are
easy to develop and latter too, change. Structured design methods help developers to deal with
the size and complexity of programs. Analysts generate instructions for the developers about
how code should be composed and how pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

• Top-down Approach

• Bottom-up Approach
 2. Design Concepts
Strategy of Design
1. Top-down Approach: This approach starts with the identification of the main components
and then decomposing them into their more detailed sub-components.
 2. Design Concepts
Strategy of Design
2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing
system.
 2. Design Concepts
Strategy of Design
2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing
system.
 2. Design Concepts
Coupling and Cohesion
In software engineering, the coupling is the degree of interdependence between software
modules. Two modules that are tightly coupled are strongly dependent on each other.
However, two modules that are loosely coupled are not dependent on each other. Uncoupled
modules have no interdependence at all within them.
 2. Design Concepts
Coupling and Cohesion
A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls between
modules increase or the amount of shared data is large. Thus, it can be said that a design with
high coupling will have more errors.
2. Design Concepts
 2. Design Concepts
1. No Direct Coupling: There is no direct coupling between M1 and M2.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.
 2. Design Concepts
3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite
data items such as structure, objects, etc. When the module passes non-global data structure or
entire structure to another module, they are said to be stamp coupled. For example, passing
structure variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is
used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed
data format, communication protocols, or device interface. This is related to communication to
external tools and devices.
 2. Design Concepts
6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a
branch from one module into another module.
 2. Design Concepts
Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a module
belong together. Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module. For example, in highly cohesive systems, functionality is
strongly related.

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

"low cohesion."
 2. Design Concepts
Types of Modules Cohesion
 2. Design Concepts
Module Cohesion
1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a

module, cooperate to achieve a single function.

2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a

module form the components of the sequence, where the output from one component of the
sequence is input to the next.

3. Communicational Cohesion: A module is said to have communicational cohesion, if all

tasks of the module refer to or update the same data structure, e.g., the set of functions
defined on an array or a stack.
 2. Design Concepts
Module Cohesion
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the
module are all parts of a procedure in which particular sequence of steps has to be carried out for
achieving a goal, e.g., the algorithm for decoding a message.

5. Temporal Cohesion: When a module includes functions that are associated by the fact that all
the methods must be executed in the same time, the module is said to exhibit temporal cohesion.

6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module
perform a similar operation. For example Error handling, data input and data output, etc.
 2. Design Concepts
Module Cohesion
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set
of tasks that are associated with each other very loosely, if at all.
 2. Design Concepts
Differentiate between Coupling and Cohesion
Coupling Cohesion

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

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

Coupling shows the relative independence between Cohesion shows the module's
the modules. relative functional strength.

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

In coupling, modules are linked to the other modules. In cohesion, the module focuses on a single thing.
 2. Design Concepts
Function Oriented Design
Function Oriented design is a method to software design where the model is decomposed into a
set of interacting units or modules where each unit or module has a clearly defined function.
Thus, the system is designed from a functional viewpoint.

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

• System is designed from a functional• System is viewed as a collection of objects

viewpoint. (i.e., entities).
• Top down decomposition. • Bottom up approach.

• Divide and conquer approach. • UML is used.

• DFD is used.
2. Design Concepts
 2. Design Concepts
Data Flow Diagram
Data-flow design is concerned with designing a series of functional transformations that convert
system inputs into the required outputs. The design is described as data-flow diagrams. These
diagrams show how data flows through a system and how the output is derived from the input
through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They
show end-to-end processing. That is the flow of processing from when data enters the system to
where it leaves the system can be traced.
 2. Design Concepts
Data Flow Diagram

• A graphical tool, useful for communicating with users, managers and other personnel.

• Useful for analyzing existing as well as proposed systems.

• Focus on the movement of data between external entities and processes and between

processes and data stores.

• A relatively simple technique to learn and use.

 2. Design Concepts
Why DFD?
Provides an overview of
• What data a system processes.

• What transformations are performed.

• What data are stored.

• What results are produced.

• Its graphical nature makes it a good communication tool between –

• User and The analyst

• Analyst and System designer.

 2. Design Concepts
DFD Elements
• Source/ Sinks (External entities).

External entities means they either supply or receive data.

Source means entity that supplies data to the system.
Sink means entity that receives data from the system.
• Data flows.

Marks movement of data through the system - a pipeline to carry the data.
Connects the processes, external entities and data stores.
Generally unidirectional, if same data flows in both direction, double headed arrow can be used.
• Processes.

• Data stores.
 2. Design Concepts
DFD Elements
• Processes.

A circle represents a process.

Straight line with incoming arrows are input data flows.
Straight line with outgoing arrows are output data flows.
Labels are assigned to data flows.
• Data stores.

A Data store is a repository of data.

Data can be written into the data store. This is depicted by an incoming arrow.
Data can be read from a data store. This is depicted by an outgoing arrow.
External entity cannot read or write to the data store.
 2. Design Concepts
Rules of Data flow
• Data can flow from -

External entity to process and vice versa.

Process to store and back.
Process to process.
• Data cannot flow from -

External entity to external entity.

External entity to store.
Store to external entity.
Store to store.
 2. Design Concepts
Data Flow Diagram
Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.
 2. Design Concepts
The notation which is used is based on the following symbols:
2. Design Concepts
 2. Design Concepts
Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The data items
listed contain all data flows and the contents of all data stores looking on the DFDs in the DFD
model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

 2. Design Concepts
Data Dictionaries
For the smallest units of data elements, the data dictionary lists their name and their type.
A data dictionary plays a significant role in any software development process because of the
following reasons:
• A Data dictionary provides a standard language for all relevant information for use by

engineers working in a project. A consistent vocabulary for data items is essential since, in
large projects, different engineers of the project tend to use different terms to refer to the same
data, which unnecessarily causes confusion.
• The data dictionary provides the analyst with a means to determine the definition of various

data structures in terms of their component elements.

 2. Design Concepts
Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to the
user without the knowledge of internal design.
 2. Design Concepts

Structured Chart is a graphical representation which shows:

• System partitions into modules

• Hierarchy of component modules

• The relation between processing modules

• Interaction between modules

• Information passed between modules

 2. Design Concepts
The following notations are used in structured chart:
 2. Design Concepts

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

Introduction to Design Modeling

• Design modeling in software engineering represents the features of the software that helps

engineer to develop it effectively, the architecture, the user interface, and the component level
detail.
• Design modeling provides a variety of different views of the system like architecture plan for

home or building.
• Different methods like data-driven, pattern-driven, or object-oriented methods are used for

constructing the design model. All these methods use set of design principles for designing a
model.
 2. Design Concepts

Working of Design Modeling

• Designing a model is an important phase and is a multi-process that represent the data

structure, program structure, interface characteristic, and procedural details. It is mainly

classified into four categories –
• Data design

• Architectural design

• Interface design, and

• Component-level design.
 2. Design Concepts

Data design:
• It represents the data objects and their interrelationship in an entity-relationship diagram.

• Entity-relationship consists of information required for each entity or data objects as well as it

shows the relationship between these objects.

• It shows the structure of the data in terms of the tables.

• It shows three type of relationship – One to one, one to many, and many to many. In one to

one relation, one entity is connected to another entity. In one many relation, one Entity is
connected to more than one entity. un many to many relations one entity is connected to more
than one entity as well as other entity also connected with first entity using more than one
entity.
 2. Design Concepts

Architectural design:
• It defines the relationship between major structural elements of the software.

• It is about decomposing the system into interacting components.

• It defines the structure and properties of the component that are involved in the system and

also the inter-relationship among these components.

• Allocation of functional responsibilities to components.

• Component Interfaces

• Component scaling and performance properties, resource consumption properties, reliability

properties, and so forth.

• Communication and interaction between components.
 2. Design Concepts

User Interfaces design:

Interface design is the specification of the interaction between a system and its environment. this
phase proceeds at a high level of abstraction with respect to the inner workings of the system i.e,
during interface design, the internal of the systems are completely ignored and the system is
treated as a black box. Attention is focused on the dialogue between the target system and the
users, devices, and other systems with which it interacts. The design problem statement produced
during the problem analysis step should identify the people, other systems, and devices which are
collectively called agents. Interface design should include the following details:
 2. Design Concepts

User Interfaces design:

• It represents how the Software communicates with the user i.e. the behavior of the system.

• It refers to the product where user interact with controls or displays of the product.

• Precise description of events in the environment, or messages from agents to which the system

must respond.
• Precise description of the events or messages that the system must produce.

• Specification of the data, and the formats of the data coming into and going out of the system.

• Specification of the ordering and timing relationships between incoming events or messages,

and outgoing events or outputs.

 2. Design Concepts

Component level design:

• It transforms the structural elements of the software architecture into a procedural description

of software components. It is a perfect way to share a large amount of data. Components need
not be concerned with how data is managed at a centralized level i.e. components need not
worry about issues like backup and security of the data.
 2. Design Concepts
Principles of Design Model
• Design must be traceable to the analysis model:

Analysis model represents the information, functions, and behavior of the system. Design model
translates all these things into architecture – a set of subsystems that implement major functions
and a set of component kevel design that are the realization of Analysis classes. This implies that
design model must be traceable to the analysis model.
• Always consider architecture of the system to be built:

Software architecture is the skeleton of the system to be built. It affects interfaces, data
structures, behavior, program control flow, the manner in which testing is conducted,
maintainability of the resultant system, and much more.
 2. Design Concepts
Principles of Design Model
• Focus on the design of the data:

Data design encompasses the manner in which the data objects are realized within the design. It
helps to simplify the program flow, makes the design and implementation of the software
components easier, and makes overall processing more efficient.
• User interfaces should consider the user first:

The user interface is the main thing of any software. No matter how good its internal functions
are or how well designed its architecture is but if the user interface is poor and end-users don’t
feel ease to handle the software then it leads to the opinion that the software is bad.
 2. Design Concepts
Principles of Design Model
• Components should be loosely coupled:

Coupling of different components into one is done in many ways like via a component interface,
by messaging, or through global data. As the level of coupling increases, error propagation also
increases, and overall maintainability of the software decreases. Therefore, component coupling
should be kept as low as possible.
• Interfaces both user and internal must be designed:

The data flow between components decides the processing efficiency, error flow, and design
simplicity. A well-designed interface makes integration easier and tester can validate the
component functions more easily.
 2. Design Concepts
Principles of Design Model
• Component level design should exhibit Functional independence:

It means that functions delivered by component should be cohesive i.e. it should focus on one
and only one function or sub-function.
 2. Design Concepts

Software Configuration Management

Introduction to Software Configuration Management:
Software Configuration Management (SCM) is a branch of Software Engineering to provide a
better process to handling, organizing and controlling the changes in requirements, codes, teams
and other elements in the software project development life cycle. The SCM primarily deals with
version selection, tracking the changes and version control of software projects with high
productivity and minimize the error or risk factor.
 2. Design Concepts

Why do we need Software Configuration Management?

It has the following pros to choose as a software configuration management tool in software
project development. Such as,
• Tracking and managing the changes in the software development process.

• It provides to enhance the Productivity of the software application with minimal error.

• It provides a smooth workflow inside the development process.

• Easy to communicate with team members to develop a better quality of the product.

• To track every member of the team with project workflow status.

• It updates each team member’s code parallelly by considering different version control.

• To manage the different tools and development processes in a software product.

 2. Design Concepts

Why do we need Software Configuration Management?

• It is used to managing the software and hardware inside the application.

• It is used to controlling and managing defects, teamwork and process.

• It handles the software budgeting as per the change in the application.

 2. Design Concepts

How does Software Configuration Management work?

A software configuration process is a tool used in the software development life cycle process to
track, changing and managing the configuration items (requirements, codes, documents, defects,
resources, budgeting, software, hardware, etc) inside the product development. The project
manager, developers, configuration manager, the product owner and testers are involved in the
SCM process.
 2. Design Concepts
It has multiple processes to complete software configuration management. Such as:
• Planning and Identification Process:

This is the initial level of the SCM process to planning properly for the development of the
application and identifies the configuration items as per the scope of the project. To conduct
kick-off meetings or start meeting and welcome to change requests are the basic criteria for this
process. The project management plan is the input for this process and approval of the plan is the
exit criteria.
• Version Control Process or Baselines:

The version control or baselines indicates to store the different versions of

development/configuration by changing the scope or requirements or code or software
environment. This process provides several versions of that software product.
 2. Design Concepts
• Change Control Process:

In this process the new change request created by the client to change some configurations on the
software product i.e. to add or remove or edit on the configuration items as the request is
received by the team. As per approval of the change request the application will develop and the
request will be closed on status.
• Configuration Release Process:

This process is used to ensure the application will develop as per the project plan and test/verify
the application as per scope. The software-related documents and software release notes are the
inputs to provide a working version of the software application.
 2. Design Concepts
• Configuration Auditing Process:

In this process to verify the developed software product as per the baselines or not. Here we go
for function requirement audit and physical audit of the software application.
• Review and Status Reporting Process:

It is a technical review on the application workflow, process, configuration items, and change
requests, etc to generate the status report in every phase of the software development life cycle
process. In this process we go for multiple reviews of the application to develop some
application-related documents like user manual, Installation process guide, Do’s and Don’t Do’s,
Release notes, etc.
 2. Design Concepts
Advantages
• To increase the productive efficiency of software as it controls and tracking the workflow or

development process.
• It welcomes change management so the risk of the product will be less.

• It is used for proper monitoring and auditing of the software development product.

• It will help to enhance the software development life cycle process.

• This process provides a reliable, organized, cost-effective and low-risk software development

application.
• It provides a high-quality software product.
 2. Design Concepts
Disadvantages
• It needs adequate resources with full knowledge about the software configuration

management tools.
• It requires more resources to work with the configuration management process for small

industries.
• It requires a highly configured desktop/laptop for the development stages.
 Unit-4
Software Quality
1. Software Quality

• Approaches for Quality Assurance

2. Software Testing

• Verification and Validation

• Types of Testing

3. Risk Assessment

• Risk Mitigation

• Monitoring and Management

 Unit-4
Software Quality
1. Software Quality

Software quality product is defined in term of its fitness of purpose. That is, a
quality product does precisely what the users want it to do. For software
products, the fitness of use is generally explained in terms of satisfaction of the
requirements laid down in the SRS document. Although "fitness of purpose" is
a satisfactory interpretation of quality for many devices such as a car, a table
fan, a grinding machine, etc. for software products, "fitness of purpose" is not a
wholly satisfactory definition of quality.
 Unit-4
Software Quality
Example: Consider a functionally correct software product. That is, it performs all tasks as
specified in the SRS document. But, has an almost unusable user interface. Even though it may
be functionally right, we cannot consider it to be a quality product.

The modern view of a quality associated with a software product several quality methods such
as the following:
• Portability: A software device is said to be portable, if it can be freely made to work in

various operating system environments, in multiple machines, with other software products,
etc.
 Unit-4
Software Quality
• Usability: A software product has better usability if various categories of users can easily

invoke the functions of the product.

• Reusability: A software product has excellent reusability if different modules of the product

can quickly be reused to develop new products.

• Correctness: A software product is correct if various requirements as specified in the SRS

document have been correctly implemented.

 Unit-4
Software Quality
• Maintainability: A software product is maintainable if bugs can be easily corrected as and

when they show up, new tasks can be easily added to the product, and the functionalities of
the product can be easily modified, etc.
 Unit-4
Software Quality
Software Quality Management System
A quality management system is the principal methods/approaches used by organizations to
provide that the products they develop have the desired quality.
A quality system subsists of the following:
• Managerial Structure and Individual Responsibilities: A quality system is the

responsibility of the organization as a whole. However, every organization has a sever quality
department to perform various quality system activities. The quality system of an
arrangement should have the support of the top management. Without help for the quality
system at a high level in a company, some members of staff will take the quality system
seriously.
 Unit-4
Software Quality
Software Quality Management System
Quality System Activities: The quality system activities encompass the following:
• Auditing of projects

• Review of the quality system

• Development of standards, methods, and guidelines, etc.

• Production of documents for the top management summarizing the effectiveness of the

quality system in the organization.

 Unit-4
Software Quality
Evolution of Quality Management System
Quality Systems are basically evolved over the past some years. The evolution of a Quality
Management System is a four-step process.
 Unit-4
Software Quality
• The main task of quality control is to detect defective devices and it also helps in finding the

cause that leads to the defect. It also helps in the correction of bugs.

• Quality Assurance helps an organization in making good quality products. It also helps in

improving the quality of the product by passing the products through security checks.

• Total Quality Management(TQM) checks and assures that all the procedures must be

continuously improved regularly through process measurements.

 ISO 9000 Certification
ISO (International Standards Organization) is a group or consortium of 63 countries established
to plan and fosters standardization. ISO declared its 9000 series of standards in 1987. It serves as
a reference for the contract between independent parties. The ISO 9000 standard determines the
guidelines for maintaining a quality system. The ISO standard mainly addresses operational and
organizational methods such as responsibilities, reporting, etc. ISO 9000 defines a set of
guidelines for the production process and is not directly concerned about the product itself.

Types of ISO 9000

Quality Standards
 ISO 9000 Certification
The ISO 9000 series of standards is based on the assumption that if a proper stage is followed
for production, then good quality products are bound to follow automatically. The types of
industries to which the various ISO standards apply are as follows.
• ISO 9001: This standard applies to the organizations engaged in design, development,

production, and servicing of goods. This is the standard that applies to most software
development organizations.
• ISO 9002: This standard applies to those organizations which do not design products but are

only involved in the production. Examples of these category industries contain steel and car
manufacturing industries that buy the product and plants designs from external sources and
are engaged in only manufacturing those products. Therefore, ISO 9002 does not apply to
software development organizations.
 ISO 9000 Certification
• ISO 9003: This standard applies to organizations that are involved only in the installation and

testing of the products. For example, Gas companies.

 ISO 9000 Certification
How to get ISO 9000 Certification?
An organization determines to obtain ISO 9000 certification applies to ISO registrar office for
registration. The process consists of the following stages:
 ISO 9000 Certification
1. Application: Once an organization decided to go for ISO certification, it applies to the

registrar for registration.

2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the

organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews the

document submitted by the organization and suggest an improvement.

4. Compliance Audit: During this stage, the registrar checks whether the organization has

compiled the suggestion made by it during the review or not.

5. Registration: The Registrar awards the ISO certification after the successful completion of

all the phases.

6. Continued Inspection: The registrar continued to monitor the organization time by time.
 Software Testing
• Software testing can be stated as the process of verifying and validating whether a software or

application is bug-free, meets the technical requirements as guided by its design and
development, and meets the user requirements effectively and efficiently by handling all the
exceptional and boundary cases.
• The process of software testing aims not only at finding faults in the existing software but

also at finding measures to improve the software in terms of efficiency, accuracy, and
usability.
• Software Testing is a method to assess the functionality of the software program.

• The process checks whether the actual software matches the expected requirements and

ensures the software is bug-free.

 Software Testing
• The purpose of software testing is to identify the errors, faults, or missing requirements in

contrast to actual requirements. It mainly aims at measuring the specification, functionality,

and performance of a software program or application.
 Software Testing
Software testing can be divided into two steps:
The terms "verification" and "validation" are commonly used in software engineering, but the
terms refer to two different types of analysis.

What is Verification?
Verification is a process that determines the quality of the software. Verification includes all the
activities associated with producing high quality software, i.e.: testing, inspection, design
analysis, specification analysis, and so on. Verification is a relatively objective process, in that if
the various processes and documents are expressed precisely enough, no subjective judgement
should be needed in order to verify software.
 Software Testing
Advantages of Verification:

• Verification helps in lowering the number of the defects that may be encountered in the later

stages of development.
• Verifying the product at the starting phase of the development will help in understanding the

product in a more comprehensive way.

• Verification reduces the chances of failures in the software application or product.

• Verification helps in building the product as per the customer specifications and needs.
 Software Testing
What is Validation?
Validation is a process in which the requirements of the customer are actually met by the
software functionality. Validation is done at the end of the development process and takes place
after verifications are completed.
Advantages
• During verification if some defects are missed, then during the validation process they can be

caught as failures.
• If during verification some specification is misunderstood and development has already

occurred then during the validation process the difference between the actual result and
expected result can be identified and corrective action taken.
 Software Testing
• Validation is done during testing like feature testing, integration testing, system testing, load

testing, compatibility testing, stress testing, etc.

• Validation helps in building the right product as per the customer’s requirement which in turn

will satisfy their business process needs.

 Software Testing
How Do Verification and Validation Differ?
The distinction between the two terms is largely due to the role of specifications. Validation is
the process of checking whether the specification captures the customer’s requirements, while
verification is the process of checking that the software meets specifications.
• Verification includes all the activities associated with the producing high quality software. It

is a relatively objective process in that no subjective judgement should be needed in order to

verify software.
• In contrast, validation is an extremely subjective process. It involves making subjective

assessments of how well the (proposed) system addresses a real-world need. Validation
includes activities such as requirements modelling, prototyping and user evaluation.
 Software Testing
Importance of Software Testing:
• Defects can be identified early

• Increased customer satisfaction

• Helps with scalability

• Saves time and money

 Software Testing
Different Types Of Software Testing
Software Testing can be broadly classified into 3 types:
Functional Testing: Functional testing is a type of software testing that validates the software
systems against the functional requirements. It is performed to check whether the application is
working as per the software’s functional requirements or not. Various types of functional testing
are Unit testing, Integration testing, System testing, Smoke testing, and so on.
Non-functional Testing: Non-functional testing is a type of software testing that checks the
application for non-functional requirements like performance, scalability, portability, stress, etc.
Various types of non-functional testing are Performance testing, Stress testing, Usability
Testing, and so on.
 Software Testing
Maintenance Testing: Maintenance testing is the process of changing, modifying, and updating
the software to keep up with the customer’s needs. It involves regression testing that verifies that
recent changes to the code have not adversely affected other previously working parts of the
software.
 Software Testing
Software testing techniques can be majorly classified into two categories:

Black Box Testing: Black box technique of testing in which the tester doesn’t have access to the
source code of the software and is conducted at the software interface without any concern with
the internal logical structure of the software known as black-box testing.

White-Box Testing: White box technique of testing in which the tester is aware of the internal
workings of the product, has access to its source code, and is conducted by making sure that all
internal operations are performed according to the specifications is known as white box testing.
 Software Testing

S No. Black Box Testing White Box Testing

Internal workings of an Knowledge of the internal

1
application are not required. workings is a must.

Also known as closed box/data- Also known as clear

2
driven testing. box/structural testing.

End users, testers, and Normally done by testers and

3
developers. developers.

This can only be done by a trial Data domains and internal

4
and error method. boundaries can be better tested.
 Software Testing
Different Levels of Software Testing
Software level testing can be majorly classified into 4 levels:
• Unit Testing: Unit testing is a level of the software testing process where individual

units/components of a software/system are tested. The purpose is to validate that each unit of
the software performs as designed.
• Integration Testing: Integration testing is a level of the software testing process where

individual units are combined and tested as a group. The purpose of this level of testing is to
expose faults in the interaction between integrated units.
• System Testing: System testing is a level of the software testing process where a complete,

integrated system/software is tested. The purpose of this test is to evaluate the system’s
compliance with the specified requirements.
 Software Testing
Different Levels of Software Testing
• Acceptance Testing: Acceptance testing is a level of the software testing process where a

system is tested for acceptability. The purpose of this test is to evaluate the system’s
compliance with the business requirements and assess whether it is acceptable for delivery.
 Software Testing
Best Practices for Software Testing
• Continuous testing: Project teams test each build as it becomes available thus it enables

software to be validated in real environments earlier in the development cycle, reducing risks
and improving the functionality and design.
• Involve users: It is very important for the developers to involve users in the process and

open-ended questions about the functionality required in the application. This will help to
develop and test the software from the customer’s perspective.
• Divide tests into smaller parts: Dividing tests into smaller fractions save time and other

resources in environments where frequent testing needs to be conducted. This also helps
teams to make better analyses of the tests and the test results.
 Software Testing
Best Practices for Software Testing
• Metrics and Reporting: Reporting enables the team members to share goals and test results.

Advanced tools integrate the project metrics and present an integrated report in the dashboard
that can be easily reviewed by the team members to see the overall health of the project.
• Don’t skip regression testing: Regression testing is one of the most important steps as it

encourages the validation of the application. Thus, it should not be skipped.

• Programmers should avoid writing tests: Test cases are usually written before the start of

the coding phase so it is considered a best practice for programmers to avoid writing test
cases as they can be biased towards their code and the application.
 Software Testing
Best Practices for Software Testing
• Service virtualization: Service virtualization simulates the systems and services that are not

yet developed or are missing. Thus, enabling teams to reduce dependency and start the testing
process sooner. They can modify, and reuse the configuration to test different scenarios
without having to alter the original environment.
 Software Testing
Benefits of Software Testing
• Product quality: Testing ensures the delivery of a high-quality product as the errors are

discovered and fixed early in the development cycle.

• Customer satisfaction: Software testing aims to detect the errors or vulnerabilities in the

software early in the development phase so that the detected bugs can be fixed before the
delivery of the product. Usability testing is a type of software testing that checks the
application for how easily usable it is for the users to use the application.
• Cost-effective: Testing any project on time helps to save money and time for the long term. If

the bugs are caught in the early phases of software testing, it costs less to fix those errors.
• Security: Security testing is a type of software testing that is focused on testing the

application for security vulnerabilities from internal or external sources.

 Unit-5
Software Metrics, Estimations & Scheduling
1. Software Metrics, Process Metrics, Product Metrics, Function

Oriented Metrics
2. Software Project Estimations

3. Function Point Based Metrics

4. COCOMO Models

5. Project Scheduling & Effort Distribution

 Software Metrics
• A software metric is a measure of software characteristics which are measurable or

countable. Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many other
uses.

• Within the software development process, many metrics are that are all connected.

Software metrics are similar to the four functions of management: Planning,

Organization, Control, or Improvement.
 Software Metrics
Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product.

The two important software characteristics are:

• Size and complexity of software.

• Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

 Software Metrics
Classification of Software Metrics

2. Process Metrics: These are the measures of various characteristics of the software
development process. For example, the efficiency of fault detection. They are used to measure
the characteristics of methods, techniques, and tools that are used for developing software.
 Software Metrics
Types of Metrics
• Internal metrics: Internal metrics are the metrics used for measuring properties that are

viewed to be of greater importance to a software developer. For example, Lines of Code

(LOC) measure.

• External metrics: External metrics are the metrics used for measuring properties that are

viewed to be of greater importance to the user, e.g., portability, reliability, functionality,

usability, etc.

• Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource

metrics. For example, cost per FP where FP stands for Function Point Metric.
 Software Metrics
Types of Metrics
• Project metrics: Project metrics are the metrics used by the project manager to check the

project's progress. Data from the past projects are used to collect various metrics, like time
and cost; these estimates are used as a base of new software. Note that as the project
proceeds, the project manager will check its progress from time-to-time and will compare the
effort, cost, and time with the original effort, cost and time. Also understand that these
metrics are used to decrease the development costs, time efforts and risks. The project quality
can also be improved. As quality improves, the number of errors and time, as well as cost
required, is also reduced.
 Software Metrics
Advantage of Software Metrics
• Comparative study of various design methodology of software systems.

• For analysis, comparison, and critical study of different programming language concerning

their characteristics.
• In comparing and evaluating the capabilities and productivity of people involved in software

development.
• In the preparation of software quality specifications.

• In the verification of compliance of software systems requirements and specifications.

• In making inference about the effort to be put in the design and development of the software

systems.
• In getting an idea about the complexity of the code.
 Software Metrics
Advantage of Software Metrics
• In taking decisions regarding further division of a complex module is to be done or not.

• In guiding resource manager for their proper utilization.

• In comparison and making design tradeoffs between software development and maintenance

cost.
• In providing feedback to software managers about the progress and quality during various

phases of the software development life cycle.

• In the allocation of testing resources for testing the code.
 Software Metrics
Disadvantage of Software Metrics
• The application of software metrics is not always easy, and in some cases, it is difficult and

costly.
• The verification and justification of software metrics are based on historical/empirical data

whose validity is difficult to verify.

• These are useful for managing software products but not for evaluating the performance of

the technical staff.

• The definition and derivation of Software metrics are usually based on assuming which are

not standardized and may depend upon tools available and working environment.
• Most of the predictive models rely on estimates of certain variables which are often not

known precisely.
 Software Metrics
Size Oriented Metrics
LOC Metrics
It is one of the earliest and simpler metrics for calculating the size of the computer program. It is
generally used in calculating and comparing the productivity of programmers. These metrics are
derived by normalizing the quality and productivity measures by considering the size of the
product as a metric.
Following are the points regarding LOC measures:
1. In size-oriented metrics, LOC is considered to be the normalization value.

2. It is an older method that was developed when FORTRAN and COBOL programming were

very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
 Software Metrics
Size Oriented Metrics
LOC Metrics
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-based)
programming. As already explained, Graphical User Interfaces (GUIs) use forms basically. LOC
metric is not applicable here.
 Software Metrics
Size Oriented Metrics
LOC Metrics
9. It requires that all organizations must use the same method for counting LOC. This is so
because some organizations use only executable statements, some useful comments, and some
do not. Thus, the standard needs to be established.
10. These metrics are not universally accepted.
 Software Metrics
Size Oriented Metrics
LOC Metrics
Based on the LOC/KLOC count of software, many other metrics can be computed:

• Errors/KLOC.

• $/ KLOC.

• Defects/KLOC.

• Pages of documentation/KLOC.

• Errors/PM.

• Productivity = KLOC/PM (effort is measured in person-months).

• $/ Page of documentation.
 Software Metrics
Size Oriented Metrics
LOC Metrics
Advantages of LOC
• Simple to measure

Disadvantage of LOC
• It is defined on the code. For example, it cannot measure the size of the specification.

• It characterizes only one specific view of size, namely length, it takes no account of

functionality or complexity
• Bad software design may cause an excessive line of code

• It is language dependent

• Users cannot easily understand it

 Software Metrics
Halstead's Software
According to Halstead's "A computer program is an implementation of an algorithm considered
to be a collection of tokens which can be classified as either operators or operand."
1. Token Count : In these metrics, a computer program is considered to be a collection of

tokens, which may be classified as either operators or operands. All software science metrics
can be defined in terms of these basic symbols. These symbols are called as a token.
The basic measures are
• n1 = count of unique operators.

• n2 = count of unique operands.

• N1 = count of total occurrences of operators.

• N2 = count of total occurrence of operands.

 Software Metrics
Halstead's Software
Halstead metrics are:
• Program Volume (V): The unit of measurement of volume is the standard unit for size "bits."

It is the actual size of a program if a uniform binary encoding for the vocabulary is used.
• Program Level (L): The value of L ranges between zero and one, with L=1 representing a

program written at the highest possible level (i.e., with minimum size).
• Program Difficulty: The difficulty level or error-proneness (D) of the program is

proportional to the number of the unique operator in the program.

• Programming Effort (E): The unit of measurement of E is elementary mental

discriminations.
 Software Metrics
Halstead's Software
Halstead metrics are:
• Estimated Program Length: According to Halstead, The first Hypothesis of software

science is that the length of a well-structured program is a function only of the number of
unique operators and operands.
• Potential Minimum Volume: The potential minimum volume V* is defined as the volume of

the most short program in which a problem can be coded.

• Size of Vocabulary (n): The size of the vocabulary of a program, which consists of the

number of unique tokens used to build a program, is defined as: n=n1+n2

• Language Level : Shows the algorithm implementation program language level. The same

algorithm demands additional effort if it is written in a low-level program language.