A Laboratory Manual for

SOFTWARE ENGINEERING
(3161605)

B.E. Semester 6 (Information Technology)

Directorate of Technical Education, Gandhinagar,

Gujarat.
 Government Engineering College, Modasa
Certificate

This is to certify that Mr./Ms. ___________________________________

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

Place: __________________

Date: __________________

Name and Sign of Faculty member

Head of the Department

 Preface

The main motto of any laboratory/practical/field work is to enhance required skills and create
ability amongst students to solve real-time problems by developing relevant competencies in the
psychomotor domain. By keeping this in view, GTU has designed a competency-focused
outcomebased 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.

Practical – Course Outcome matrix

Software Engineering(3161605)
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. CO CO CO
No. Objective(s) of Experiment CO1 CO5
2 3 4
Study of various type of Software Process models
with comparison and find out which process model
1. √
will be 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
9. √ √
the system and also perform the various type of testing.
Study of any two Open source tools in DevOps for
1 Infrastructure Automation, Configuration Management √
0. Deployment Automation, Performance Management,
Log Management Monitoring.

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.
Software Engineering(3161605)
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 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.
Software Engineering(3161605)
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.

Index
(Progressive Assessment Sheet)
Sr. Objective(s) of Experiment Page Date Date Assessm Sign. Rem
No. No. of of en of ar
perfor submi t Teache ks
m ss ion Marks r with
ance date
Software Engineering(3161605)
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.
1 Study of any two Open source tools in
0. DevOps for Infrastructure Automation,
Configuration Management ,Deployment
Automation, Performance Management,
Log Management Monitoring.
Total

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.
Software Engineering(3161605)
Date:

• 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

• Waterfall model.
• V model.
• Incremental model.
• RAD model.
• Agile model.
• Iterative model.
• Spiral model.
• Prototype model.
• Agile model

➔ For your Face Detection & Recognition project, the Spiral Model is the most
suitable process model. Here's why:
❖ Why Choose the Spiral Model?
- The Spiral Model is ideal because your project involves:

✅ Complex AI Model Development:

● Face detection and recognition systems require continuous improvement in accuracy, precision, and
performance.
● The Spiral Model’s iterative nature supports multiple testing and refinement phases, which is crucial for
deep learning models.

✅ Uncertain Requirements:

● Since face detection systems often involve experimenting with different machine learning models, image
preprocessing techniques, and performance optimization strategies, the flexibility of the Spiral Model helps
adapt to changing requirements.

✅ Risk Management:
● The Spiral Model emphasizes early risk assessment. For your project, risks like false detections, data
privacy concerns, and model overfitting can be identified and mitigated early in development.

✅ Incremental Development:

● The Spiral Model enables you to build and test features in phases. For instance:
○ Phase 1: Develop basic face detection functionality.
○ Phase 2: Integrate face recognition with database lookup.
○ Phase 3: Improve accuracy, performance, and scalability.

✅ Customer Feedback Integration:

Software Engineering(3161605)
● Since your project involves real-time user interactions (e.g., mobile camera integration, gRPC server
communication), continuous feedback will help refine the system effectively.

🚀 Step-by-Step Spiral Model in Your Project

1. Planning Phase:

● Identify system requirements like face recognition accuracy, database structure, etc.
● Define milestones like embedding database setup, API creation, and mobile camera integration.

2. Risk Analysis Phase:

● Identify risks such as:

○ Model failing in low-light conditions.
○ Misclassification due to variations in facial angles.
● Plan mitigation strategies like improving dataset quality or adding error-handling mechanisms.

3. Engineering Phase:

● Develop core modules:

○ Face detection with MTCNN.
○ Face recognition using FaceNet512.
○ Database management using PostgreSQL and Milvus.
● Conduct unit tests for each module.

4. Evaluation Phase:

● Conduct rigorous testing (unit testing, integration testing, etc.).

● Gather feedback from test users to improve accuracy and performance.
● Refine the system based on feedback and retest.

Quiz:

1. Compare waterfall model and incremental model.

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.
Software Engineering(3161605)

b) The loops for spiral model are fixed.

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

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

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks

Signature of Faculty:

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:
Software Engineering(3161605)
1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path.

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

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

Quiz:

1) Explain project scheduling process.

1) Breakdown of the Development Process:

