School of Computing Science and Engineering

Course Code:BTCS3503 Course Name: Software Testing & Quality Assurance

MCSE2320

Unit 1: Overview of Software

Engineering

Introduction to Software: Software Crisis, Software Processes & Characteristics, Software life cycle models,
Waterfall, Prototype, Evolutionary and Spiral Model, Requirement engineering, Use case approach, requirements
analysis using DFD, Data dictionaries & ER Diagrams, Software Design: Cohesion & Coupling

Program Name: B.Tech Dr Shajahan

 Topics to be covered

• Introduction to Software: 

• Software Crisis, Software Processes & Characteristics,

• Software life cycle models, Waterfall, Prototype, Evolutionary and Spiral Model,

• Requirement engineering,

• Use case approach,

• requirements analysis using DFD,

• Data dictionaries & ER Diagrams,

• Software Design: Cohesion & Coupling

 Introduction to Software Engineering

• Software is more than just a program code.

• A program is an executable code, which serves some computational purpose.

Software is considered to be collection of executable programming code,
associated libraries and documentations.

• Software, when made for a specific requirement is called software product.

• Engineering on the other hand, is all about developing products, using well-
defined, scientific principles and methods.
 Introduction to Software Engineering

• Software engineering is the branch of

computer science that deals with the
design, development, testing, and
maintenance of software applications.
Software engineers apply engineering
principles and knowledge of
programming languages to build
software solutions for end users.
 Introduction to Software Engineering

Why is Software Engineering required?

• Software Engineering is required due to the following reasons:

• To manage Large software

• For more Scalability

• Cost Management

• To manage the dynamic nature of software

• For better quality Management

 Introduction to Software Engineering

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of progress in user requirements and the environment
on which the program is working.
• Huge Programming: It is simpler to manufacture a wall than to a house or building, similarly, as the measure of
programming become extensive engineering has to step to give it a scientific process.
• Adaptability: If the software procedure were not based on scientific and engineering ideas, it would be simpler to re-create
new software than to scale an existing one.
• Cost: As the hardware industry has demonstrated its skills and huge manufacturing has let down the cost of computer and
electronic hardware. But the cost of programming remains high if the proper process is not adapted.
• Dynamic Nature: The continually growing and adapting nature of programming hugely depends upon the environment in
which the client works. If the quality of the software is continually changing, new upgrades need to be done in the existing
one.
• Quality Management: Better procedure of software development provides a better and quality software product.
 Introduction to Software Engineering

Importance of Software Engineering

 Introduction to Software Engineering

Software Processes
The term software specifies to the set of computer programs, procedures and associated documents
(Flowcharts, manuals, etc.) that describe the program and how they are to be used.

A software process is the set of activities and associated outcome that produce a software product. Software
engineers mostly carry out these activities. These are four key process activities, which are common to all
software processes. These activities are:

• Software specifications: The functionality of the software and constraints on its operation must be defined.

• Software development: The software to meet the requirement must be produced.

• Software validation: The software must be validated to ensure that it does what the customer wants.

• Software evolution: The software must evolve to meet changing client needs.
 Introduction to Software Engineering

The Software Process Model

A software process model is a specified definition of a software process, which is presented from a particular perspective.
Models, by their nature, are a simplification, so a software process model is an abstraction of the actual process, which is
being described. Process models may contain activities, which are part of the software process, software product, and the
roles of people involved in software engineering. Some examples of the types of software process models that may be
produced are:

1.A workflow model: This shows the series of activities in the process along with their inputs, outputs and dependencies. The
activities in this model perform human actions.

2. A dataflow or activity model: This represents the process as a set of activities, each of which carries out some data
transformations. It shows how the input to the process, such as a specification is converted to an output such as a design.
The activities here may be at a lower level than activities in a workflow model. They may perform transformations carried out
by people or by computers.

3. A role/action model: This means the roles of the people involved in the software process and the activities for which they
are responsible.
 Introduction to Software Engineering

The Software Process Model

There are several various general models or paradigms of software development:

• The waterfall approach: This takes the above activities and produces them as separate process phases such as
requirements specification, software design, implementation, testing, and so on. After each stage is defined, it is "signed
off" and development goes onto the following stage.

• Evolutionary development: This method interleaves the activities of specification, development, and validation. An initial
system is rapidly developed from a very abstract specification.

• Formal transformation: This method is based on producing a formal mathematical system specification and transforming
this specification, using mathematical methods to a program. These transformations are 'correctness preserving.' This
means that you can be sure that the developed programs meet its specification.

• System assembly from reusable components: This method assumes the parts of the system already exist. The system
development process target on integrating these parts rather than developing them from scratch.
 Introduction to Software Engineering

Software Crisis

• Size: Software is becoming more expensive and more complex with the growing complexity and expectation
out of software. For example, the code in the consumer product is doubling every couple of years.

• Quality: Many software products have poor quality, i.e., the software products defects after putting into use
due to ineffective testing technique. For example, Software testing typically finds 25 errors per 1000 lines of
code.

• Cost: Software development is costly i.e. in terms of time taken to develop and the money involved. For
example, Development of the FAA's Advanced Automation System cost over $700 per lines of code.

• Delayed Delivery: Serious schedule overruns are common. Very often the software takes longer than the
estimated time to develop, which in turn leads to cost shooting up. For example, one in four large-scale
development projects is never completed.
 Introduction to Software Engineering

Program vs. Software

• Software is more than programs. Any

program is a subset of software, and
it becomes software only if
documentation & operating
procedures manuals are prepared.
 What is SDLC?

• SDLC is a systematic process for building software that ensures the quality
and correctness of the software built.

• SDLC process aims to produce high-quality software that meets customer

expectations. The system development should be complete in the pre-defined
time frame and cost.

• SDLC consists of a detailed plan which explains how to plan, build, and
maintain specific software.

• Every phase of the SDLC life Cycle has its own process and deliverables that
feed into the next phase.
 WHY SDLC?

Why SDLC?

Here, are prime reasons why SDLC is important for developing a software system.

• It offers a basis for project planning, scheduling, and estimating

• Provides a framework for a standard set of activities and deliverables

• It is a mechanism for project tracking and control

• Increases visibility of project planning to all involved stakeholders of the development process

• Increased and enhance development speed

• Improved client relations

• Helps you to decrease project risk and project management plan overhead
SDLC Phases

• Phase 1: Requirement collection and analysis

• Phase 2: Feasibility study

• Phase 3: Design

• Phase 4: Coding

• Phase 5: Testing

• Phase 6: Installation/Deployment

• Phase 7: Maintenance
SDLC Phase 1: Requirement collection and analysis

• The requirement is the first stage in the SDLC process. It is conducted by the
senior team members with inputs from all the stakeholders and domain
experts in the industry. Planning for the quality assurance requirements and
recognization of the risks involved is also done at this stage.

• This stage gives a clearer picture of the scope of the entire project and the
anticipated issues, opportunities, and directives which triggered the project.
SDLC Phase 2: Feasibility study

• Once the requirement analysis phase is completed the next sdlc step is to define and document software
needs. This process conducted with the help of ‘Software Requirement Specification’ document also
known as ‘SRS’ document. It includes everything which should be designed and developed during the
project life cycle.

• There are mainly five types of feasibilities checks:

• Economic: Can we complete the project within the budget or not?

• Legal: Can we handle this project as cyber law and other regulatory framework/compliances.

• Operation feasibility: Can we create operations which is expected by the client?

• Technical: Need to check whether the current computer system can support the software

• Schedule: Decide that the project can be completed within the given schedule or not.
SDLC Phase 2: Feasibility study

• Once the requirement analysis phase is completed the next sdlc step is to define and document
software needs. This process conducted with the help of ‘Software Requirement Specification’ document
also known as ‘SRS’ document. It includes everything which should be designed and developed during
the project life cycle.

• There are mainly five types of feasibilities checks:

• Economic: Can we complete the project within the budget or not?

• Legal: Can we handle this project as cyber law and other regulatory framework/compliances.

• Operation feasibility: Can we create operations which is expected by the client?

• Technical: Need to check whether the current computer system can support the software

• Schedule: Decide that the project can be completed within the given schedule or not.
SDLC Phase 3: Design

In this third phase, the system and software design documents are prepared as per the requirement
specification document. This helps define overall system architecture

This design phase serves as input for the next phase of the model.

There are two kinds of design documents developed in this phase:

High-Level Design (HLD) Low-Level Design (LLD)

• Brief description and name of each module • Functional logic of the modules

• An outline about the functionality of every module • Database tables, which include type and size

• Interface relationship and dependencies between modules • Complete detail of the interface

• Database tables identified along with their key elements • Addresses all types of dependency issues

• Complete architecture diagrams along with technology • Listing of error messages

details • Complete input and outputs for every module
SDLC Phase 4: Coding

• Once the system design phase is over, the next phase is coding. In this phase, developers
start build the entire system by writing code using the chosen programming language.

• In the coding phase, tasks are divided into units or modules and assigned to the various
developers.

• It is the longest phase of the Software Development Life Cycle process.

SDLC Phase 5: Testing

• Once the software is complete, and it is deployed in the testing

environment.

• The testing team starts testing the functionality of the entire system.

• This is done to verify that the entire application works according to

the customer requirement.
SDLC Phase 6: Installation/Deployment

Once the software testing phase is over and no bugs or errors left in
the system then the final deployment process starts.

Based on the feedback given by the project manager, the final

software is released and checked for deployment issues if any.
SDLC Phase 7: Maintenance

Once the system is deployed, and customers start using the developed system,
following 3 activities occur

• Bug fixing – bugs are reported because of some scenarios which are not tested
at all

• Upgrade – Upgrading the application to the newer versions of the Software

• Enhancement – Adding some new features into the existing software

 Popular SDLC Models

Here, are some of the most important

models of Software Development Life
Cycle (SDLC):

• Waterfall model in SDLC

• Incremental Model in SDLC

• V-Model in SDLC

• Agile Model in SDLC

• Spiral Model
 SDLC Models - Waterfall Model

Waterfall model is the simplest model

of software development paradigm.

It says the all the phases of SDLC will

function one after another in linear
manner.

That is, when the first phase is

finished then only the second phase
will start and so on.
 SDLC Models - Waterfall Model

When to use SDLC Waterfall Model?

• When the requirements are constant and not

changed regularly.

• A project is short

• The situation is calm

• Where the tools and technology used is consistent

and is not changing

• When resources are well prepared and are

available to use.
 SDLC Models - Prototype Model

The prototype model requires that before carrying

out the development of actual software, a working
prototype of the system should be built.

A prototype is a toy implementation of the system.

A prototype usually turns out to be a very crude

version of the actual system, possible exhibiting
limited functional capabilities, low reliability, and
inefficient performance as compared to actual
software.
 SDLC Models - Prototype Model

Steps of Prototype Model Advantage of Prototype Model

• Requirement Gathering and Analyst • Reduce the risk of incorrect user requirement

• Quick Decision • Good where requirement are changing/uncommitted

• Build a Prototype • Regular visible process aids management

• Assessment or User Evaluation • Support early product marketing

• Prototype Refinement • Reduce Maintenance cost.

• Engineer Product • Errors can be detected much earlier as the system is

made side by side.
 SDLC Models - Evolutionary Process Model

Evolutionary process model resembles the iterative enhancement model. The same phases are defined for the
waterfall model occurs here in a cyclical fashion. This model differs from the iterative enhancement model in
the sense that this does not require a useful product at the end of each cycle. In evolutionary development,
requirements are implemented by category rather than by priority.

For example, in a simple database application, one cycle might implement the graphical user Interface (GUI),
another file manipulation, another queries and another updates. All four cycles must complete before there is a
working product available. GUI allows the users to interact with the system, file manipulation allow the data to
be saved and retrieved, queries allow user to get out of the system, and updates allows users to put data into
the system.
 SDLC Models - Spiral Model

The spiral model, initially proposed by Boehm, 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.
 SDLC Models - 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

Advantages

• High amount of risk analysis

• Useful for large and mission-critical projects.

 UML - Unified Modeling Language.

• 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 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-Diagrams

• The UML diagrams are

categorized into structural
diagrams, behavioral
diagrams, and also
interaction overview
diagrams.

• The diagrams are

hierarchically classified in
the following figure:
 Use Case Diagram:

• Use Case Diagram: It represents the functionality of a system by utilizing actors

and use cases.

• It encapsulates the functional requirement of a system and its association with

actors.

• It portrays the use case view of a system.

• It models the tasks, services, and functions required by a system/subsystem of an

application.

• It depicts the high-level functionality of a system and also tells how the user
handles a system.
 Use Case Diagram: - Purpose

Following are the purposes of a use case diagram given below:

• It gathers the system's needs.

• It depicts the external view of the system.

• It recognizes the internal as well as external factors that influence the system.

• It represents the interaction between the actors.

 Use Case Diagram: - Purpose

How to Draw a Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. When the requirements
of a system are analyzed, the functionalities are captured in use cases.

We can say that use cases are nothing but the system functionalities written in an organized manner. The
second thing which is relevant to use cases are the actors. Actors can be defined as something that interacts
with the system.

Actors can be a human user, some internal applications, or may be some external applications. When we are
planning to draw a use case diagram, we should have the following items identified.

• Functionalities to be represented as use case

• Actors

• Relationships among the use cases and actors.

 Use Case Diagram: - Components

Use case diagram components

Actors: The users that interact with a system. An actor can be a person, an organization, or an outside
system that interacts with your application or system. They must be external objects that produce or
consume data.

System: A specific sequence of actions and interactions between actors and the system. A system may also
be referred to as a scenario.

Goals: The end result of most use cases. A successful diagram should describe the activities and variants
used to reach the goal.
 Use Case Diagram: - Purpose

Use Case Notation

• Use case is represented as an eclipse with a name inside it. It

may contain additional responsibilities.      

• Use case is used to capture high level functionalities of a

system.

Actor Notation

• An actor can be defined as some internal or external entity that

interacts with the system
 Use Case Diagram: - Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase online. The top-level uses
are as follows; View Items, Make Purchase, Checkout, Client Register. The View Items use case is utilized by the
customer who searches and view products. The Client Register use case allows the customer to register itself with
the website for availing gift vouchers, coupons, or getting a private sale invitation. It is to be noted that the
Checkout is an included use case, which is part of Making Purchase, and it is not available by itself.

The View Items is further extended by several use cases such as; Search Items, Browse Items, View
Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use cases provide some
functions to customers, which allows them to search for an item. The View Items is further extended by several
use cases such as; Search Items, Browse Items, View Recommended Items, Add to Shopping Cart, Add to Wish
list. All of these extended use cases provide some functions to customers, which allows them to search for an
item.
 Use Case Diagram: - Example of a Use Case Diagram

Use Case
Diagram: -
Example of a
Use Case
Diagram
 Use Case Diagram: - Example of a Use Case Diagram

Use Case
Diagram: -
Example of a
Use Case
Diagram
 Use Case Diagram: - Example of a Use Case Diagram

Top UML Diagram Tools That You Can Consider

ArgoUML : - ArgoUML is an UML diagramming application written in Java and released under the open source
Eclipse Public License. By virtue of being a Java application, it is available on any platform supported by Java
SE.

StarUML :- StarUML is a software engineering tool for system modeling using the Unified Modeling Language, as
well as Systems Modeling Language, and classical modeling notations. It is published by MKLabs and is
available on Windows, Linux and MacOS

Draw.io : Draw.io is a free open-source collaborative workspace for drawing UML diagrams. It also contains
predefined templates for drawing any UML diagram, creating wireframes, business charts, etc.

Rational Rose XDE, an "eXtended Development Environment" for software developers, integrates with Microsoft
Visual Studio .NET and Rational Application Developer. The Rational Software division of IBM, which previously
produced Rational Rose, wrote this software
 Data Flow Diagrams

• A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system. A
neat and clear DFD can depict the right amount of the system requirement graphically.

• It can be manual, automated, or a combination of both.

• It shows how data enters and leaves the system, what changes the information, and where data is stored.

• The objective of a DFD is to show the scope and boundaries of a system as a whole.

• It may be used as a communication tool between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system.

• The DFD is also called as a data flow graph or bubble chart.

 Data Flow Diagrams

Data Flow
Diagrams -
Symbols
 Data Flow Diagrams

Rules for creating DFD

• The name of the entity should be easy and understandable without any extra assistance(like comments).

• The processes should be numbered or put in ordered list to be referred easily.

• The DFD should maintain consistency across all the DFD levels.

• A single DFD can have maximum processes upto 9 and minimum 3 processes.

Levels of DFD
• DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be created. Levels of DFD are as follows:

• 0-level DFD

• 1-level DFD:

• 2-level DFD:.
 Data Flow Diagrams

0-level DFDM

It is also known as fundamental system model, or context diagram represents the

entire software requirement as a single bubble with input and output data denoted
by incoming and outgoing arrows.

Then the system is decomposed and described as a DFD with multiple bubbles..

1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes.

In this level, we highlight the main objectives of the system and breakdown the
high-level process of 0-level DFD into subprocesses.

2-Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to
project or record the specific/necessary detail about the system's functioning.
Data Flow Diagrams
 Data Dictionaries

• A data dictionary is a file or a set of files that includes a database's

metadata.

• The data dictionary hold records about other objects in the database, such
as data ownership, data relationships to other objects, and other data.

• The data dictionary is an essential component of any relational database.

Ironically, because of its importance, it is invisible to most database users.
Typically, only database administrators interact with the data dictionary.
 Data Dictionaries

The data dictionary, in general, includes information about the following:

• Name of the data item

• Aliases

• Description/purpose

• Related data items

• Range of values

• Data structure definition/Forms

Data Dictionaries
 Entity-Relationship Diagrams

• ER-modeling is a data modeling method used in software engineering to produce a conceptual

data model of an information system. Diagrams created using this ER-modeling method are called
Entity-Relationship Diagrams or ER diagrams or ERDs.

Purpose of ERD

• The database analyst gains a better understanding of the data to be contained in the database
through the step of constructing the ERD.

• The ERD serves as a documentation tool.

• Finally, the ERD is used to connect the logical structure of the database to users. In particular, the
ERD effectively communicates the logic of the database to users.
 Entity-Relationship Diagrams

1. Entity

• An entity can be a real-world object,

either animate or inanimate, that can be
merely identifiable. An entity is denoted
as a rectangle in an ER diagram.
 Entity-Relationship Diagrams

2. Attributes

• Entities are denoted utilizing their

properties, known as attributes. All
attributes have values. For example, a
student entity may have name, class,
and age as attributes.

• There exists a domain or range of

values that can be assigned to
attributes. For example, a student's
name cannot be a numeric value. It has
to be alphabetic. A student's age cannot
be negative, etc.
 Entity-Relationship Diagrams

There are four types of Attributes:

1. Key attribute

2. Composite attribute

3. Single-valued attribute

4. Multi-valued attribute
 Entity-Relationship Diagrams

3. Relationships

• The association among entities is known

as relationship.

• Relationships are represented by the

diamond-shaped box.

• For example, an employee works_at a

department, a student enrolls in a
course. Here, Works_at and Enrolls are
called relationships.
 Entity-Relationship Diagrams

Degree of a relationship set

The number of participating entities in a

relationship describes the degree of the
relationship. The three most common relationships
in E-R models are:

• Unary (degree1)

• Binary (degree2)

• Ternary (degree3)
 Entity-Relationship Diagrams

Cardinality

Cardinality describes the number of entities

in one entity set, which can be associated
with the number of entities of other sets via
relationship set.

Types of Cardinalities

1. One to One:

2. One to Many

3. Many to One:

4. Many to many
 Coupling and Cohesion

• "Coupling" describes the relationships between modules,

and "cohesion" describes the relationships within them.

• Cohesion: Cohesion is the indication of the relationship

within the module. It is the concept of intra-module.
Cohesion has many types but usually, high cohesion is
good for software.

• Coupling: Coupling is also the indication of the

relationships between modules. It is the concept of the
Inter-module. The coupling has also many types but
usually, the low coupling is good for software.
 Coupling and Cohesion

Cohesion Coupling

Cohesion is the concept of intra-module. Coupling is the concept of inter-module.

Cohesion represents the relationship within a Coupling represents the relationships between
module. modules.

Increasing cohesion is good for software. Increasing coupling is avoided for software.

Cohesion represents the functional strength of Coupling represents the independence among
modules. modules.

Whereas loosely coupling gives the best

Highly cohesive gives the best software.
software.

In cohesion, the module focuses on a single In coupling, modules are connected to the other
thing. modules.
Coupling and Cohesion
GALGOTIAS UNIVERSITY

THANK YOU