Software Engineering

A Laboratory Manual for
SOFTWARE ENGINEERING
(3161605)
B.E. Semester 6 (Information Technology)
Directorate of Technical Education, Gandhinagar,

Gujarat.
1
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
2
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.
3
210160116086 Batch(B1)
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.
4
210160116086 Batch(B1)
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
5
210160116086 Batch(B1)
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.
6
210160116086 Batch(B1)
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
7
210160116086 Batch(B1)
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.
8
210160116086 Batch(B1)
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.
9
210160116086 Batch(B1)
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.
10
210160116086 Batch(B1)
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 :
11
210160116086 Batch(B1)
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
12
210160116086 Batch(B1)
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.
13
210160116086 Batch(B1)
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
14
210160116086 Batch(B1)
1. Compare waterfall model and incremental model.
15
210160116086 Batch(B1)
2. 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.
b. The loops for spiral model are fixed.
3. Write the reasons to justify which life model you going to use to develop the software in the
project.
16
210160116086 Batch(B1)
17
210160116086 Batch(B1)
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:

https://www.tutorialspoint.com/sdlc/index.htm
https://www.javatpoint.com/software-engineering-prototype-model
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:
18
210160116086 Batch(B1)
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.

 Research and Planning:
o Define project objectives
o Analyze existing solutions
o Identify stakeholders and their requirements
o Create a project scope
o Determine timeline and milestones
 Blockchain Technology Integration:

o Set up a blockchain network
o Design smart contracts
o Integrate barcode-based authentication
o Ensure data compatibility with blockchain
o Test blockchain functionality
 Barcode Generation and Assignment:

o Design a barcode generation system
o Create a unique identifier for each product
o Implement barcode assignment to individual products
o Test the barcode system
 Product Information Management:

o Design a product information database
o Implement data fields for manufacturer, production date, etc.
o Integrate the database with the barcode system
o Test product information management
 User Interface and Experience Design:

o Design a user-friendly interface
o Implement barcode scanning functionality
19
210160116086 Batch(B1)
o Ensure accurate product authentication

o Test the user interface
 Testing and Quality Assurance:

o Perform functional testing
o Test for counterfeit detection
o Validate accuracy of product information
o Ensure system security and performance
 Deployment and Maintenance:

o Prepare the system for production
o Deploy the system
o Perform post-deployment testing
o Schedule regular maintenance and updates
2. Break down large tasks into small activities.

 Research and Planning:
o Define project objectives

o Identify the primary goals of the project
o Establish the project's purpose
o Analyze existing solutions
o Investigate available technologies
o Review competitor offerings
o Identify stakeholders and their requirements
o Identify all parties involved
o Gather their expectations and needs
o Create a project scope
o Define the project's boundaries
o Specify deliverables and exclusions
o Determine timeline and milestones
o Establish a project schedule
o Define key milestones and deadlines
 Blockchain Technology Integration:
o Set up a blockchain network

o Choose a suitable blockchain platform
o Configure the network
o Design smart contracts
o Define the contract logic
o Implement the smart contracts
o Integrate barcode-based authentication
o Connect barcode system to the blockchain
o Ensure compatibility
o Ensure data compatibility with blockchain
o Define data formats and structures
o Implement data conversion if necessary
o Test blockchain functionality
o Validate smart contracts
o Test network performance
20
210160116086 Batch(B1)
 Barcode Generation and Assignment:
o Design a barcode generation system

o Choose a barcode format (QR, Code 128, etc.)
o Define the barcode layout
o Create a unique identifier for each product
o Implement a unique identifier generation algorithm
o Assign unique identifiers to each product
o Implement barcode assignment to individual products
o Integrate barcode generation with product database
o Assign barcodes during production or packaging
o Test the barcode system
o Validate barcode scanning
o Ensure accurate identifier retrieval
 Product Information Management:
o Design a product information database

o Choose a database technology
o Define the database schema
o Implement data fields for manufacturer, production date, etc.
o Define required data fields
o Implement data input forms
o Integrate the database with the barcode system
o Connect the barcode system to the product database
o Ensure seamless data exchange
o Test product information management
o Validate data input and retrieval
o Test data compatibility with the blockchain
 User Interface and Experience Design:
o Design a user-friendly interface

o Choose a design approach (mobile app, web app, etc.)
o Define the user interface layout
o Implement barcode scanning functionality
o Integrate a barcode scanning library
o Test scanning performance
o Ensure accurate product authentication
o Validate barcode-product matching
o Test counterfeit detection
o Test the user interface
o Validate user experience
o Perform usability testing
 Testing and Quality Assurance:
o Perform functional testing

o Validate core features
o Test edge cases
o Test for counterfeit detection
21
210160116086 Batch(B1)
o Create test scenarios for counterfeit products

o Ensure accurate detection
o Validate accuracy of product information
o Test data retrieval
o Ensure accurate information display
o Ensure system security and performance
o Test for vulnerabilities
o Monitor system performance
o Prepare the system for production

o Optimize performance
o Conduct final testing
o Deploy the system
o Release the system to the public
o Announce availability
o Perform post-deployment testing
o Validate system functionality
o Monitor user feedback
o Schedule regular maintenance and updates
o Plan for periodic updates
o Schedule regular system maintenance
3. Determine the dependency among different activities.

Research and Planning: Before starting the development, thorough research and planning are necessary to
understand the requirements, existing solutions, and the overall scope of the project. This activity
depends on the initial concept and the problem it aims to solve.
Blockchain Technology Integration: This involves setting up the blockchain infrastructure, defining the
smart contracts, and integrating the necessary components to support barcode-based product
authentication. This activity depends on the research and planning phase.
Barcode Generation and Assignment: Developing a system for generating unique barcodes and assigning
them to individual products is a critical activity. This depends on the blockchain integration as the
barcode data needs to be compatible with the blockchain system.
Product Information Management: This involves creating a system for managing product information,
including details such as manufacturer, production date, and other relevant data. This activity depends on
the barcode generation and assignment as well as the blockchain integration.
User Interface and Experience Design: This activity focuses on creating an intuitive and user-friendly
interface for customers to scan barcodes and verify product authenticity. This depends on the blockchain
and product information management systems.
Testing and Quality Assurance: Rigorous testing is required to ensure that the system functions correctly,
detects counterfeit products, and provides accurate information. This activity depends on all the previous
phases.
Deployment and Maintenance: After successful testing, the system can be deployed and made available to
the public. Regular maintenance and updates are necessary to keep the system secure and efficient. This
22
210160116086 Batch(B1)
depends on the feedback and data collected during the system's usage.
4. Establish the most likely estimates for the time durations necessary to complete the activities.
 Research and Planning: 1-2 weeks. This phase involves understanding the problem, analyzing existing
solutions, and defining the scope of the project.
 Blockchain Technology Integration: 3-4 weeks. This phase includes setting up the blockchain
infrastructure, defining smart contracts, and integrating necessary components for barcode-based product
authentication.
 Barcode Generation and Assignment: 2-3 weeks. This phase focuses on creating a system for generating
unique barcodes and assigning them to individual products.
 Product Information Management: 2-3 weeks. This phase involves managing product information,
including details such as manufacturer, production date, and other relevant data.
 User Interface and Experience Design: 2-3 weeks. This phase focuses on designing an intuitive and user-
friendly interface for customers to scan barcodes and verify product authenticity.
 Testing and Quality Assurance: 2-3 weeks. This phase involves rigorous testing to ensure that the system
functions correctly, detects counterfeit products, and provides accurate information.
 Deployment and Maintenance: 1-2 weeks for deployment, followed by ongoing maintenance as needed.
5. Allocate resources to activities.

Research and Planning:
o Project Manager: 1 FTE (Full-Time Equivalent)
o Business Analyst: 0.5 FTE
o Stakeholder Representatives: Varies
Blockchain Technology Integration:

o Blockchain Developer: 1 FTE
o Smart Contract Developer: 0.5 FTE
o QA Engineer: 0.5 FTE
Barcode Generation and Assignment:

o Backend Developer: 0.5 FTE
Product Information Management:

o Backend Developer: 0.5 FTE
o Database Administrator: 0.5 FTE
User Interface and Experience Design:

o UI/UX Designer: 0.5 FTE
o Frontend Developer: 0.5 FTE
23
210160116086 Batch(B1)
Testing and Quality Assurance:

o QA Engineer: 1 FTE
o Security Analyst: 0.5 FTE

o DevOps Engineer: 0.5 FTE
• Additionally, the project may require other resources such as:

o Hardware and infrastructure for development, testing, and production
o Software licenses and subscriptions for development tools, libraries, and platforms
o Third-party services for barcode generation, blockchain network, and other functionalities
o Project management tools for tracking progress and collaboration
6. Plan the starting and ending dates for various activities.

 Sprint 1:
o Research and planning for the project.
o Define the scope and objectives of the project.
o Determine the technology stack and tools needed for the project.
o Design the system architecture and user interface.
Sprint 2:
o Implement the barcode scanning feature.
o Integrate the barcode scanning with the blockchain system.
o Test the system for usability and user experience.
Sprint 3:
o Develop the smart contracts for the blockchain system.
o Test the smart contracts for security vulnerabilities.
o Implement user authentication and authorization.
Sprint 4:
o Develop the database schema and data model.
o Implement data validation and input sanitization.
o Integrate the blockchain system with the database.
Sprint 5:
o Implement the fake product detection feature.
o Test the system for accuracy and reliability.
o Perform user acceptance testing.
Sprint 6:
o Develop the admin module for managing the system.
o Test the system for administrative tasks.
o Prepare the project documentation.
Sprint 7:
o Conduct a final review and quality assurance.
24
210160116086 Batch(B1)
o Demonstrate the system to stakeholders.

o Deploy the system to a production environment.
Sprint 8 :
o Monitor the system for any issues.
o Provide user support and maintenance.
7. Determine the critical path.

Task Description Duration(Days) Predecessor Task Dependency
Define Blockchain 5 - -
Platform
Design Database 3 A A completed
Schema
Develop Smart Contract 7 B B completed
Integrate Barcode 5 B B completed

Scanning App
Test & Debug 7 C,D Both C,D completed
Blockchain System
Deploy System & Train 3 E E completed
Users
Critical Path: A -> B -> C -> E -> F (Total Duration: 25 days)
Explanation:
1. Define Blockchain Platform (A): This is the initial step, independent of other tasks.
2. Design Database Schema (B): This relies on the chosen blockchain platform (A).
3. Develop Smart Contract (C): This requires the database schema (B) design to be finalized.
4. Integrate Barcode Scanning App (D): This also requires the database schema (B) design.
5. Test & Debug Blockchain System (E): This depends on both the smart contract (C) and app integration
(D) being complete.
6. Deploy System & Train Users (F): This is the final step and depends on a fully functional and tested
system (E).
Critical path: The tasks that lie on the critical path have no slack (buffer time) and any delay in these tasks
will directly impact the overall project timeline. In this case, the critical path is A -> B -> C -> E -> F, leading
to a total project duration of 25 days.
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.
25
210160116086 Batch(B1)
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.
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.
Quiz:
1) Explain project scheduling process.
26
210160116086 Batch(B1)
2) Explain Software metrics used for software cost estimation
27
210160116086 Batch(B1)

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

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked
Development of Development of Development of

the Solution the Solution the Solution
Concept Clarity Concept Clarity

& understanding & understanding
Correct answer to
all questions
28
210160116086 Batch(B1)
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.
Procedure to develop SRS:

Every team has to identify the requirements of their projects and arrange as per the requirement
engineering document.
In order to form a good SRS, here you will see some points which can be used and should be considered
to form a structure of good SRS. These are as follows:
1. Introduction
• Purpose of this document
• Scope of this document
• Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
29
210160116086 Batch(B1)
SOFTWARE REQUIREMNT
SPECIFICATION FOR
“IDENTIFYING FAKE
PRODUCT USING
BARCODE BASED
BLOCKCHAIN
SYSTEM”
Authors
Raval Jigarkumar Rameshkumar
Raval Jayeshkumar Dineshkumar
Department of Information and Technology,

Government Engineering College, Modasa
Guided by,
Prof Nilesh Goriya ,
Assistant Professor,
Department of Computer Engineering,
Government Engineering College, Modasa
Date:
Version: 1.0
30
210160116086 Batch(B1)
TABLE OF CONTENTS
1. Introduction…………………………………………………………………..
 Purpose of this document
 Scope of this document
 Overview
2. General description…………………………………………………………..
3. Functional Requirements…………………………………………………….
4. Interface Requirements………………………………………………………
5. Performance Requirements…………………………………………………..
6. Design Constraints……………………………………………………………
6. Non-Functional Attributes………………………………................................
31
210160116086 Batch(B1)
1. Introduction
 Purpose of this document

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.
 Scope of this document

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.
 Overview
A barcode-based blockchain system is a way of identifying fake products by using a unique
QR code that is linked to a secure and transparent database. The system works as follows:
The manufacturer creates a product and assigns a QR code to it, which contains information
such as the product serial id, date of manufacture, origin of the product, expiry date, etc.
The manufacturer uploads the QR code and the product information to a blockchain database,
which is a distributed ledger that records transactions in a verifiable and immutable way.
The product is then shipped to the seller, who can verify the authenticity of the product by
scanning the QR code and checking the blockchain database.
32
210160116086 Batch(B1)
The customer can also scan the QR code and check the blockchain database to see if the
product is genuine or fake, and also get the product history and details.
The benefits of using a barcode-based blockchain system are:
It provides security and transparency to the consumers, who can access authentic and reliable
data about the products they buy.
It prevents the production and distribution of counterfeit products, which can harm the
consumers and the legitimate businesses.
It enhances the quality control and sustainability of the products, as the manufacturers and
sellers can track and monitor the product’s condition and origin.
2. General description
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.
Project Function:
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.
33
210160116086 Batch(B1)
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.
34
210160116086 Batch(B1)
3. Functional Requirements
R.1: User Management
Description User registration and login for guests, and administrators.
R.1.1: User registration
Input Username, password, email address
Output New user account is created, user receives confirmation email
R.1.2: User Login
Input Username, password
Output User is logged in and redirected to the appropriate dashboard (e.g., consumer,
manufacturer)
R.1.3: Forgot Password
Input Email address
Output Password reset link is sent to the user’s email
R.2: Product Registration

Description User’s trip status. Selection of Destination place, dates, and members etc.
R.2.1: Product Information Entry
Input Manufacture enters product details(name , description, category, image, etc.)
Output Product information is validated and stored in the system

R2.2: Unique Identifier Generation
Input System automatically generates a unique identifier (e.g., serial number)
Output Unique identifier is linked to the product information
R2.3: QR Code Generation
Input Unique identifier
Output System generates a unique QR code linked to the product information
R.3: Product Verification

Description System will provide the weather forecasts and local attractions/event information for the
tourists.
R3.1: Barcode Scanning
Input User scans the product's barcode using a mobile app
Output App extracts the encoded data (unique identifier) from the barcode
R.3.2: Blockchain Query

Input App sends the extracted unique identifier to the blockchain network
Output System retrieves product information associated with the identifier from the blockchain
R3.3: Product Information Display
Input Retrieved product information
Output App displays the product information (e.g., name, manufacturer, description, image) to
the user
35
210160116086 Batch(B1)
R.4: Fake Product Reporting

Description System will send Notification to the users regarding destination to visit, offers, checking
weather updates, reservation updates etc.
R.4.1: Report Submission
Input User submits a report indicating suspicion of a fake product
Output System stores the report and sends a notification to the administrator
R.4.2: Report Details
Input User provides information about the suspected fake product (e.g., discrepancies with
displayed information, packaging differences)
Output: System stores the additional details with the report
R.5: Administrator Features

Description System will provide the weather forecasts and local attractions/event information for the
tourists.
R5.1: Report Management
Input Administrator views a list of submitted reports
Output Administrator can access detailed information about each report, mark reports as
investigated, and take appropriate actions (e.g., removing suspicious products from the
system)
R5.2: User Management
Input Administrator views a list of users
Output Administrator can manage user accounts (e.g., view user activity, suspend accounts)
R5.3: System Monitoring
Input Administrator accesses system logs and metrics
Output Administrator can monitor system health, identify potential issues, and manage system
settings
36
210160116086 Batch(B1)
4. Interface Requirements:
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.
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.
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.
37
210160116086 Batch(B1)
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.
Security Interfaces:
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.
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.
38
210160116086 Batch(B1)
Business Rules:
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.
5. Performance Requirements
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.
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.
6. Design Constraints:
39
210160116086 Batch(B1)
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.
7. Non-Functional Attributes
Performance:
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.
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.
40
210160116086 Batch(B1)
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.
Documentation and Training:

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.
Security:
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.
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.
Availability:
The system should be available for use at all times. This is crucial as users may need to verify
41
210160116086 Batch(B1)
product authenticity at any time.
Reliability:
The system should operate reliably under all conditions. This is crucial to ensure users can trust
the system to verify product authenticity.
42
210160116086 Batch(B1)
Quiz:
1. Which are properties of good SRS?
2. What is functional and non-functional requirement?
43
210160116086 Batch(B1)

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




Correct answer to
all questions
44
210160116086 Batch(B1)
Signature of Faculty
45
210160116086 Batch(B1)
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
46
210160116086 Batch(B1)
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
Level 0:
 1-level DFD: It represents the main functions of the system and how they interact with each
47
210160116086 Batch(B1)
other.
Level 1:
 2-level DFD: It represents the processes within each function of the system and how they interact
with each other.
Level 2:
 Tools / Material Needed:

o Hardware:
o Software:
48
210160116086 Batch(B1)
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?
49
210160116086 Batch(B1)
1. Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

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



Correct answer to
all questions
Signature of the Faculty
50
210160116086 Batch(B1)
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.
51
210160116086 Batch(B1)
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.
52
210160116086 Batch(B1)
53
Soft
Software Engineering (3161605)
Quiz:
1. what is weak entityset?
54
Soft
2. what is mapping cardinality?
55
Soft



Correct answer to
all questions
56
Soft
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.
57
Soft
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.
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;
58
Soft
A description of the state when the scenario finishes.

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?
1. Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

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.
59
Soft



Correct answer to
all questions
60
Soft
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.
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.
61
Soft
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
Assumptions:
 Size estimation: Estimated size of the project is 5000 lines of code (LOC).
 Mode selection: Organic mode is chosen as the project is relatively small and
straightforward.
 Productivity: Assume a productivity factor of 20 person-months per KLOC (thousand
lines of code).
 Team Size: Assume a team size of 2 developers.
 Scheduling: Assume a standard schedule with no specific constraints.
Solution:
1. Determine Size
 Estimated size of the project = 5000 LOC
2. Select Mode:
 Since the size of the project is relatively small and the requirements are clear,
we'll choose the Organic mode.
3. Calculate Effort:
 Effort = 2.4 * (LOC)^1.05 for Organic mode (where LOC is in KLOC)
 Effort = 2.4 * (5)^1.05 = 5.4 person-months
62
Soft
4. Calculate Duration:
 Duration = Effort / Team Size
 Duration = 5.4 person-months / 2 developers = 2.7 months
COCOMO divides effort and time as follows

17% Requirements Analysis
25% Design
25% Coding and Unit Testing
33% Integration and Testing
If it is adapted to Airline Reservation System the following table occurs;
 Estimation Plan
In this part of the Initial Plan, the cost and schedule for conducting the project as well as
methods, tools and techniques used to estimate project cost, schedule and resource requirements
are specified.
Since it is a convenient method to use in the early phases of project development, the size of the Online Airline
Reservation System is estimated according to the function-point (FP) method [8]. In counting function points,
external inputs, external outputs, external enquiries, internal files and external interfaces of the software are
identified. Each instance for each separate class is multiplied with the associated weight factor. The overall sum
is calculated to find the function points. Weights for simple, average and complex inputs, outputs, enquires, files
and external interfaces, which are used in calculations, are depicted below:
Simple Average Complex

External input 3 4 6
External output 4 5 7
External enquiry 3 4 6
Internal file 7 10 15
External interface 5 7 10
Table 4: Complexity Factors Used in Function Point Calculation
In order to systematically find complexity levels, references to file accesses, record type accesses and data
elements are counted and complexity scores are determined accordingly. The table below depicts the factors
used for complexity calculation. For example, an external input that reference four files and nine data types (3 +
2) is considered ‘complex’. (2 - 3 simple -denoted by the letter ‘S’, 4 average -denoted by the letter ‘A’, 5- 6
complex -denoted by the letter ‘C’)
63
Soft
EXTERNAL INPUTS Files Rec. Data Elements Comp. Score

Types
Ask personal question Personal file - User id S 3
Define new user User - User id Password S 3
authentication file Name of User
User information
Select language Language
file file - Language id S 3
Ask another question Questions file - Question id S 3

Select FAQs Frequently asked - FAQ id S 3
OR questions files
Select from Menu Menu file - Menu id S 3
Enter an input Entered input file - Input id S 3
Ask for barcode scanner Barcode file - Scanner id S 3

Select from Menu User menu file - Menu id S 3
EXTERNAL OUTPUTS
Login successful message None - Message text S 4
Login failed message None - Message text S 4
Problem fetched None - Message text S 4
Couldn’t fetch the None - Message text S 4

problem
Successfully found the None - Message text S 4
solution
Check the threshold level None - Message text S 4
Go for professional help None - Message text S 4
Problem fetched from None - Message text S 4

FAQs
Problem from FAQs
64
Soft
Successfully found the None - Message text S 4
solution
Check the threshold level None - Message text S 4
Suggest for professional None - Message text S 4

help
Failed to help user None - Message text S 4
Problem fetched None - Message text S 4

from manual entry
problem
Successfully found None - Message text S 4
the solution
Check the None - Message text S 4
threshold level
Successfully helped the user None - Message text S 4
INTERNAL FILES
User authentication file - None User id S 7
Password
User informaertion file - None User id S 7
Question file - None Question id S 7
Threshold file - None Threshold id S 7
User Menu file - None Menu id S 7
Solution file - None Solution id S 7
Multiple language file - None Language id S 7
EXTERNAL ENQUIRIES
None - - - - -
EXTERNAL INTERFACES
APIs - - - - -
TOTAL UNADJUSTED FUNCTION POINTS 226
Table 6: Details of the Function Point Calculation
65
Soft
Influence Factors Degree of Comment

Influence-DI
Data Communication 5 Distributed environment
Interaction Function 1 Client-server architecture
Threshold Function 5 Online threshold checking
Barcode Scanner Function 5 Take data from datbase
On-line Update Function 0 No special requirements
Manually enter Function 4 Enter your product name
Reusability Function 0 No special requirements
Installation Ease Function 0 No special requirements
Operational Ease Function 3 No special requirements
Multiple Language Function 5 Select your language
Sum of Degree of Influence = 28
Table 7: Influence Factors of Online Airline Reservation System
Phase Month-1 Month-2 Month-3 TOTAL

Requirements
75% 25% 0% 100%
Analysis
Design 25% 50% 25% 100%
Coding & Unit Testing
0% 50% 50% 100%
Integration & Testing
0% 25% 75% 100%
66
Soft
Table 8: Effort and Time Division
Effort Month-1 Month-2 Month-3

Phase
(staff * months) (staff * months) (staff * months) (staff * months)
Requirements
0.17 * 2.7 = 0.459 0.8 * 0.75 = 0.6 0.8 * 0.25 = 0.2 0.8 * 0 = 0
Analysis (17%)
1.18 0.50 = 0.58 1.18 * 0 25 = 0.29
Design (25%) 0.25 * 2.7 = 0.675 1.18 * 0 25 = 0.29
*
Coding & Unit 1.18 0.50 = 0.58 1.18 * 0 25 = 0.29
Testing (25%) 0.25 * 2.7 = 0.665 1.18 * 0 25 = 0.29 *
Integration & Testing 1.55 0.25 = 1.55 * 0.75 =1.16

(33%) 0.33 * 2.7 = 0.891 1.55* 0 = 0 *
0.38
TOTAL EFFORT 2.68 1.17 1.77 1.77
(staff * months)
Month-1 Month-2 Month-3 TOTAL

1.17 * 5000 = 5850 1.77 * 5000 = 8850 1.77 * 5000 = 8850
Cost of the staff ($) 23550
Cost of the
subcontracted 64 * 10 = 640 64 * 10 = 640 64 * 10 = 640 1920
processes ($)
Cost of the
electricity consumed 30 30 30 90
($)
TOTAL 6520 9520 9520 25560
COST ($)
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.
67
Soft
1) Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

68
Soft




questions
69
Soft
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.
70
Soft
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.
71
Soft
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
72
Soft
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.
73
Soft
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.
74
Soft
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.
75
Soft
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.
76
Soft
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?
1) Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.
2) Pankaj Jalote, Software Engineering – A Precise Approach Wiley




questions
77
Soft
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.
78
Soft
 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.
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.
79
Soft
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

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
80
Soft
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?
1 Software Testing: A Craftsman's Approach, by Paul C. Jorgensen, Third Edition
2 Software Engineering by Rajib Mall, PHI 2014
81
Soft



Correct answer to
all questions
82
Soft
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
83
Soft
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.
84
Soft
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
85
Soft
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.
1 Deepak Gaikwad, Viral Thakkar, DevOps Tools from Practitioner‟s ViewPoint, Wiley.
2 The DevOps Handbook - Gene Kim et. al.




questions
86

Software Engineering

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Software Engineering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

A Laboratory Manual for

B.E. Semester 6 (Information Technology)

Directorate of Technical Education, Gandhinagar,

This is to certify that Mr./Ms.

Name and Sign of Faculty member

Head of the Department

Practical – Course Outcome matrix

Course Outcomes (COs):

Discuss the Project Management: Project Planning and

Draw the Entity-Relationship Diagram for your selected

8. Modeling UML Class Diagrams and Sequence diagrams √ √

Industry Relevant Skills

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

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

Guidelines for Faculty members

Instructions for Students

included in scope of manual.

General Guidelines for Software Engineering Laboratory Work

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

List of Different Process Models

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

The Incremental Model is used in the following scenarios:

Figure 4: RAD Model

The various phases of RAD are as follows:

Phases of Agile Model:

Agile Testing Methods:

When to use the Agile Model?

Figure 6:Iterative Model

The various phases of Iterative model are as follows:

Figure 7:Spiral Model

Each cycle in the spiral is divided into four parts:

Steps of Prototype Model

 Requirement Gathering and Analyst

1. Compare waterfall model and incremental model.

b. The loops for spiral model are fixed.

References used by the students:

Rubric wise marks obtained:

Marks Complete Complete Complete Complete Complete

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Concept Clarity & Concept Clarity &

Correct answer to all

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

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

 Blockchain Technology Integration:

 Barcode Generation and Assignment:

 Product Information Management:

 User Interface and Experience Design:

o Ensure accurate product authentication

 Testing and Quality Assurance:

 Deployment and Maintenance:

2. Break down large tasks into small activities.

o Define project objectives

 Blockchain Technology Integration:

o Set up a blockchain network

 Barcode Generation and Assignment:

o Design a barcode generation system