Software Engineering(3161605)

2) Explain Software metrics used for software cost estimation

Software Engineering(3161605)

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

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

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

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

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

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

IEEE Template for SRS

Software Requirement Specification (SRS)

Project Title: Face Detection and Recognition System

Prepared By: Patel Om & Mayank Suthar

Department of Information Technology
Semester 6
Date:

1. Introduction
1.1 Purpose

The purpose of this document is to define the functional and non-functional requirements for the Face
Detection and Recognition System. This system will use image processing techniques to detect and
recognize human faces efficiently. The objective is to build a robust system capable of identifying
individuals in real-time using a trained model.

1.2 Scope

This system will:

● Detect faces in real-time from a webcam, CCTV, or uploaded image.

● Recognize known individuals by matching their faces with stored data.
● Generate logs with timestamps for recognized individuals.
● Provide a secure database to manage registered user data.

1.3 Definitions, Acronyms, and Abbreviations

● SRS: Software Requirement Specification

● AI: Artificial Intelligence
● ML: Machine Learning
● API: Application Programming Interface

1.4 References
Software Engineering(3161605)
● IEEE Standard 830-1998 for Software Requirements Specification
● Python Documentation for OpenCV and Face Recognition Libraries

1.5 Overview

This document outlines the system's functional, non-functional, and interface requirements along with
design constraints, assumptions, and dependencies.

2. Overall Description
2.1 Product Perspective

The system will integrate with the following:

● Camera Module: To capture real-time video.

● Database System: To manage registered user data.
● App-Based Interface: For user interaction and report generation.

2.2 Product Functions

● Face detection using MTCNN [Multi-Task Cascaded Convolutional Networks].

● Face recognition using FaceNet.
● User database management with CRUD operations.
● Real-time monitoring and alert generation.

2.3 User Characteristics

● Admin: Manages user data, sets security policies.

● End User: Interacts with the system to view real-time results.

2.4 Constraints

● Requires a system with a webcam for real-time detection.

● Dependent on proper lighting conditions for optimal recognition [This Could Be Solved Consider
as Optional For Now].

2.5 Assumptions and Dependencies

● Python 3.8+ with OpenCV and other relevant libraries must be installed.
● A stable internet connection is required for cloud-based processing.

3. Specific Requirements
3.1 Functional Requirements
Software Engineering(3161605)
● Login System: Secure authentication for admin users.
● Face Detection Module: Detects faces in real-time using a camera or uploaded image.
● Face Recognition Module: Matches detected faces with stored embeddings.
● User Management: Admin can add, delete, or modify user records.

3.2 Non-Functional Requirements

● Performance: The system should detect and recognize faces within 2 seconds.
● Security: The system should provide encrypted user data storage.
● Reliability: 95% accuracy for facial recognition.

3.3 Interface Requirements

● Hardware Interface: USB webcam for capturing faces.

● Software Interface: Integration with OpenCV and TensorFlow libraries.
● User Interface: Web dashboard to view recognized faces and manage records.

4. Design Constraints
● Limited processing speed on low-end hardware.
● Recognition accuracy may vary with poor lighting conditions.

5. Software System Attributes

5.1 Reliability

● The system should maintain 95% accuracy under optimal conditions.

5.2 Security

● User data like Face Embedding must be securely stored in an encrypted database.

5.3 Maintainability

● System updates should follow a modular structure for easy enhancements.

5.4 Portability

● The system should run efficiently on Windows, Linux, and macOS.

6. Other Requirements
Software Engineering(3161605)
● The system must support multi-face detection for group monitoring.
● Real-time alerts must be generated for unrecognized individuals.

Quiz:

1. Which are properties of good SRS?

2. What is functional and non-functional requirement?

1. Properties of a Good SRS

2. What is Functional and Non-Functional Requirement?

Software Engineering(3161605)

Suggested Reference:
Software Engineering(3161605)
References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

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

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:

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.
Software Engineering(3161605)
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

Data store A left-right open rectangle is denoted as data store; name of the data
store is written inside the shape

Data flow Data flow is represented by a directed arc with its data name

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
Software Engineering(3161605)
DFD uses hierarchy to maintain transparency thus multilevel DFD‟s can be created. Levels of
DFD are as follows:

• 0-level DFD: The primary external entities (boxes) produce information for use by the system
and consume information generated by the system
• 1-level DFD: It represents the main functions of the system and how they interact with each
other.
• 2-level DFD: It represents the processes within each function of the system and how they
interact with each other.

● Level 0 Of DFD Of Face Detaction & Recognistion System

- Camera :- In this this would Be Input Device It could Be change like Phone Camera to CCTV
Which Capture Live Streme And Send to our System
- Face Reco System :- This is Main System Where Using MTCNN Face will be Detected by It’s 4
Point [eye’s , Nose , mouth , ear] And Face Net Using It’s Pre Build Train Dataset it will first
calculate face Embedding and match will All the stored Embedding
- User Face Embedding :- This Dataset Contain the All User Face Embedding in Encrypted Form.
- UI Display :- This will show the Face is Recognised or not if recognised than Display It’s Detail

● Level 1 of DFD Of Face Detaction & Recognition

Software Engineering(3161605)

- This Level 1 the 3 Part newly Added 1st is Face detection and recognition and 3rd is Report
Generating
- We Done Nothing but Separating the Main System in brief formate

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?

1. In a data flow diagram, does an arrow represent a flow of control or something else?
Software Engineering(3161605)

2. What is “Information Flow Continuity” and how is it applied as a data flow diagram is
refined?

3. What are the advantages of DFD?

Suggested Reference:

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

Software Engineering(3161605)
International Editions

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

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

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

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of the Faculty

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".
Software Engineering(3161605)
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.
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).
Software Engineering(3161605)

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.

- Now Let’s Look Out ER Diagram For Our Face Detection & Recognition

Quiz:
1. what is weak entityset?
2. what is mapping cardinality?

1. What is a Weak Entity Set?

Software Engineering(3161605)

2. What is Mapping Cardinality?

References used by the students:

- SmartDraw :- For Drawing

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total
Software Engineering(3161605)
Marks Complete Complete Complete Complete Complete
implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:

Practical – 6
AIM: Draw Use Case 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.
Software Engineering(3161605)
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.
If a use-case has two or more significantly different outcomes, we can show this by
extending the use case to a main use case and one or more subsidiary cases.

• Background / Preparation:
How to draw a Use Case diagram?
It is essential to analyze the whole system before starting with drawing a use case diagram,
and then the system's functionalities are found. And once every single functionality is
identified, they are then transformed into the use cases to be used in the use case diagram.
After that, we will enlist the actors that will interact with the system. The actors are the
person or a thing that invokes the functionality of a system. It may be a system or a private
entity, such that it requires an entity to be pertinent to the functionalities of the system to
which it is going to interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular
instance of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
Software Engineering(3161605)
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;
A description of the state when the scenario finishes.

• 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

- Let see the Use Case Diagram For Our Current Project
Software Engineering(3161605)

Actors:
1. End Users:

○ Represents employees, students, or general users who interact with the system for identity
verification or authentication.
○ They provide facial input for recognition and access various system services.
2. Admin:

○ Responsible for managing the system's core operations.

○ Admin can add or remove face embeddings in the Embedding Database for authorized users.
○ Admin can also generate detailed reports based on recognition data.

System Components:
1. Face Detection & Recognition:

○ Core functionality that detects and verifies user faces for authentication.
2. Face Recognition Module:

○ Matches captured facial data with the stored embeddings for identity confirmation.
3. Embedding Database:

○ Stores facial embeddings securely. The Admin manages entries by adding or removing face data.
4. Report Generating:

○ Provides detailed system performance logs, recognition success rates, and security alerts for admin
review.
Software Engineering(3161605)

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. What are the four main components of a use case diagram?

2. List relationships used in a use case.

Software Engineering(3161605)

3. What Tests Can Help Find Useful Use Cases?

Software Engineering(3161605)
Suggested Reference:

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

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

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

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

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:

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.
Software Engineering(3161605)

• 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
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
Software Engineering(3161605)
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

- Let’s see the COCOMO Problem Solving with Our Project Problem Face Detection &
Recognition

COCOMO Model Calculation for Face Detection & Recognition Project

- The Basic COCOMO Model (Constructive Cost Model) is used to estimate the effort, time, and resources
required for software development. It follows this formula:
Software Engineering(3161605)
Where:

● Effort (E) = Person-months (PM)

● Time (T) = Development time in months
● KLOC = Thousands of lines of code
● a, b, c, d = Constants based on project type
● Project Type = Organic, Semi-detached, or Embedded

Step 1: Identify the Project Type

● Since this is a small project with two developers working in a relatively stable environment, it fits the
Organic model.

Step 2: Determine Constants for Organic Model

● For Organic Model:

○ a=2.4a = 2.4a=2.4
○ b=1.05b = 1.05b=1.05
○ c=2.5c = 2.5c=2.5
○ d=0.38d = 0.38d=0.38

Step 3: Estimating KLOC (Lines of Code)

- Since your project is based on Face Detection & Recognition, an estimated size of 3 KLOC (3000 lines of
code) is reasonable.

Step 4: Effort Calculation

Step 5: Time Calculation

Software Engineering(3161605)
Step 6: Team Distribution

Since you have 2 developers, you can divide the total effort:

Since you mentioned completing it in 45-50 days, this calculation shows a slight mismatch. The
difference may indicate your team has worked efficiently or minimized unnecessary complexities.

Final Answer:

● Estimated Effort: ~7.61 Person-Months

● Estimated Time: ~5.2 months
● Total Calendar Days (for 2 developers): ~114 days
● Conclusion: Achieving this project in 45-50 days shows excellent teamwork and optimized
workflow.

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.
Software Engineering(3161605)

Suggested Reference:

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

International Editions
References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation 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:

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].
Software Engineering(3161605)

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.

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.

 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,
Software Engineering(3161605)
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.
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.
Software Engineering(3161605)

Messages

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

Following are types of messages enlisted below:

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

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

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

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

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

interaction that represents a message of the same lifeline, has been invoked.

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.
Software Engineering(3161605)

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.

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.
Software Engineering(3161605)

- Sequence Diagram

Scenario: Marking Attendance

1. Employee/Student faces the camera.
2. FaceDetector detects the face.
3. FaceRecognizer recognizes the face.
4. Database is queried to match the face embedding.
5. Attendance is marked in the database.

- Sequence Data
Employee/Student -> FaceDetector: Face Image

FaceDetector -> FaceRecognizer: Detected Face Coordinates

FaceRecognizer -> Database: Query Face Embedding

Database -> FaceRecognizer: Face Embedding

FaceRecognizer -> Attendance: Recognize Face

Attendance -> Database: Mark Attendance

Database -> Attendance: Attendance Record

Attendance -> Employee/Student: Attendance Marked

Software Engineering(3161605)
Explanation of Sequence Diagram
1. Employee/Student interacts with the system by facing the camera.
2. FaceDetector detects the face and sends the coordinates to FaceRecognizer.
3. FaceRecognizer queries the Database to match the face embedding.
4. Database returns the matching face embedding to FaceRecognizer.
5. FaceRecognizer recognizes the face and sends the result to Attendance.
6. Attendance marks the attendance in the Database.
7. Database confirms the attendance record.
8. Employee/Student receives confirmation that attendance has been marked.

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. in a sequence Diagram , what does a box depict? What does a dashed line depict? What does a
Arrow between boxes depict?
Software Engineering(3161605)

2. What does a X over a lifeline indicate?

Suggested Reference:

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

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

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total
Software Engineering(3161605)
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:

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.
Software Engineering(3161605)
o Validation ensures the product under development is as per the user
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.
• 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.
• 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.

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.

- Test Case Design and Testing Types for Face Detection & Recognition Project

1. Test Case Design

Software Engineering(3161605)
- The following table outlines key test cases for the Face Detection and Recognition project:

2. Integration Testing
- Integration testing ensures that different modules work together as expected.
Software Engineering(3161605)
3. System Testing

- System testing validates the entire system as a whole, ensuring it meets the requirements.

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.
Software Engineering(3161605)
o Test case template o The primary purpose of writing a test case is to achieve the

efficiency of the application.

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?
Software Engineering(3161605)
Software Engineering(3161605)

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

References used by the students:

Rubric wise marks obtained:

Software Engineering(3161605)
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:

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.
Software Engineering(3161605)

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 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.
Software Engineering(3161605)
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
welldefined 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.

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 APIdriven 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
Software Engineering(3161605)
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 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.
Software Engineering(3161605)
Software Engineering(3161605)

Suggested Reference:

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

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

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

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty: