A Laboratory Manual for

SOFTWARE ENGINEERING
(3161605)

B.E. Semester 6 (Information Technology)

Directorate of Technical Education, Gandhinagar,

Gujarat.
 Government Engineering College, Bhavnagar

Certificate

This is to certify that Mr./Ms.

Enrollment No. of B.E. Semester Information
Technology of this Institute (GTU Code: ) has satisfactorily completed
the Practical / Tutorial work for the subject Software Engineering (3161605)
for the academic year 2023-24.

Place:

Date:

Name and Sign of Faculty member

Head of the Department

 Preface

The main motto of any laboratory/practical/field work is to enhance required skills and create ability
amongst students to solve real-time problems by developing relevant competencies in the
psychomotor domain. By keeping this in view, GTU has designed a competency-focused outcome-
based curriculum for engineering degree programs where sufficient weightage is given to practical
work. It shows the importance of enhancement of skills amongst the students, and it pays attention to
utilizing every second of time allotted for practicals amongst students, instructors, and faculty
members to achieve relevant outcomes by performing the experiments rather than merely study-type
experiments. It is a must for the effective implementation of a competency-focused outcome-based
curriculum that every practical is keenly designed to serve as a tool to develop and enhance relevant
competency required by the various industry among every student. These psychomotor skills are very
difficult to develop through traditional chalk-and-board content delivery methods in the classroom.
Accordingly, this lab manual is designed to focus on industry-defined relevant outcomes rather than
the old practice of conducting practicals to prove concepts and theories.

By using this lab manual, students can go through the relevant theory and procedure in advance before
the actual performance, which creates interest, and students can have a basic idea prior to the
performance. This, in turn, enhances pre-determined outcomes amongst students. Each experiment in
this manual begins with competency, industry-relevant skills, course outcomes as well as practical
outcomes (objectives). The students will also achieve safety and necessary precautions to be taken
while performing practical.

This manual also provides guidelines to faculty members to facilitate student-centric lab activities
through each experiment by arranging and managing necessary resources in order that the students
follow the procedures with required safety and necessary precautions to achieve the outcomes. It also
gives an idea of how students will be assessed by providing rubrics.

Software Engineering is an application of a systematic, defined, and measurable approach that begins
with requirement specification and progresses with planning, modeling, and testing, and concludes
with deployment. It is a layered paradigm that comprises processes, methods, and tools with the
bedrock of quality focus. The Software Engineering approach's main purpose is committed to
developing the software products within the stipulated time and budget with more quality. Quality
product motivates firmness, commodity, and delight.

Utmost care has been taken while preparing this lab manual; however ,there is always a chance of
improvement. Therefore, we welcome constructive suggestions for improvement and removal of
errors, if any.
Soft
Software Engineering (3161605)

Practical – Course Outcome matrix

Course Outcomes (COs):

CO-1: Prepare SRS (Software Requirement Specification) document and SPMP (Software Project
Management Plan) document.
CO-2: Apply the concept of Functional Oriented and Object-Oriented Approaches for Software
Design. CO-3. Recognize how to ensure the quality of software products, different quality standards,
and software review techniques.
CO-4. Apply various testing techniques and test plans in.
CO-5. Able to understand modern Agile Development
Sr.
Objective(s) of Experiment CO1 CO2 CO3 CO4 CO5
No.
Study of various type of Software Process models with
comparison and find out which process model will be
1. √
appropriate for your selected Project.

Discuss the Project Management: Project Planning and

2. √ √
Project Scheduling about your Project.
Prepare the Software Requirement Specification (SRS)
3. √ √
document for selected project.
4. Draw the Data Flow Diagram for your selected Project. √ √

Draw the Entity-Relationship Diagram for your selected

5. √ √
Project
Draw Usecase Diagram for your selected Project.
6. √ √
Solve the problem by applying basic COCOMO model.
7. √ √

8. Modeling UML Class Diagrams and Sequence diagrams √ √

Design the various test cases to perform the testing of the
9. √ √
system and also perform the various type of testing.
Study of any two Open source tools in DevOps for
Infrastructure Automation, Configuration Management
10. √
Deployment Automation, Performance Management, Log
Management Monitoring.
Soft
Software Engineering (3161605)

Industry Relevant Skills

The following industry relevant competency is expected to be developed in the student by

undertaking the practical work of this laboratory.

1. Apply knowledge of Process Models for the development of software.

2. Understand the concept of Software requirement Specification (SRS) document for project
development.

Guidelines for Faculty members

1. Teacher should provide the guideline with demonstration of practical to the students with
all features.
2. Teacher shall explain basic concepts/theory related to the experiment to the students before
starting of each practical
3. Involve all the students in performance of each experiment.
4. Teacher is expected to share the skills and competencies to be developed in the students
and ensure that the respective skills and competencies are developed in the students after
the completion of the experimentation.
5. Teachers should give opportunity to students for hands-on experience after the
demonstration.
6. Teacher may provide additional knowledge and skills to the students even though not
covered in the manual but are expected from the students by concerned industry.
7. Give practical assignment and assess the performance of students based on task assigned to
check whether it is as per the instructions or not.
8. Teacher is expected to refer complete curriculum of the course and follow the guidelines
for implementation.

Instructions for Students

1. Students are expected to carefully listen to all the theory classes delivered by the faculty
members and understand the COs, content of the course, teaching and examination scheme, skill
set to be developed etc.
2. Students shall organize the work in the group and make record of all observations.
3. Students shall develop maintenance skill as expected by industries.
4. Student shall attempt to develop related hand-on skills and build confidence.
5. Student shall develop the habits of evolving more ideas, innovations, skills etc. apart from those
Soft
Software Engineering (3161605)

included in scope of manual.

6. Student shall refer technical magazines and data books.
7. Student should develop a habit of submitting the experimentation work as per the schedule and
she/he should be well prepared for the same.

General Guidelines for Software Engineering Laboratory Work

1. Student has to perform all the practical as described in the practical list.

2. For performing the practical list, student can able to work individually or work in a team as per
subject teacher guidelines.
3. After establishing the team, every team will have to identify the problem area / definition for
performing the laboratory work.
4. Every team has to approve their problem definition to respective faculty member within 15 days
of the beginning of the semester.
5. Once the problem definition is approved by the faculty member, every team has to perform all
the practical based on their respective problem definition.
Soft
Software Engineering (3161605)

Index
(Progressive Assessment
Sheet)

Sr. Objective(s) of Experiment Page Date of Date of Assessmen Sign. of Remar

No. No. perform submiss t Teacher ks
ance ion Marks with date
1 Study of various type of Software Process
models with comparison and find out which
process model will be appropriate for your
selected Project.
2 Discuss the Project Management: Project
Planning and Project Scheduling about your
Project.
3 Prepare the Software Requirement
Specification (SRS) document for selected
project.
4 Draw the Data Flow Diagram for your selected
Project.
5 Draw the Entity-Relationship Diagram for your
selected Project
6 Draw Usecase Diagram for your selected
Project.
7 Solve the problem by applying basic
COCOMO model.
8 Modeling UML Class Diagrams and
Sequence diagrams
9. Design the various test cases to perform the
testing of the system and also perform the
various type of testing.
10. Study of any two Open source tools in
DevOps for Infrastructure Automation,
Configuration Management ,Deployment
Automation, Performance Management, Log
Management Monitoring.
Total
Soft
Software Engineering (3161605)

Practical – 1
AIM: Study of various type of Software Process models with comparison and find out which process
model will be appropriate for your selected Project.

Objectives: To learn different process models and identify suitable model for the project development.

 Theory:
A software process is defined as a collection of work activities, actions, and tasks that are
performed when some work product is to be created.

List of Different Process Models

1. Waterfall model :
1. Requirement Gathering and
Analysis: In this initial phase, all the
necessary requirements for the
system are identified and documented
in a specification requirement
document.
2. System Design: Building upon the
requirements gathered, this phase
Involves creating a detailed system
design. This design specifies the
hardware and system requirements
and defines the overall system
architecture. Figure 1:Waterfall Model
3. Implementation: Based on the system design, the actual system is developed in small units
or programs. Each unit is developed and tested individually in a process known as Unit Testing.

4. Integration and Testing: Once all the individual units are developed and tested, they are integrated into
a complete system. The integrated system is then tested thoroughly for any faults or failures.
5. Deployment of the System: After successful testing, the product is deployed in the customer
environment or released into the market.
6. Maintenance: As the system is used in the client environment, issues may arise. To address these,
patches are released. Additionally, new versions of the product may be released to enhance its features.
Maintenance ensures that these changes are delivered to the customer environment.
 Soft
Software Engineering (3161605)

2. V model :
 Verification: This phase
includes a static analysis method,
such as a review which is conducted
without executing the code. It
evaluates the product development
process to determine if specified
requirements are met.
 Validation: This phase involves a
dynamic analysis method, including
functional and non-functional
testing, which is performed by
executing the code. Validation
classifies the software after the
development process to ascertain if
it meets customer expectations and
Figure 2:V Model
requirements.
 The V-Model incorporates
Verification phases on one side and Validation phases on the other side. The Verification and
Validation processes are connected by the coding phase in a V-shape, hence its name. Here are the
various phases of the Verification Phase in the V-model:

1. Business Requirement Analysis: This initial step involves understanding the product requirements from
the customer's perspective. It requires detailed communication to grasp the customer's expectations and
exact requirements.
2. System Design: In this stage, system engineers analyze and interpret the business aspects of the
proposed system by studying the user requirements document.
3. Architecture Design: The architecture design phase involves selecting a baseline architecture that
comprehensively addresses all requirements. This typically includes a list of modules, brief functionality
of each module, interface relationships, dependencies, database tables, architecture diagrams, technology
details, etc. Integration testing is also carried out in this phase.
4. Module Design: During this phase, the system is broken down into small modules. Detailed designs of
these modules are specified, which is known as Low-Level Design.
5. Coding Phase: After the design phase, the coding phase begins. Based on the requirements, a suitable
programming language is chosen. Coding is done following specific guidelines and standards. Before
checking in the repository, the final build is optimized for better performance. The code also undergoes
many code reviews to ensure its performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase.
These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity
which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity
can function correctly when isolated from the rest of the codes/ units.
Soft
Software Engineering (3161605)
2. Integration Testing: Integration Test Plans are developed during the Architectural Design Phase.
These tests verify that groups created and tested independently can coexist and communicate among
themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and
Integration Test Plans, System Tests Plans are composed by the client’s business team. System Test
ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It
includes testing the software product in user atmosphere. Acceptance tests reveal the compatibility
problems with the different systems, which is available within the user atmosphere. It conjointly
discovers the non-functional problems like load and performance defects within the real user
atmosphere.

3. Incremental model :
The Incremental Model of software development
Progress through several phases:
1. Requirement Analysis: In this initial phase,
the product analysis experts identify the
requirements. The requirement analysis
team understands the system's functional
requirements, which plays a crucial
role in developing software under the
incremental model.
Figure 3:Incremental Model

2. Design & Development: This phase completes the design of the system functionality and the
development of the method. The incremental model uses the design and development phase when
developing new functionality.

3. Testing: The testing phase in the incremental model checks the performance of each existing function and
any additional functionality. Various methods are used to test the behavior of each task.

4. Implementation: The implementation phase enables the coding phase of the development system. It
involves the final coding designed in the design and development phase and tests the functionality from
the testing phase. After this phase, the product's working functionality is enhanced and upgraded to the
final system product.

The Incremental Model is used in the following scenarios:

• When requirements are complex: Breaking them down into smaller chunks makes them easier to handle.
• For lengthy development schedules: Incremental development allows for regular releases, keeping
stakeholders engaged.
• With less experienced teams: It allows for learning and improvement over successive iterations.
• When quick product releases are required: Incremental development enables rapid, iterative
improvements.
• For prioritized requirements: Allows development of high-priority features first, ensuring essential
functionality is delivered early.
Soft
Software Engineering (3161605)

4. RAD model.

Figure 4: RAD Model

The various phases of RAD are as follows:

1. Business Modelling: This phase defines the flow of information among business functions. It answers
questions like what data drives the business process, who generates it, where does it go, who processes it,
and so on.
2. Data Modelling: The data collected from business modeling is refined into a set of data objects (entities)
needed to support the business. Attributes (characteristics of each entity) are identified, and the
relationships between these data objects (entities) are defined.
3. Process Modelling: Information objects defined in the data modeling phase are transformed to achieve
the data flow necessary to implement a business function. Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.
4. Application Generation: This phase involves using automated tools to facilitate the construction of the
software.
5. Testing & Turnover: Many of the programming components have already been tested since RAD
emphasizes reuse. This reduces overall testing time. However, the new parts must be tested, and all
interfaces must be fully exercised.

5. Agile model :
Soft
Software Engineering (3161605)
Phases of Agile Model:
1. Requirements gathering: In this phase, the requirements are defined. It involves explaining business
opportunities and planning the time and effort needed to build the project. Based on this information,
technical and economic feasibility can be evaluated.
2. Designing: Once the project is identified, stakeholders work together to define requirements. User flow
diagrams or high-level UML diagrams can be used to illustrate the workflow of new features and how
they will integrate with the existing system.
3. Construction/ iteration: After the requirements are defined, the work begins. Designers and developers
start working on the project, aiming to deploy a working product. The product undergoes various stages
of improvement, including the inclusion of simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks for
bugs.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback about
the product and works through the feedback.

Agile Testing Methods:

1. Scrum
2. Crystal
3. Dynamic Software Development Method (DSDM)
4. Feature Driven Development (FDD)
5. Lean Software Development
6. eXtreme Programming (XP)

When to use the Agile Model?

• When frequent changes are required.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with a software team all the time.
• When project size is small.

6. Iterative model :

Figure 6:Iterative Model

Soft
Software Engineering (3161605)
The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered from customers and
analyzed by an analyst to ensure they can be fulfilled within budget. Once this is done, the software team
moves on to the next phase.
2. Design: During the design phase, the team creates the software using various diagrams such as Data
Flow diagrams, activity diagrams, class diagrams, and state transition diagrams.
3. Implementation: In the implementation phase, the requirements are translated into code and transformed
into computer programs, which form the software.
4. Testing: After the coding phase is completed, software testing begins using different methods such as
white box, black box, and grey box testing.
5. Deployment: Once all the phases are completed, the software is deployed to its working environment.
6. Review: After the software is deployed, a review phase is conducted to check the behavior and validity
of the product. If any errors are found, the process starts again from the requirement gathering phase.
7. Maintenance: In the maintenance phase, after deployment of the software in the working environment
there may be some bugs, some errors or new updates are required. Maintenance involves debugging and
new addition options.

7. Spiral model :

Figure 7:Spiral Model

Each cycle in the spiral is divided into four parts:

1. 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.
2. 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.
3. 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.
Soft
Software Engineering (3161605)
4. 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.
• The development phase depends on the remaining risks. For example, if performance or user-interface
risks are treated more essential than the program development risks, the next phase may be an
evolutionary development that includes developing a more detailed prototype for solving the risks.
• The risk-driven feature of the spiral model allows it to accommodate any mixture of a specification-
oriented, prototype-oriented, simulation-oriented, or another type of approach. An essential element of
the model is that each period of the spiral is completed by a review that includes all the products
developed during that cycle, including plans for the next cycle. The spiral model works for development
as well as enhancement projects.

8. 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. In
many instances, the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system,
the processing needs, and the output requirement, the prototyping model may be employed.

Steps of Prototype Model

 Requirement Gathering and Analyst

 Quick Decision
 Build a Prototype
 Assessment or User Evaluation
 Prototype Refinement
 Engineer Product
Soft
Software Engineering (3161605)

1. State weather the following statements are true or false. Justify your answer.
a. Software development organizations which follow the iterative waterfall model for
product development provide maximum customer satisfaction.
Soft
Software Engineering (3161605)

b. The loops for spiral model are fixed.

2. Write the reasons to justify which life model you going to use to develop the software in the
project.
Soft
Software Engineering (3161605)

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S.Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill
International Edition
Soft
Software Engineering (3161605)

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 2
AIM: Discuss the Project Management: Project Planning and Project Scheduling about your Project.

Objectives:

1. To represent the plan to deliver the project scope over time.

Theory:
Once a project is found to be feasible, software project managers undertake project planning. Project
planning is undertaken and completed even before any development activity starts. Project planning
consists of the following essential activities:
Project-task scheduling is an important project planning activity. It involves deciding which
tasks would be taken up when. In order to schedule the project activities, a software project manager
needs to do the following:

1. Identify all the tasks needed to complete the project.

2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path.

A critical path is the chain of activities that determines the duration of the project. The first step in
scheduling a software project involves identifying all the tasks necessary to complete the project. A
good knowledge of the intricacies of the project and the development process helps the managers to
effectively identify the important tasks of the project. Next, the large tasks are broken down into a
logical set of small activities which would be assigned to different engineers. The work breakdown
structure formalism helps the manager to breakdown the tasks systematically after the project manager
has broken down the tasks and created the work breakdown structure, he has to find the dependency
among the activities.

Dependency among the different activities determines the order in which the different activities would
be carried out. If an activity A requires the results of another activity B, then activity A must be
scheduled after activity B. In general, the task dependencies define a partial ordering among tasks, i.e.
each tasks may precede a subset of other tasks, but some tasks might not have any precedence ordering
defined between them (called concurrent task). The dependency among the activities is represented in
the form of an activity network. Once the activity network representation has been worked out,
resources are allocated to each activity.
Soft
Software Engineering (3161605)

Resource allocation is typically done using a Gantt chart. After resource allocation is done, a PERT
chart representation is developed. The PERT chart representation is suitable for program monitoring and
control. For task scheduling, the project manager needs to decompose the project tasks into a set of
activities. The time frame when each activity is to be performed is to be determined. The end of each
activity is called milestone. The project manager tracks the progress of a project by monitoring the
timely completion of the milestones. If he observes that the milestones start getting delayed, then he has
to carefully control the activities, so that the overall deadline can still be met.

A Gantt chart(Time line chart) is a special type of bar chart where each bar represents an activity. The
bars are drawn along a time line. The length of each bar is proportional to the duration of time planned
for the corresponding activity. Gantt charts are used in software project management are actually an
enhanced version of the standard Gantt charts.
Soft
Software Engineering (3161605)

Quiz:

1) Explain project scheduling process.

2) Explain Software metrics used for software cost estimation

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S.Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill
International Editions
References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 3
AIM: Prepare the Software Requirement Specification (SRS) document for selected project.

Objectives:

1. Learn how to provide a detailed overview of our software product, its parameters and goals.

2. Describes the project's target audience and its user interface, hardware and software requirements.

Theory:

A software requirements specification (SRS) is a document that is created when a detailed description of
all aspects of the software to be built must be specified before the project is to commence. It is important
to note that a formal SRS is not always written. In fact, there are many instances in which effort
expended on an SRS might be better spent in other software engineering activities. However, when
software is to be developed by a third party, when a lack of specification would create severe business
issues, or when a system is extremely complex or business critical, an SRS may be justified.

IEEE Template for SRS

Soft
Software Engineering (3161605)

Software Requirements Specification

For <Project>
Version 1.0 approved

Prepared by <author>

<organization>

<date created>
Soft
Software Engineering (3161605)

Table of Contents
Table of Contents 11
Revision History 12
1. Introduction 13
1.1 Purpose 13
1.2 Document Conventions 13
1.3 Intended Audience and Reading SuggestionsError! Bookmark not defined.
1.4 Product Scope 13
1.5 References 13
2. Overall Description 13
2.1 Product Perspective 13
2.2 Product Functions 13
2.3 User Classes and Characteristics 13
2.4 Operating Environment 13
2.5 Design and Implementation Constraints 14
2.6 User Documentation 14
2.7 Assumptions and Dependencies 14
3. External Interface Requirements 14
3.1 User Interfaces 14
3.2 Hardware Interfaces 14
3.3 Software Interfaces 14
3.4 Communications Interfaces 14
4. System Features 15
4.1 System Feature 1 15
4.2 System Feature 2 (and so on) 15
5. Other Nonfunctional Requirements 15
5.1 Performance Requirements 15
5.2 Safety Requirements 15
5.3 Security Requirements 16
5.4 Software Quality Attributes 16
5.5 Business Rules 16
6. Other Requirements 16
Appendix A: Glossary16
Appendix B: Analysis Models 16
Appendix C: To Be Determined List 16

Revision History
Name Date Reason For Changes Version
Soft
Software Engineering (3161605)

Introduction
Purpose
The purpose of this Software Requirements Specification (SRS) is to define the requirements for “identifying
fake product through barcode based blockchain system” v1.0. This system uses blockchain technology to
verify the authenticity of products through barcode scanning. The SRS covers the entire system, including
the user interface for barcode scanning, the blockchain network for data verification, and the database for
storing product information. The goal is to provide a reliable and secure method for consumers and retailers
to verify the authenticity of products, thereby combating counterfeit goods in the market.

Document Conventions
In this SRS for the “identifying fake product through barcode based blockchain system” system, we have
adhered to the following conventions:

Fonts: We have used ‘Arial’ for the main text, ‘Courier New’ for code snippets, and ‘Times New Roman’ for
headers.

Highlighting: Important terms and concepts are highlighted in bold. Code or technical terms are presented
in monospace.

Requirement Priorities: Each requirement statement has its own priority. Higher-level requirement priorities
are not assumed to be inherited by detailed requirements.

Requirement Identification: Each requirement is uniquely identified with a number for easy reference.

Terminology: All terms are defined in a glossary at the end of the document. Blockchain and barcode-
related terms are used consistently throughout the document.

These conventions ensure clarity and consistency throughout the document.

Product Scope
The “identifying fake product through barcode based blockchain system” is a blockchain-based system
designed to identify fake products through barcode scanning. Its primary objective is to ensure product
authenticity, thereby protecting consumers and legitimate businesses from counterfeit goods.

The system offers several benefits:

1. Consumer Protection: By verifying product authenticity, it protects consumers from counterfeit
goods which may be of inferior quality or harmful.
2. Business Protection: It helps businesses protect their brand reputation and revenue by preventing
the sale of counterfeit versions of their products.
3. Trust and Transparency: The use of blockchain technology ensures that the product verification
process is transparent and cannot be tampered with, thereby increasing trust in the system.

This system aligns with corporate goals of enhancing customer trust, protecting brand integrity, and
promoting ethical business practices. It also supports broader business strategies aimed at leveraging
technology to combat counterfeiting and improve supply chain transparency. If a separate vision and scope
document is available, please refer to it for more detailed information.
 Soft
Software Engineering (3161605)

References

1. “Blockchain Technology Overview”, National Institute of Standards and Technology, Version 1.0,
January 2018, NIST Website

2. “Barcode Standards”, GS1 US, Version 2023, GS1 US Website

3. “User Interface Design Guide”, Internal Document, Version 2.1, February 2024, Available upon request.
4. “System Requirements Specification for Blockchain Systems”, IEEE, Version 3.0, 2023, IEEE Xplore
5. “Use Case Document for Product Authenticator”, Internal Document, Version 1.0, January 2024,
Available upon request.
6. “Vision and Scope Document for Product Authenticator”, Internal Document, Version 1.0, December
2023, Available upon request.

Overall Description
Product Perspective

The “identifying fake product through barcode based blockchain system” is a new, self-contained product
designed to combat the issue of counterfeit goods in the market. It is not a follow-on member of a product
family, nor a replacement for certain existing systems. Instead, it introduces a novel approach to product
verification using blockchain technology and barcode scanning.

This system can also be viewed as a component of a larger ecosystem involving manufacturers, retailers,
and consumers. It interfaces with existing inventory management systems at the manufacturer and retailer
levels, and with consumer devices for barcode scanning.

The major components of the system include the user interface for barcode scanning, the blockchain
network for data verification, and the database for storing product information. These components interact
with each other and with external systems to provide a secure and reliable product verification process.
.

Product Functions

The major functions of the “Identifying Fake Product through Barcode Based Blockchain System” could include:

1. Barcode Scanning: The system should allow users to scan the barcode of a product using a
smartphone or a barcode reader.
2. Product Verification: After scanning, the system should verify the product’s authenticity by checking
the product information stored in the blockchain against the information encoded in the barcode.
3. Product Information Retrieval: The system should retrieve detailed product information such as
manufacturing date, batch number, manufacturer details, etc., from the blockchain.
4. User Feedback: The system should allow users to provide feedback on the product and its authenticity,
which can be stored in the blockchain and used for future reference.
5. Alerts and Notifications: If a product is identified as fake, the system should alert the user and
possibly notify relevant authorities or parties.
6. Data Synchronization: The system should synchronize data across the blockchain network to ensure
all users have access to the latest and most accurate product information.
7. Security Measures: The system should implement robust security measures to prevent tampering with
the blockchain data, ensuring the reliability of the product verification process.
These functions work together to provide a secure and reliable method for consumers to verify product
authenticity and combat counterfeiting. The blockchain serves as an immutable, decentralized database of
 Soft
Software Engineering (3161605)
product information, making it difficult for counterfeiters to manipulate product data. The barcode provides a
simple and accessible interface for users to interact with this database. Together, they form a powerful tool for
ensuring product authenticity. Please note that this is a high-level description and the actual system design
may vary based on specific requirements and constraints. The detailed functionalities and system design would
be described in the subsequent sections of the SRS.

User Classes and Characteristics

For the “Identifying Fake Product through Barcode Based Blockchain System”, we can anticipate several user
classes:
1. End Consumers: These are the individuals who will use the system to verify the authenticity of a
product before purchase. They may have varying levels of technical expertise and may use the system
infrequently, only when purchasing products. Their primary function is to scan barcodes and verify
product authenticity.
2. Retailers: Retailers sell products to end consumers and would use the system to verify the authenticity
of their stock. They may use the system more frequently than end consumers. Their primary functions
are to scan barcodes, verify product authenticity, and possibly register new products in the system.
3. Manufacturers: Manufacturers produce the products and would use the system to register new
products. They have a high level of technical expertise and would use the system frequently. Their
primary functions are to generate barcodes, register new products in the system, and monitor product
verification results.
4. System Administrators: System administrators maintain the system. They have the highest level of
technical expertise and full access to all system functions. They are responsible for system
maintenance, user management, and handling security issues.
The most important user classes for this product are the end consumers and the manufacturers, as they are
the primary users of the system. The system is designed to protect end consumers from counterfeit products,
and manufacturers are the ones who register products in the system. Retailers and system administrators are
also important, but their satisfaction is less critical to the system’s success. The system should be designed to
be user-friendly for end consumers and manufacturers, as they are the primary users. Retailers and system
administrators require more technical expertise, so the system can afford to be more complex for these user
classes.

Operating Environment

The “Identifying Fake Product through Barcode Based Blockchain System” is designed to be platform-
independent and should be able to operate in a variety of environments. Here are some considerations:

1. Hardware Platform: The system should be compatible with various hardware platforms. For end
consumers, it should work on smartphones and tablets with built-in cameras for barcode scanning. For
retailers and manufacturers, it might need to work on desktop computers or handheld devices with
barcode scanners.
2. Operating System: The system should be designed to work on multiple operating systems. For
smartphones and tablets, this includes iOS and Android. For desktop computers, this includes
Windows, macOS, and Linux.
3. Software Components: The system will need to interact with various software components:
o A barcode scanning application to read barcodes.
o A web browser or dedicated app for users to interact with the system.
o A blockchain network to store and retrieve product information.
o Other database systems for storing user feedback and other non-blockchain data.
4. Coexistence with Other Applications: The system should be designed to peacefully coexist with other
applications on the user’s device. It should not interfere with the operation of other software, and it
should be secure to prevent unauthorized access to the user’s device.
 Soft
Software Engineering (3161605)
5. Network Requirements: As a blockchain-based system, it will require an internet connection to interact
with the blockchain network.

Design and Implementation Constraints

The design and implementation of the “Identifying Fake Product through Barcode Based Blockchain System”
could be constrained by several factors:

1. Regulatory Policies: The system must comply with all relevant data protection and privacy laws. This
includes regulations on how consumer data is collected, stored, and used.
2. Hardware Limitations: The system should be designed to work on devices with varying capabilities.
This includes considerations for memory and processing power, especially for devices used by end
consumers.
3. Interfaces to Other Applications: The system may need to interface with other applications such as
barcode scanning apps or retail management systems. These interfaces must be designed carefully to
ensure compatibility and seamless operation.
4. Specific Technologies: The choice of blockchain technology could constrain the design. Different
blockchain platforms have different capabilities and limitations, and the chosen platform will dictate
certain aspects of the system’s design.
5. Parallel Operations: The system should be capable of handling multiple simultaneous requests, which
requires careful design to ensure performance and accuracy.
6. Language Requirements: The system should be accessible to users who speak different languages.
This may require the system to support multiple languages.
7. Communications Protocols: The system will need to use secure and reliable communication protocols
to interact with the blockchain and other components of the system.
8. Security Considerations: Security is a major concern for any blockchain system. The system must be
designed to prevent unauthorized access and protect user data.
9. Design Conventions or Programming Standards: If the customer’s organization will be maintaining
the delivered software, the system should be designed according to their conventions and standards.
This could include specific programming languages, frameworks, or coding standards.

User Documentation

The user documentation for the “Identifying Fake Product through Barcode Based Blockchain System” could
include:
1. User Manual: A comprehensive guide detailing the system’s features, how to use them, and
troubleshooting tips. This could be provided as a PDF for easy access and printing.
2. Online Help: An online version of the user manual, possibly integrated into the system itself. This would
allow users to quickly search for and find the information they need.
3. Tutorials: Step-by-step guides that walk users through specific tasks in the system. These could be
provided as written guides, video tutorials, or interactive lessons within the system.
4. FAQs: A list of Frequently Asked Questions (and their answers) that users might have about the
system.
5. Glossary: A list of terms and definitions related to the system and blockchain technology.
6. Release Notes: Documentation detailing the changes, improvements, and bug fixes in each new
version of the system.

The exact format of these documents would depend on the specific requirements and constraints of the project.
However, they should all be designed to be easily accessible and understandable to the user. They could be
provided in multiple formats (such as HTML for online access, PDF for printing, etc.) to accommodate different
user preferences and needs. The documentation should also adhere to any relevant documentation standards,
such as the Microsoft Manual of Style for Technical Publications or the Chicago Manual of Style. The choice of
standard would depend o the target audience and the nature of the system.
 Soft
Software Engineering (3161605)

Assumptions and Dependencies

The “Identifying Fake Product through Barcode Based Blockchain System” could have several assumptions
and dependencies:
Assumptions:
1. Blockchain Technology: It is assumed that the chosen blockchain technology will be able to handle
the volume of transactions and data storage required by the system.
2. Barcode Standards: The system assumes that all products will use a standard barcode format that the
system can read.
3. Internet Connectivity: The system assumes that users will have reliable internet connectivity to access
the blockchain and verify product authenticity.
4. User Acceptance: The system assumes that end consumers, retailers, and manufacturers will accept
and adopt this new method of product verification.
Dependencies:
1. Third-Party Barcode Scanning Application: The system may depend on a third-party application for
barcode scanning functionality.
2. Blockchain Platform: The system’s operation is dependent on the chosen blockchain platform. Any
changes or issues with the platform could affect the system.
3. Operating Systems: The system’s performance and compatibility are dependent on the operating
systems of the devices it runs on.
4. Regulatory Compliance: The system’s operation is dependent on compliance with data protection and
privacy laws. Any changes in these laws could require changes to the system.
These assumptions and dependencies could affect the requirements, design, and implementation of the
system. If any of these assumptions are incorrect or change, or if any of the dependencies are not met, the
project could be affected. Therefore, these factors should be carefully considered and monitored throughout the
project.

External Interface Requirements

User Interfaces

The user interface for the “Identifying Fake Product through Barcode Based Blockchain System” should be
designed to be intuitive, user-friendly, and accessible. Here are some logical characteristics of the user
interface:
1. Barcode Scanning Interface: This is the primary interface for users to interact with the system. It
should include a simple and intuitive method for users to scan barcodes using their device’s camera.
2. Product Verification Interface: After a barcode is scanned, the system should display the product’s
information retrieved from the blockchain. If the product is identified as fake, the system should clearly
alert the user.
3. User Feedback Interface: The system should provide an interface for users to leave feedback about
the product and its authenticity. This could include a rating system and a text box for comments.
4. Help and Support Interface: The system should include a help button on every screen that provides
access to user documentation, FAQs, and customer support.
5. Settings Interface: The system should provide an interface for users to customize their experience,
such as language settings, notification preferences, etc.
The user interface should follow modern design principles and be consistent across all screens. It should use
clear and concise language, easy-to-understand icons, and intuitive navigation. Error messages should be
informative and guide the user towards a solution.
Keyboard shortcuts could be implemented for frequently used functions to enhance the user experience,
especially for desktop users.
The user interface should also be designed with accessibility in mind, ensuring that users with disabilities can
easily use the system. This could include features like text-to-speech for visually impaired users and speech-to-
text for users with mobility impairments.
 Soft
Software Engineering (3161605)

Hardware Interfaces

The “Identifying Fake Product through Barcode Based Blockchain System” will interact with various hardware
components. Here are some of the key hardware interfaces:
1. Barcode Scanners: These devices, either standalone or integrated into smartphones, are used to scan
the barcodes on products. The system should be compatible with a wide range of barcode scanners
and should be able to process the data they provide.
2. Smartphones/Tablets: The system will likely have a mobile application component for end consumers.
This means it should be designed to work on a variety of devices with different operating systems,
screen sizes, and capabilities.
3. Servers: The blockchain network will likely be hosted on servers. The system should be designed to
efficiently interact with these servers to retrieve and update product information.
4. Network Hardware: The system will require an internet connection to interact with the blockchain. This
means it will interact with network hardware like routers and modems.
The nature of the data and control interactions between the software and the hardware will depend on the
specific hardware component. For example, barcode scanners will provide product barcode data to the system,
while the system will send requests to servers to retrieve or update product information.
The system should use standard communication protocols to ensure compatibility and security. For example, it
could use HTTP/HTTPS for communication with servers, and standard protocols like Bluetooth or Wi-Fi for
communication with barcode scanners.

Software Interfaces

The “Identifying Fake Product through Barcode Based Blockchain System” will interact with various software
components. Here are some of the key software interfaces:
1. Blockchain Platform: The system will interact with a specific blockchain platform (name and version to
be determined based on project requirements). This platform will provide the infrastructure for storing
and retrieving product information.
2. Barcode Scanning Application: The system will interface with a barcode scanning application (name
and version to be determined based on project requirements). This application will provide the
functionality for scanning barcodes and decoding the information they contain.
3. Operating Systems: The system will be designed to work on multiple operating systems, including
various versions of iOS, Android, Windows, macOS, and Linux. The system will need to interface with
these operating systems to access hardware resources, manage memory, handle user input, and
display output.
4. Database Systems: Besides the blockchain, the system may also interact with traditional database
systems for storing user feedback and other non-blockchain data.
5. Integrated Commercial Components: The system may also interface with commercial components
such as payment gateways, user authentication services, or analytics tools.
Data items coming into the system could include barcode data from the barcode scanning application, user
feedback, and requests to retrieve or update product information. Data items going out of the system could
include product information retrieved from the blockchain, verification results, and user feedback.
The system will need to provide services for barcode scanning, product verification, product information
retrieval, user feedback, and data synchronization. The nature of communications will depend on the specific
software component. For example, communication with the blockchain platform could involve sending and
receiving data via API calls, while communication with the barcode scanning application could involve receiving
barcode data via an SDK.
Data that will be shared across software components could include product information, user feedback, and
verification results. If the data sharing mechanism must be implemented in a specific way, this will be specified
as an implementation constraint in the detailed design document.
 Soft
Software Engineering (3161605)

Communications Interfaces

The “Identifying Fake Product through Barcode Based Blockchain System” will require various communication
interfaces:
1. Web Browser: The system may have a web-based interface for users to interact with. This requires
standard web protocols like HTTP/HTTPS.
2. Network Server Communications: The system will need to communicate with servers to interact with
the blockchain and possibly other databases. This could involve various protocols, including TCP/IP for
general network communication, and specific application protocols like HTTP/HTTPS for web services,
FTP for file transfers, etc.
3. Electronic Forms: The system may use electronic forms for user input, such as providing feedback on
product authenticity. These forms should be designed to be easy to use and should validate input to
prevent errors and security issues.
4. Message Formatting: Messages sent between the system and the blockchain or other servers will
need to be formatted according to the requirements of the blockchain platform and any other APIs the
system uses.
5. Communication Standards: The system will likely use standard communication protocols like
HTTP/HTTPS for web services, FTP for file transfers, and TCP/IP for general network communication.
6. Communication Security: All communications should be encrypted to protect sensitive data. This
could involve using HTTPS for web services, SFTP for secure file transfers, and other encryption
methods for other types of communication.
7. Data Transfer Rates: The system should be designed to handle the data transfer rates required for
real-time barcode scanning and product verification.
8. Synchronization Mechanisms: The system will need to synchronize data across the blockchain
network, which could involve complex synchronization mechanisms to ensure all nodes in the network
have the latest and most accurate product information.

System Features

----------------------------------------
| User Interface |
----------------------------------------
|
|
---------------------
| Backend Server |
---------------------
|
|
External APIs
|
|
-------------
| Database |
-------------
|
|
-------------
| Response |
-------------
 Soft
Software Engineering (3161605)
System Feature 1

System Feature 1: Barcode Scanning and Verification

4.1.1 Description and Priority This feature allows users to scan the barcode of a product and verify its
authenticity using the blockchain system. This is a high priority feature as it forms the core functionality of the
system.
4.1.2 Stimulus/Response Sequences

 User opens the application and points their device camera at the product barcode.
 The system scans the barcode and retrieves the encoded product information.
 The system verifies the product information against the data stored in the blockchain.
 The system displays the verification result to the user.

4.1.3 Functional Requirements

REQ-1: The system must be able to scan barcodes using the device’s camera or a connected barcode
scanner.
REQ-2: The system must be able to decode the scanned barcode and retrieve the encoded product
information.
REQ-3: The system must be able to retrieve the corresponding product information from the blockchain using
the decoded product information.
REQ-4: The system must compare the retrieved product information with the blockchain data and determine
the authenticity of the product.
REQ-5: The system must display the verification result to the user in a clear and understandable manner.
REQ-6: The system should handle errors gracefully, such as when the barcode cannot be scanned or the
product information cannot be retrieved from the blockchain. In such cases, the system should display an
appropriate error message to the user.

System Feature 2

System Feature 2: Product Information Retrieval

4.1.1 Description and Priority This feature allows users to retrieve detailed product information from the
blockchain after scanning a product’s barcode. This is a high priority feature as it provides users with the
information they need to make informed purchasing decisions.
4.1.2 Stimulus/Response Sequences

 User scans a product’s barcode using the system.

 The system retrieves the product’s information from the blockchain.
 The system displays the retrieved product information to the user.

4.1.3 Functional Requirements

REQ-1: The system must be able to retrieve product information from the blockchain using the product ID
obtained from the scanned barcode.
REQ-2: The retrieved product information should include details such as the product’s name, manufacturer,
manufacturing date, batch number, and any other relevant information stored in the blockchain.
REQ-3: The system must display the retrieved product information to the user in a clear and understandable
manner.
REQ-4: The system should handle errors gracefully, such as when the product information cannot be retrieved
from the blockchain. In such cases, the system should display an appropriate error message to the user.
 Soft
Software Engineering (3161605)

Other Nonfunctional Requirements

Performance Requirements

The performance requirements for the “Identifying Fake Product through Barcode Based Blockchain System”
could include:
1. Response Time: The system should respond quickly to user actions. For example, after a user scans a
barcode, the system should be able to verify the product’s authenticity and display the result to the user
within a few seconds. This is important to ensure a smooth user experience.
2. Data Synchronization: The system should synchronize data across the blockchain network in a timely
manner. This is crucial to ensure that all users have access to the latest and most accurate product
information.
3. Scalability: The system should be able to handle a large number of users and transactions without a
significant degradation in performance. This is important as the system could potentially be used by
millions of consumers, retailers, and manufacturers worldwide.
4. Reliability: The system should be reliable and available for use at all times. This is important as users
may need to verify product authenticity at any time.
5. Security: The system should be able to handle security-related tasks, such as encryption and
decryption, without a significant impact on performance. This is crucial to protect sensitive data and
ensure the integrity of the product verification process.

Safety Requirements
The safety requirements for the “Identifying Fake Product through Barcode Based Blockchain System” could
include:
1. Data Privacy and Security: The system should ensure the privacy and security of user data. It should
use encryption and other security measures to protect sensitive data. Any loss, damage, or
unauthorized access to user data should be prevented.
2. Regulatory Compliance: The system should comply with all relevant laws and regulations related to
data privacy, consumer protection, and product safety. This includes regulations like the General Data
Protection Regulation (GDPR) in the EU, the California Consumer Privacy Act (CCPA) in the US, and
others.
3. Error Handling: The system should handle errors gracefully to prevent harm to users or damage to the
system. This includes providing clear error messages to users and preventing harmful actions.
4. Product Verification Accuracy: The system should accurately verify product authenticity to prevent
harm to users from counterfeit products. Any inaccuracies in product verification could result in harm to
users and should be prevented.
5. System Availability: The system should be available for use at all times to allow users to verify product
authenticity whenever needed. Any downtime could result in users being unable to verify product
authenticity, which could potentially result in harm.
6. Safety Certifications: The system should meet any safety certifications that are required for systems of
this nature. This could include certifications related to data security, consumer safety, etc.

Security Requirements
The security requirements for the “Identifying Fake Product through Barcode Based Blockchain System” could
include:
1. Data Privacy and Security: The system should ensure the privacy and security of user data. It should
use encryption and other security measures to protect sensitive data. Any unauthorized access to user
data should be prevented.
2. User Identity Authentication: The system should authenticate the identity of users to prevent
unauthorized access. This could involve the use of usernames and passwords, two-factor
authentication, or other authentication methods.
 Soft
Software Engineering (3161605)
3. Regulatory Compliance: The system should comply with all relevant laws and regulations related to
data privacy and security. This includes regulations like the General Data Protection Regulation (GDPR)
in the EU, the California Consumer Privacy Act (CCPA) in the US, and others.
4. Security Certifications: The system should meet any security certifications that are required for
systems of this nature. This could include certifications related to data security, such as ISO/IEC 27001,
or privacy certifications, such as Privacy Shield.
5. Blockchain Security: The system should ensure the security of the blockchain network. This includes
preventing unauthorized transactions, ensuring the integrity of the blockchain data, and protecting the
network from attacks.

Software Quality Attributes

The software quality attributes for the “Identifying Fake Product through Barcode Based Blockchain System”
could include:
1. Adaptability: The system should be able to adapt to different operating systems, devices, and barcode
standards. This is important to ensure a wide range of users can use the system.
2. Availability: The system should be available for use at all times. This is crucial as users may need to
verify product authenticity at any time.
3. Correctness: The system should accurately verify product authenticity and provide correct product
information. This is essential to protect users from counterfeit products.
4. Flexibility: The system should be flexible enough to accommodate changes, such as new barcode
standards or changes in blockchain technology.
5. Interoperability: The system should be able to interact seamlessly with other systems, such as
barcode scanning apps or retail management systems.
6. Maintainability: The system should be easy to maintain and update. This is important to ensure the
system can adapt to changes and fix any issues that arise.
7. Portability: The system should work on a variety of devices and operating systems. This is important to
ensure a wide range of users can use the system.
8. Reliability: The system should operate reliably under all conditions. This is crucial to ensure users can
trust the system to verify product authenticity.
9. Reusability: Components of the system should be designed in a way that they can be reused in other
systems or parts of the same system. This can help reduce development time and costs.
10. Robustness: The system should handle errors gracefully and continue to operate even under
unexpected conditions.
11. Testability: The system should be designed in a way that makes it easy to test. This is important to
ensure all features work correctly and to identify any issues.
12. Usability: The system should be easy to use. This is crucial to ensure a wide range of users, including
those with little technical expertise, can use the system.

Business Rules
The business rules for the “Identifying Fake Product through Barcode Based Blockchain System” could include:
1. User Roles and Permissions: Different users may have different roles and permissions in the system.
For example, end consumers can scan barcodes and verify product authenticity, but they cannot add
new products to the blockchain. On the other hand, manufacturers can add new products to the
blockchain, but they cannot modify or delete existing product information.
2. Product Registration: Only authorized manufacturers can register new products in the blockchain.
This is to ensure that only legitimate products are added to the system.
3. Product Verification: Any user can verify the authenticity of a product. However, the verification result
is read-only and cannot be modified by users.
4. User Feedback: Users can provide feedback on the product and its authenticity. However, feedback
must be reviewed and approved before it is added to the blockchain to prevent spam or inappropriate
content.
5. Data Privacy: User data must be handled in accordance with all relevant data privacy laws and
regulations. This includes obtaining user consent before collecting personal data, and providing users
with the ability to view, modify, or delete their personal data.
 Soft
Software Engineering (3161605)
These business rules are not functional requirements in themselves, but they imply certain functional
requirements to enforce the rules. For example, the system must have functionality to manage user roles and
permissions, register new products, verify product authenticity, handle user feedback, and ensure data privacy.
The detailed functional requirements would be described in the subsequent sections of the SRS.

Other Requirements

1. Database Requirements: The system should be able to interact with a blockchain database for storing
and retrieving product information. It may also need to interact with traditional databases for storing user
feedback and other non-blockchain data.
2. Internationalization Requirements: The system should support multiple languages to cater to a global
user base. This includes providing translations of user interfaces, user documentation, and error
messages.
3. Legal Requirements: The system should comply with all relevant laws and regulations. This includes
data privacy laws, consumer protection laws, and any laws related to the sale and distribution of goods.
4. Reuse Objectives: Components of the system should be designed in a way that they can be reused in
other systems or parts of the same system. This can help reduce development time and costs.

Appendix A: Glossary
1. Blockchain: A type of database that stores data in blocks that are chained together. Once a block is
filled with data, it is chained onto the previous block, which makes the data chained together in
chronological order.
2. Barcode: A method of representing data in a visual, machine-readable form. On products, barcodes are
often used to encode a product number which can be scanned and looked up in a database to retrieve
product information.
3. Product Authenticity: The genuineness of a product. Authentic products are genuine, not counterfeit
or fake.
4. User Feedback: Information provided by users about their experience with a product or system.
5. Data Synchronization: The process of establishing consistency among data from a source to a target
data storage and vice versa.

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state- transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

The following items are to be determined (TBD) for the “Identifying Fake Product through Barcode Based
Blockchain System”:
1. Blockchain Platform: The specific blockchain platform to be used for the system is TBD. This will
affect various aspects of the system, including how product information is stored and retrieved, and the
security measures in place.
2. Barcode Scanning Application: The specific application or technology to be used for barcode
scanning is TBD. This will affect the user experience of scanning barcodes and the types of barcodes
that can be scanned.
3. Database Systems: If the system will interact with traditional databases in addition to the blockchain,
the specific database systems to be used are TBD.
4. Operating Systems: While the system is intended to work on multiple operating systems, the specific
operating systems and versions to be supported are TBD.
5. Security Certifications: The specific security certifications that the system should meet are TBD.
6. Internationalization: The specific languages to be supported by the system are TBD.
Soft
Software Engineering (3161605)
7. Legal Requirements: The specific legal requirements, such as data privacy laws and consumer
protection laws, that the system must comply with are TBD.
8. User Interface Design: The specific design of the user interface, including the layout, colors, fonts, and
icons, is TBD.

Quiz:

1. Which are properties of good SRS?

Soft
Software Engineering (3161605)

2. What is functional and non-functional requirement?

Soft
Software Engineering (3161605)
Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S.Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill
International Editions

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 4
AIM: Draw the Data Flow Diagram for your selected Project.

 Objectives:
To learn flow oriented model through data flow diagrams.

 Theory:
The DFD takes an input-process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of the
software. The data flow diagram enables you to develop models of the information domain and
functional domain.
Term Notation Remarks

External
Name of the external entity is written inside the rectangle
entity

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store; name of the data

Data store
store is written inside the shape

Data flow Data flow is represented by a directed arc with its data name
Soft
Software Engineering (3161605)

Explanation of Symbols used in DFD

 Process: Processes are represented by circle. The name of the process is written into the circle.
The name of the process is usually given in such a way that represents the functionality of the
process. More detailed functionalities can be shown in the next Level if it is required. Usually it
is better to keep the number of processes less than 7. If we see that the number of processes
becomes more than 7 then we should combine some the processes to a single one to reduce the
number of processes and further decompose it to the next level .
 External entity: External entities are only appear in context diagram. External entities are
represented by a rectangle and the name of the external entity is written into the shape. These
send data to be processed and again receive the processed data.
 Data store: Data stares are represented by a left-right open rectangle. Name of the data store is
written in between two horizontal lines of the open rectangle. Data stores are used as repositories
from which data can be flown in or flown out to or from a process.
 Data flow: Data flows are shown as a directed edge between two components of a Data Flow
Diagram. Data can flow from external entity to process, data store to process, in between two
processes and vice-versa.

.
 Background / Preparation:

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: The primary external entities (boxes) produce information for use by the
system and consume information generated by the system
 1-level DFD: It represents the main functions of the system and how they interact with
each other.
 2-level DFD: It represents the processes within each function of the system and how they
interact with each other.

 Tools / Material Needed:

o Hardware:
o Software:
Soft
Software Engineering (3161605)

Quiz:

1. In a data flow diagram, does an arrow represent a flow of control or something else?

2. What is “information flow continuity” and how is it applied as a data flow diagram
is refined?
3. What are the advantages of DFD?

Suggested Reference:

1. Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

International Editions

2. Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of the Faculty

Soft
Software Engineering (3161605)

Practical – 5
AIM: Draw the Entity-Relationship Diagram for your selected Project.

 Objectives:
1. Identify entity sets, their attributes, and various relationships
2. Represent the data model through ER diagram

 Theory:
Entity-Relationship model is used to represent a logical design of a database to be created. In ER
model, real world objects (or concepts) are abstracted as entities, and different possible
associations among them are modeled as relationships.

For example, student and school -- they are two entities. Students study in school. So, these two
entities are associated with a relationship "Studies in".

As another example, consider a system where some job runs every night, which updates the
database. Here, job and database could be two entities. They are associated with the relationship
"Updates".

Entity Set and Relationship Set

An entity set is a collection of all similar entities. For example, "Student" is an entity set that
abstracts all students. Ram, John are specific entities belonging to this set. Similarly, a
"Relationship" set is a set of similar relationships.

Attributes of Entity
Attributes are the characteristics describing any entity belonging to an entity set. Any entity in a set
can be described by zero or more attributes.
For example, any student has got a name, age, an address. At any given time a student can study
only at one school. In the school he would have a roll number, and of course a grade in which he
studies. These data are the attributes of the entity set Student.

Keys
One or more attribute(s) of an entity set can be used to define the following keys:

Super key: One or more attributes, which when taken together, helps to uniquely identify an entity
in an entity set. For example, a school can have any number of students. However, if we know
grade and roll number, then we can uniquely identify a student in that school.
Soft
Software Engineering (3161605)

Candidate key: It is a minimal subset of a super key. In other words, a super key might contain
extraneous attributes, which do not help in identifying an object uniquely. When such attributes
are removed, the key formed so is called a candidate key.
Primary key: A database might have more than one candidate key. Any candidate key chosen for a
particular implementation of the database is called a primary key.
Prime attribute: Any attribute taking part in a super key
Weak Entity
An entity set is said to be weak if it is dependent upon another entity set. A weak entity can't be
uniquely identified only by it's attributes. In other words, it doesn't have a super key.

For example, consider a company that allows employees to have travel allowance for their
immediate family. So, here we have two entity sets: employee and family, related by "Can claim
for". However, family doesn't have a super key. Existence of a family is entirely dependent on the
concerned employee. So, it is meaningful only with reference to employee.

Entity Generalization and Specialization

Once we have identified the entity sets, we might find some similarities among them. For example,
multiple person interacts with a banking system. Most of them are customers, and rest employees or
other service providers. Here, customers, employees are persons, but with certain specializations.
Or in other way, person is the generalized form of customer and employee entity sets.

ER model uses the "ISA" hierarchy to depict specialization (and thus, generalization).

Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider two entity
sets E1 and E2 associated by a relationship set R. Based on the number of entities in E1 and E2 are
associated with, we can have the following four type of mappings:

One to one: An entity in E1 is related to at most a single entity in E2, and vice versa
One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in E2 could
be related to at most a single entity in E1.
Many to one: Zero or more number of entities in E1 could be associated to a single entity in E2.
However, an entity in E2 could be related to at most one entity in E1.
Many to many: Any number of entities could be related to any number of entities in E2, including
zero, and vice versa.
ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have these information, we represent them
pictorially, called an entity-relationship (ER) diagram.
Soft
Software Engineering (3161605)

Quiz:

1. what is weak entityset?

2. what is mapping cardinality?

References used by the students:

Soft
Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 6
AIM: Draw Usecase Diagram for your selected Project .

 Objectives:
1. To write different scenarios of the system‟s execution.
2. To explore various UML use case diagram components to draw USECASE diagram.

 Theory:
o A use case diagram is used to represent the dynamic behavior of a system. It encapsulates
the system's functionality by incorporating use cases, actors, and their relationships. 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.
o Purpose of Use Case Diagrams
 The main purpose of a use case diagram is to portray the dynamic aspect of a
system. It accumulates the system's requirement, which includes both internal as
well as external influences. It invokes persons, use cases, and several things that
invoke the actors and elements accountable for the implementation of use case
diagrams. It represents how an entity from the external environment can interact
with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
o In a use-case diagram, an actor is a user of the system (i.e. Something external to the
system; can be human or non-human) acting in a particular role.
o A use-case is a task which the actor needs to perform with the help of the system,
e.g., find details of a book or print a copy of a receipt in a bookshop.
o We can draw a box (with a label) around a set of use cases to denote the system
boundary, as on the previous slide (“library system”).

Inheritance can be used between actors to show that all use cases of one actor are
available to the other:
If several use cases include, as part of their functionality, another use case, we have a
special way to show this in a use-case diagram with an <<include>> relation.
Soft
Software Engineering (3161605)

If a use-case has two or more significantly different outcomes, we can show this by
extending the use case to a main use case and one or more subsidiary cases.

 Background / Preparation:
How to draw a Use Case diagram?
It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified, they
are then transformed into the use cases to be used in the use case diagram.
After that, we will enlist the actors that will interact with the system. The actors are the person or
a thing that invokes the functionality of a system. It may be a system or a private entity, such that
it requires an entity to be pertinent to the functionalities of the system to which it is going to
interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.
The purposes of use case diagrams can be as follows:

 Used to gather requirements of a system.

 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.
Scenarios
• Scenarios are real-life examples of how a system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
Soft
Software Engineering (3161605)

A description of the state when the scenario finishes.

 Tools / Material Needed:
o Hardware:
o Software:

 Procedure / Steps:
o Developing Use Cases:
o Step One – Define the set of actors that will be involved in the story
 Actors are people, devices, or other systems that use the system or product within
the context of the function and behavior that is to be described
 Actors are anything that communicate with the system or product and that are
external to the system itself
o Step Two – Develop use cases, where each one answers a set of questions

Quiz:

1. What are the four main components of a use case diagram?

2. List relationship used in use case.
3. What Tests Can Help Find Useful Use Cases?

Suggested Reference:

1. Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

International Editions
2. Booch, G. et al. The Unified Modeling Language User Guide. Chapters 15, 18, 27.
Addison-Wesley.
3. Jacobson, I. et al. Object-Oriented Software Engineering: A Use-Case Driven Approach.
Addison-Wesley.
4. Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modelling Language.
Chapter 5. Addison Wesley.
Soft
Software Engineering (3161605)

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 7
AIM: Solve the problem by applying basic COCOMO model.

 Objectives:
1. Categorize projects using COCOMO, and estimate effort and development time
required for a project.

 Theory

A software project is not just about writing a few hundred lines of source code to achieve
a particular objective. The scope of a software project is comparatively quite large, and
such a project could take several years to complete. However, the phrase "quite large"
could only give some (possibly vague) qualitative information. As in any other science
and engineering discipline, one would be interested to measure how complex a project is.
One of the major activities of the project planning phase, therefore, is to estimate various
project parameters in order to take proper decisions. Some important project parameters
that are estimated include:

Project size: What would be the size of the code written say, in number of lines, files,
modules?
Cost: How much would it cost to develop a software? A software may be just pieces of
code, but one has to pay to the managers, developers, and other project personnel.
Duration: How long would it be before the software is delivered to the clients?
Effort: How much effort from the team members would be required to create the
software?
In this experiment we will focus on two methods for estimating project metrics:
COCOMO

COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there
could be three categories of software projects: organic, semidetached, and embedded. The
classification is done considering the characteristics of the software, the development
team and environment. These product classes typically correspond to application, utility
and system programs, respectively. Data processing programs could be considered as
application programs. Compilers, linkers, are examples of utility programs. Operating
systems, real-time system programs are examples of system programs. One could easily
apprehend that it would take much more time and effort to develop an OS than an
attendance management system.

The concept of organic, semidetached, and embedded systems are described below.
Soft
Software Engineering (3161605)

Organic: A development project is said to be of organic type, if The project deals with
developing a well understood application The development team is small The team
members have prior experience in working with similar types of projects
Semidetached: A development project can be categorized as semidetached type, if
The team consists of some experienced as well as inexperienced staff Team members
may have some experience on the type of system to be developed
Embedded: Embedded type of development project are those, which Aims to develop a
software strongly related to machine hardware Team size is usually large
Boehm suggested that estimation of project parameters should be done through three
stages: Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.

Basic COCOMO Model

The basic COCOMO model helps to obtain a rough estimate of the project parameters. It
estimates effort and time required for development in the following way:
Effort = a * (KDSI)b PM
Tdev = 2.5 * (Effort)c Months

where

 KDSI is the estimated size of the software expressed in Kilo Delivered Source
Instructions
 a, b, c are constants determined by the category of software project
 Effort denotes the total effort required for the software development, expressed in
person months (PMs)
 Tdev denotes the estimated time required to develop the software (expressed in
months)
The value of the constants a, b, c are given below:

Software project a b c
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.20 0.32

Quiz:

1. Assume that the size of an organic type software product has been estimated to be 32,000 lines of
source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine
the effort required to develop the software product and the nominal development time.

Suggested Reference:

1) Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

International Editions
Soft
Software Engineering (3161605)

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 8
AIM: Modeling UML Class Diagrams and Sequence diagrams.

Objectives:

1. Graphically represent a class, and associations among different classes

2. Identify the logical sequence of activities undergoing in a system, and represent them pictorially

 Theory:
Class diagram
It is a graphical representation for describing a system in context of its static construction[1].

Elements in class diagram

Class diagram contains the system classes with its data members, operations and relationships
between classes.
Class
A set of objects containing similar data members and member functions is described by a class. In
UML syntax, class is identified by solid outline rectangle with three compartments which contain

Class name
A class is uniquely identified in a system by its name. A textual string [2]is taken as class name. It
lies in the first compartment in class rectangle.

Attributes
Property shared by all instances of a class. It lies in the second compartment in class rectangle.

Operations
An execution of an action can be performed for any object of a class. It lies in the last compartment
in class rectangle.

Example

To build a structural model for an Educational Organization, „Course‟ can be treated as a class
which contains attributes „courseName‟ & „courseID‟ with
the operations „addCourse()‟ &
„removeCourse()‟ allowed to be performed for any object to that class.
Soft
Software Engineering (3161605)

Generalization/Specialization
It describes how one class is derived from another class. Derived class inherits the properties of its
parent class.

Geometric_Shapes is the class that describes how many sides a particular shape has. Triangle,
Quadrilateral and Pentagon are the classes that inherit the property of the Geometric_Shapes class.
So the relations among these classes are generalization. Now Equilateral_Triangle,
Isosceles_Triangle and Scalene_Triangle, all these three classes inherit the properties of Triangle
class as each one of them has three sides. So, these are specialization of Triangle class.

Relationships
Existing relationships in a system describe legitimate connections between the classes in that
system.

Association
It is an instance level relationship[i] that allows exchanging messages among the objects of both
ends of association. A simple straight line connecting two class boxes represent an association.
Soft
Software Engineering (3161605)

We can give a name to association and also at the both end we may indicate role names and
multiplicity of the adjacent classes. Association may be uni-directional.

Example

In structure model for a system of an organization an employee (instance of „Employee‟ class) is

always assigned to a particular department (instance of „Department‟ class) and the association
can be shown by a line connecting the respective classes.

Aggregation
It is a special form of association which describes a part-whole[i] relationship between a pair of
classes. It means, in a relationship, when a class holds some instances of related class, then that
relationship can be designed as an aggregation.

Example

For a supermarket in a city, each branch runs some of the departments they have. So, the relation
among the classes „Branch‟ and „Department‟ can be designed as an aggregation. In UML, it
can be shown as in the fig. below

Composition [i]
It is a strong from of aggregation which describes that whole is completely owns its part. Life
cycle of the part depends on the whole.

Example
Soft
Software Engineering (3161605)

Let consider a shopping mall has several branches in different locations in a city. The existence
of branches completely depends on the shopping mall as if it is not exist any branch of it will no
longer exists in the city. This relation can be described as composition and can be shown as
below

 Multiplicity
It describes how many numbers of instances of one class is related to the number of instances of
another class in an association.
Notation for different types of multiplicity:

o 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.
o Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.
Soft
Software Engineering (3161605)

o 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.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of
the scope of the system. It represents the role, which involves human users and external
hardware or subjects. An actor may or may not represent a physical entity, but it purely
depicts the role of an entity. Several distinct roles can be played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which
an operation is performed by an element, such that the top and the bottom of the rectangle
is associated with the initiation and the completion time, each respectively.
Soft
Software Engineering (3161605)

Messages

The messages depict the interaction between the objects and are represented by arrows.
They are in the sequential order on the lifeline. The core of the sequence diagram is
formed by messages and lifelines.

Following are types of messages enlisted below:

 Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the corresponding
caller message.

Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.
Soft
Software Engineering (3161605)

Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of the
self message as it represents the recursive calls.

Create Message: It describes a communication, particularly between the lifelines of an

interaction describing that the target (lifeline) has been instantiated.

Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.
Soft
Software Engineering (3161605)

Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

Quiz:

1) In a sequence diagram, what does a box depict? What does a dashed line depict? What does a
arrow between boxes depict?
2) What does a X over a lifeline indicate?

Suggested Reference:

1) Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.

2) Pankaj Jalote, Software Engineering – A Precise Approach Wiley

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 9
AIM: Design the various test cases to perform the testing of the system and also perform the various
type of testing
Objectives: To explore and learn about different testing techniques and use them.

 Theory:
o Software Testing is evaluation of the software against requirements gathered from users
and system specifications. Testing is conducted at the phase level in software
development life cycle or at module level in program code. Software testing comprises of
Validation and Verification.

o Software Validation
 Validation is process of examining whether or not the software satisfies the user
requirements. It is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.

Validation ensures the product under development is as per the user

o
requirements.
o Validation answers the question – "Are we developing the product which
attempts all that user needs from this software ?".
o Validation emphasizes on user requirements.
o Software Verification
 Verification is the process of confirming if the software is meeting the business
requirements, and is developed adhering to the proper specifications and
methodologies.

 Verification ensures the product being developed is according to design

specifications.
 Verification answers the question– "Are we developing this product by firmly
following all design specifications ?"
 Verifications concentrates on the design and system specifications.

o Target of the test are -

 Errors - These are actual coding mistakes made by developers. In addition, there is a
difference in output of software and desired output, is considered as an error.
Soft
Software Engineering (3161605)

 Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an
error which can cause system to fail.
 Failure - failure is said to be the inability of the system to perform the desired task.
Failure occurs when fault exists in the system.

o Testing Levels
 Testing itself may be defined at various levels of SDLC. The testing process
runs parallel to software development. Before jumping on the next stage, a
stage is tested, validated and verified.
 Testing separately is done just to make sure that there are no hidden bugs or
issues left in the software. Software is tested on various levels -
o Unit Testing

While coding, the programmer performs some tests on that unit of program to
know if it is error free. Testing is performed under white-box testing approach. Unit
testing helps developers decide that individual units of the program are working as
per requirement and are error free.

o Integration Testing

Even if the units of software are working fine individually, there is a need to find
out if the units if integrated together would also work without errors. For example,
argument passing and data updation etc.

o System Testing
The software is compiled as product and then it is tested as a whole.

 Background / Preparation:
o Test management tool
o Test management tools are used to keep track of all the testing activity, fast data
analysis, manage manual and automation test cases, various environments, and
plan and maintain manual testing as well.
o Test management tools are used to keep track of all the testing activity, fast data analysis,
manage manual and automation test cases, various environments, and plan and maintain
manual testing as well.
o The test management tool is connected with the automation software. These types of
tools had various strategies for testing and multiple sets of features. Some of the test
management tools had capabilities to design the test case with the help of requirements.
Soft
Software Engineering (3161605)

o It is best for test managing, scheduling, defect logging, tracking, and analysis.
o Some of the most commonly used test management tools are as follows:
o Quality center
o RTH
o Testpad
o Test Monitor
o PractiTest

 Tools / Material Needed:

o Hardware:
o Software:

o Test Cases:
 The test case is defined as a group of conditions under which a tester determines
whether a software application is working as per the customer's requirements or
not. Test case designing includes preconditions, case name, input conditions, and
expected result. A test case is a first level action and derived from test scenarios.

o Test case template

o The primary purpose of writing a test case is to achieve the efficiency of the
application.

Test Test Test Steps Expected Actual Pass/Fail

case Scenario Results Results
ID

1
2

Example
Test Test Test Steps Expected Actual Pass/Fail
Case Scenario Results Results
ID

TU01 Check 1. Go to User As Pass

Customer should Expected
site http://demo.guru99.c
Login with Login into
om
application
Soft
Software Engineering (3161605)

valid Data 2. Enter UserId

3. Enter Password
4. Click Submit

TU02 Check 1. Go to User As Pass

Customer should not Expected
site http://demo.guru99.c
Login with Login into
om
invalid Data application
2. Enter UserId
3. Enter Password
4. Click Submit

Quiz:

1 What elements of the WebApp can be “unit tested”? What types of tests must be conducted only
after the WebApp elements are integrated?
2 What is white box testing? What are the different coverage based testing strategies.
3 What is black box testing?

Suggested Reference:
1 Software Testing: A Craftsman's Approach, by Paul C. Jorgensen, Third Edition
2 Software Engineering by Rajib Mall, PHI 2014

References used by the students:

Soft
Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 10
AIM: Study of Open-source tools in DevOps for Infrastructure Automation, Configuration
Management, Deployment Automation, Performance Management, Log Management. Monitoring

 Objectives: to learn how DevOps tools works.

 Theory:

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization‟s
ability to deliver applications and services at high velocity: evolving and improving products at a faster
pace than organizations using traditional software development and infrastructure management
processes. This speed enables organizations to better serve their customers and compete more effectively
in the market.

How DevOps Works

Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these
two teams are merged into a single team where the engineers work across the entire application
lifecycle, from development and test to deployment to operations, and develop a range of skills not
limited to a single function.

In some DevOps models, quality assurance and security teams may also become more tightly integrated
with development and operations and throughout the application lifecycle. When security is the focus of
everyone on a DevOps team, this is sometimes referred to as DevSecOps.

These teams use practices to automate processes that historically have been manual and slow. They use
a technology stack and tooling which help them operate and evolve applications quickly and reliably.
These tools also help engineers independently accomplish tasks (for example, deploying code or
Soft
Software Engineering (3161605)

provisioning infrastructure) that normally would have required help from other teams, and this further
increases a team‟s velocity.

Why DevOps Matters

Software and the Internet have transformed the world and its industries, from shopping to entertainment
to banking. Software no longer merely supports a business; rather it becomes an integral component of
every part of a business. Companies interact with their customers through software delivered as online
services or applications and on all sorts of devices. They also use software to increase operational
efficiencies by transforming every part of the value chain, such as logistics, communications, and
operations. In a similar way that physical goods companies transformed how they design, build, and
deliver products using industrial automation throughout the 20th century, companies in today‟s world
must transform how they build and deliver software.

DevOps Practices

Continuous Integration
Continuous integration is a software development practice where developers regularly merge their code
changes into a central repository, after which automated builds and tests are run. The key goals of
continuous integration are to find and address bugs quicker, improve software quality, and reduce the
time it takes to validate and release new software updates.

Continuous Delivery
Continuous delivery is a software development practice where code changes are automatically built,
tested, and prepared for a release to production. It expands upon continuous integration by deploying all
code changes to a testing environment and/or a production environment after the build stage. When
continuous delivery is implemented properly, developers will always have a deployment-ready build
artifact that has passed through a standardized test process.

Microservices
The microservices architecture is a design approach to build a single application as a set of small
services. Each service runs in its own process and communicates with other services through a well-
defined interface using a lightweight mechanism, typically an HTTP-based application programming
interface (API). Microservices are built around business capabilities; each service is scoped to a single
purpose. You can use different frameworks or programming languages to write microservices and
deploy them independently, as a single service, or as a group of services.
Soft
Software Engineering (3161605)

Infrastructure as Code
Infrastructure as code is a practice in which infrastructure is provisioned and managed using code and
software development techniques, such as version control and continuous integration. The cloud‟s API-
driven model enables developers and system administrators to interact with infrastructure
programmatically, and at scale, instead of needing to manually set up and configure resources. Thus,
engineers can interface with infrastructure using code-based tools and treat infrastructure in a manner
similar to how they treat application code. Because they are defined by code, infrastructure and servers
can quickly be deployed using standardized patterns, updated with the latest patches and versions, or
duplicated in repeatable ways.

Configuration Management
Developers and system administrators use code to automate operating system and host configuration,
operational tasks, and more. The use of code makes configuration changes repeatable and standardized.
It frees developers and systems administrators from manually configuring operating systems, system
applications, or server software.

Policy as Code
With infrastructure and its configuration codified with the cloud, organizations can monitor and enforce
compliance dynamically and at scale. Infrastructure that is described by code can thus be tracked,
validated, and reconfigured in an automated way. This makes it easier for organizations to govern
changes over resources and ensure that security measures are properly enforced in a distributed manner
(e.g. information security or compliance with PCI-DSS or HIPAA). This allows teams within an
organization to move at higher velocity since non-compliant resources can be automatically flagged for
further investigation or even automatically brought back into compliance.

Monitoring and Logging

Organizations monitor metrics and logs to see how application and infrastructure performance impacts
the experience of their product‟s end user. By capturing, categorizing, and then analyzing data and logs
generated by applications and infrastructure, organizations understand how changes or updates impact
users, shedding insights into the root causes of problems or unexpected changes. Active monitoring
becomes increasingly important as services must be available 24/7 and as application and infrastructure
update frequency increases. Creating alerts or performing real-time analysis of this data also helps
organizations more proactively monitor their services.

Communication and Collaboration

Increased communication and collaboration in an organization is one of the key cultural aspects of
DevOps. The use of DevOps tooling and automation of the software delivery process establishes
collaboration by physically bringing together the workflows and responsibilities of development and
operations. Building on top of that, these teams set strong cultural norms around information sharing and
facilitating communication through the use of chat applications, issue or project tracking systems, and
Soft
Software Engineering (3161605)

wikis. This helps speed up communication across developers, operations, and even other teams like
marketing or sales, allowing all parts of the organization to align more closely on goals and projects.

DevOps Tools
The DevOps model relies on effective tooling to help teams rapidly and reliably deploy and innovate for
their customers. These tools automate manual tasks, help teams manage complex environments at scale,
and keep engineers in control of the high velocity that is enabled by DevOps. AWS provides services
that are designed for DevOps and that are built first for use with the AWS cloud. These services help
you use the DevOps practices described above.

+Quiz:
1 What are the challenges with DevOps implementation?
2 What is DevOps? How it works? What are the DevOps principles & best practices?
3 Explain 7Cs of DevOps lifecycle.

Suggested Reference:

1 Deepak Gaikwad, Viral Thakkar, DevOps Tools from Practitioner‟s ViewPoint, Wiley.
2 The DevOps Handbook - Gene Kim et. al.
References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty: