Software Engineering(102045602)

Department of Computer Engineering

Practical 1
Aim: An introduction to software engineering & Studying Various phases of Water-Fall
Model. For each SDLC phase, identify the objectives and summaries outcomes. Assume
yourself as Software Analyst / Project developer/ / Manager and complete following practical
2, 3, 4,5,6,7,8,9,10 based on selected project. Choose any one project like:

1. Library Information System

2. Villager Telephone System
3. Waste Management Inspection Tracking System (WMITS)
4. Flight Control System
5. Ambulance Dispatching System /108
6. Suraksha Setu project system

INTRODUCTION TO SOFTWARE ENGINEERING:

SDLC - Waterfall Model

The Waterfall Model was the first Process Model to be introduced. It is also referred to
asa linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In this Waterfall model, typically, the outcome
of one phase acts as the input for the next phase sequentially.

The following illustration is a representation of the different phases of the Waterfall Model:

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

The sequential phases in Waterfall model are :

 Requirement Gathering and analysis − All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification
document.
 System Design − The requirement specifications from first phase are studied in this phase
and the system design is prepared. This system design helps in specifying hardwareand
system requirements and helps in defining the overall system architecture.
 Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is developed
and tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
Let us now learn about each of these phases in detail.

1. FEASIBILITY STUDY

The main goal of this phase is to determine whether it would be financially and technically
feasible to develop the software.

The feasibility study involves understanding the problem and then determining the various
possible strategies to solve the problem. These different identified solutions are analyzed
based on their benefits and drawbacks, The best solution is chosen and all the other phases
12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
are

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
carried out as per this solution strategy.

2. REQUIREMENTS ANALYSIS AND SPECIFICATION

The aim of the requirement analysis and specification phase is to understand the exact
requirements of the customer and document them properly. This phase consists of two
different activities.

Requirement gathering and analysis: Firstly all the requirements regarding the software are
gathered from the customer and then the gathered requirements are analyzed. The goal of the
analysis part is to remove incompleteness (an incomplete requirement is one in which some
parts of the actual requirements have been omitted) and inconsistencies (an inconsistent
requirement is one in which some part of the requirementcontradicts some other part).

Requirement specification: These analyzed requirements are documented in a software

requirement specification (SRS) document. SRS document serves as a contract between the
development team and customers. Any future dispute between the customers and the
developers can be settled by examining the SRS document.

3. DESIGN

The goal of this phase is to convert the requirements acquired in the SRS into a format that
can be coded in a programming language. It includes high-level and detailed design as well
as the overall software architecture. A Software Design Document is used to document all of
this effort (SDD)

4. CODING AND UNIT TESTING

In the coding phase software design is translated into source code using any suitable
programming language. Thus each designed module is coded. The aim of the unit testing
phase is to check whether each module is working properly or not.

5. INTEGRATION AND SYSTEM TESTING

Integration of different modules is undertaken soon after they have been coded and unit
tested. Integration of various modules is carried out incrementally over a number of
steps.During each integration step, previously planned modules are added to the
partiallyintegrated system and the resultant system is tested. Finally, after all the modules
have been successfully integrated and tested, the full working system is obtained and system
testing is carried out on this.

System testing consists of three different kinds of testing activities as described below.

 Alpha testing: Alpha testing is the system testing performed by the development team.
 Beta testing: Beta testing is the system testing performed by a friendly set of customers.
 Acceptance testing: After the software has been delivered, the customer performed
acceptance testing to determine whether to accept the delivered software or reject it.

6. MAINTENANCE
12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is 60% of the total effort spent to develop a full software. There are basically
three types of maintenance.

 Corrective Maintenance: This type of maintenance is carried out to correct errors that
were not discovered during the product development phase.
 Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
 Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as working on a new computer platform or
with a new operating system.

Advantages of the Classical Waterfall Model

The classical waterfall model is an idealistic model for software development. It is very
simple, so it can be considered the basis for other software development life cycle models.
Below are some of the major advantages of this SDLC model.

Easy to Understand: Classical Waterfall Model is very simple and easy to understand.
Individual Processing: Phases in the Classical Waterfall model are processed one at a time.

Properly Defined: In the classical waterfall model, each stage in the model is clearly defined.

Clear Milestones: Classical Waterfall model has very clear and well-understood milestones.

Properly Documented: Processes, actions, and results are very well documented.

Reinforces Good Habits: Classical Waterfall Model reinforces good habits like define-
before- design and design-before-code.

Working: Classical Waterfall Model works well for smaller projects and projects where
requirements are well understood.

Disadvantages of the Classical Waterfall Model

The Classical Waterfall Model suffers from various shortcomings, basically, we can’t use it in
real projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model.

 No Feedback Path: In the classical waterfall model evolution of software from one phase
to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for error
correction.
 Difficult to accommodate Change Requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customer’s requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
 No Overlapping of Phases: This model recommends that a new phase can start only after

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
the completion of the previous phase. But in real projects, this can’t be maintained. To
increase efficiency and reduce cost, phases may overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or uncertain
requirements. Once a phase has been completed, it is difficult to make changes or go back
to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential
approach, which means that stakeholders are typically involved in the early phases of the
project (requirements gathering and analysis) but may not be involved in the later phases
(implementation, testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done toward the end of
the development process. This means that defects may not be discovered until late in the
development process, which can be expensive and time-consuming to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a lengthy development
cycle, as each phase must be completed before moving on to the next. This can result in
delays and increased costs if requirements change or new issues arise.
 Not Suitable for Complex Projects: The Waterfall Model is not well-suited for complex
projects, as the linear and sequential nature of the model can make it difficult to manage
multiple dependencies and interrelated components.

When to Use the Classical Waterfall Model

 Only well-defined, unambiguous, and fixed requirements are employed with this
paradigm.
 The definition of a product is constant.
 People understand technology.
 There are no unclear prerequisites.
 There are many resources with the necessary knowledge readily available.
 When it’s a brief project.

The Waterfall approach involves little client engagement in the product development
process.The product can only be shown to end consumers when it is ready.

Applications of Classical Waterfall Model

 Large-scale Software Development Projects: The Waterfall Model is often used for
large- scale software development projects, where a structured and sequential approach is
necessary to ensure that the project is completed on time and within budget.
 Safety-Critical Systems: The Waterfall Model is often used in the development ofsafety-
critical systems, such as aerospace or medical systems, where the consequences of errors or
defects can be severe.
 Government and Defense Projects: The Waterfall Model is also commonly used in
government and defense projects, where a rigorous and structured approach is necessary to
ensure that the project meets all requirements and is delivered on time.
 Projects with well-defined Requirements: The Waterfall Model is best suited for projects
with well-defined requirements, as the sequential nature of the model requires a clear
understanding of the project objectives and scope.

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
Practical-2

AIM: - Define requirement gathering and technical requirement specification

forselected project.

What is requirement gathering in project management?

Requirements gathering is the process of identifying your project’s exact requirements from
startto finish. This process occurs during the project initiation phase but you’ll continue to
manage your project requirements throughout the entire project timeline.
Requirements gathering typically happens during the project brief or initial kick-off meeting.
Some questions include:
 How long will our project schedule be?
 Who will be involved in the project?
 What risks may we face in this project?

Requirements gathering shouldn’t be complex, but it’s an important component of the project
initiation process.
 For a Waste Management Inspection Tracking System, the requirement gathering
process would involve:

1.Stakeholder Identification:Identify and list all stakeholders involved in the Waste Management
Inspection Tracking System project. This include administrators, inspectors, supervisors, regulatory
bodies, and they and other relevant parties.

2.Interviews and Surveys: Conduct interviews and workshops with stakeholders to gather insights
into their expectations and requirements.

3.Surveys and Questionnaries: Distribute surveys or questionnaires to gather

feedback from a broader audience. Collect quantitative data on user preferences,
system expectations, and key functionalities.

4.Observation: Observe current waste management practices and inspection

processes. Identify any challenges or inefficiencies in the existing system.

5.Document Analysis: Review existing documentation, regulations, and

standards related to waste management. Extract relevant information that should be
incorporated into the WMITS.

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
6.Prototyping: Develop prototypes or mockups to visually represent potential
system features. Use prototypes to gather feedback and refine requirements
iteratively.

7.Prioritization:Prioritize requirements based on their criticality and impact on the success of the
WMITS. Identify core functionalities that must be included in the initial release.

8.Requirement Documentation: Document gathered requirements in a clear and structured format,

including functional and non-functional requirements. Ensure that requirements are traceable,
measurable, and testable.

 Technical Requirement Specification:

Technical Requirement Specification is a detailed document that outlines the technical aspects of a
project. It translates the functional requirements into a technical solution, providing guidance for the
development, implementation, and maintenance of the system.

Components:

1.System Architecture: Define the overall system architecture, including hardware components,
network infrastructure, and software layers. Specify whether the system will be cloud-based, on-
premises, or a hybrid solution.

2.Database Design: Specify the database structure, including tables, relationships, and data
types.Define data storage and retrieval mechanisms, ensuring efficiency and data integrity.

3.Security Requirements:Define security measures, including user authentication, authorization

mechanisms, and data encryption. Specify measures to protect against common security threats in
waste management systems.

4.Performance Requirements:Define performance benchmarks, such as response times, throughput,

and system scalability. Specify measures to optimize performance, especially during peak usage.

5.User Interface Design:Provide guidelines for the user interface design, ensuring a user-friendly and
intuitive experience. Specify design principles, layout, and interactive elements.

6.Documentation:Provide guidelines for system documentation, including technical manuals, user

guides, and developer documentation.

7.Training Requirements:Outline training requirements for users, administrators, and support staff.
Identify the training materials and resources needed for effective system adoption.

8.Maintenance and Support:Define procedures for ongoing system maintenance, updates, and support.
Specify the expected response times for addressing issues and implementing updates.

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

Practical- 3

AIM: - Development of DFD and E-R diagram for the software domain problem.
What is a data flow diagram?
A data flow diagram (DFD) maps out the flow of information for any process or system. It
uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data
inputs, outputs, storage points and the routes between each destination. Data flowcharts can
range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that
dig progressivelydeeper into how the data is handled. They can be used to analyze an existing
system or model a new one. Like all the best diagrams and charts, a DFD can often visually
“say” things that would be hard to explain in words, and they work for both technical and
nontechnical audiences, from developer to CEO. That’s why DFDs remain so popular after all
these years. While they work well for data flow software and systems, they are less applicable
nowadays to visualizinginteractive, real-time, or database-oriented software or systems.

Characteristics of DFD

 DFDs are commonly used during problem analysis.

 DFDs are quite general and are not limited to problem analysis for software
requirements specification.
 DFDs are very useful in understanding a system and can be effectively used during
analysis.
 It views a system as a function that transforms the inputs into desired outputs.
 The DFD aims to capture the transformations that take place within a system to the
input data so that eventually the output data is produced.
 The processes are shown by named circles and data flows are represented by named
arrows entering or leaving the bubbles.
 A rectangle represents a source or sink and it is a net originator or consumer of data. A
source sink is typically outside the main system of study.

Components of DFD

The Data Flow Diagram has 4 components:

 Process Input to output transformation in a system takes place because of process function.
The symbols of a process are rectangular with rounded corners, oval, rectangleor a circle.
The process is named a short sentence, in one word or a phrase to express its essence.

 Data Flow Data flow describes the information transferring between different parts of
the systems. The arrow symbol is the symbol of data flow. A relatable name should be
given to the flow to determine the information which is being moved. Data flow also
represents material along with information that is being moved. Material shifts are modeled
in systems that are not merely informative. A given flow should only transfera single type
of information. The direction of flow is represented by the arrow which can also be bi-
directional.

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
 Warehouse The data is stored in the warehouse for later use. Two horizontal lines
represent the symbol of the store. The warehouse is simply not restricted to being a data
file,rather it can be anything like a folder with documents, an optical disc, a filing cabinet.
The data warehouse can be viewed independent of its implementation. Whenthe data
flow from the warehouse it is considered as data reading and when data flowsto the
warehouse it is called data entry or data updating.

 Terminator The Terminator is an external entity that stands outside of the system and
communicates with the system. It can be, for example, organizations like banks, groups of
people like customers or different departments of the same organization, which is not apart
of the model system and is an external entity.

Symbols Used in DFD

 Square Box: A square box defines source or destination of the system. It is also
calledentity. It is represented by rectangle.
 Arrow or Line: An arrow identifies the data flow i.e. it gives information to the data thatis
in motion.
 Circle or bubble chart: It represents as a process that gives us information. It is also called
processing box.
 Open Rectangle: An open rectangle is a data store. In this data is store either temporaryor
permanently.

DFD for waste management system:

0 LEVEL DFD

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

1 LEVEL DFD for admin/municipal corporation:

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
What is ER Diagram?

The Entity Relational Model is a model for identifying entities to be represented in the database
and representation of how those entities are related. The ER data model specifies enterprise
schema that represents the overall logical structure of a database graphically.

The Entity Relationship Diagram explains the relationship among the entities present in the
database. ER models are used to model real-world objects like a person, a car, or a company
and the relation between these real-world objects. In short, the ER Diagram is the structural
format of the database.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists
of these symbols:
 Rectangles: Rectangles represent Entities in the ER Model.
 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
 Double Rectangle: Double Rectangle represents a Weak Entity.

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering
Practical-4
AIM: Draw Use case and Activity Diagrams for the project definition.

Use case diagram: A Use Case Diagram is a vital tool in system design, it provides a visual

representation of how users interact with a system. It serves as a blueprint for

understanding the functional requirements of a system from a user’s perspective, aiding in

the communication between stakeholders and guiding the development process.

 Use case diagram of waste management system:

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

Activity Diagram:

Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps involved
in the execution of a use case. It is a type of behavioral diagram and we can depict both sequential
processing and concurrent processing of activities using an activity diagram ie an activity diagram
focuses on the condition of flow and the sequence in which it happens .
 Activity diagram for waste management system:

12102040701109,12102040701110,12102040701121,12202040703016
 Software Engineering(102045602)
Department of Computer Engineering

PRACTICAL: 5
AIM: Draw the Sequence Diagram for the project definition.

Sequence Diagram:

Sequence Diagram is an interaction diagram that details how operations are carried out -- what messages
are sent and when. Sequence diagrams are organized according to time. The time progresses as you go
down the page. The objects involved in the operation are listed from left to right according to when they
take part in the message sequence.

 Sequence Diagram for waste management system:

Figure 5 Sequence Diagram

 Software Engineering(102045602)
Department of Computer Engineering

Practical:6
Aim: Development of State Transition Diagram for Software project definition.

State Transition Diagram :

They are also known as Dynamic models. As the name suggests, it is a type of diagram that is used
to represent different transition (changing) states of a System. It is generally used to graphically
represent all possible transition states a system can have and model such systems. It is very
essential and important and right for object-oriented modeling from the beginning. The System
consists of various states that are being represented using various symbols in the state transition
diagram

 State Transition Diagram of waste management system:

 Software Engineering(102045602)
Department of Computer Engineering
PRACTICAL: 7
AIM: Design Class & Object Diagrams for software domain problem.
Class diagram:
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes in a system. UML is a
standardized modeling language that helps in designing and documenting software systems. They
are an integral part of the software development process, helping in both the design and
documentation phases.
 Class diagram for waste management system:

Fig. Class Diagram

,
 Software Engineering(102045602)
Department of Computer Engineering

Object diagram:
Object diagrams are a visual representation in UML (Unified Modeling Language)
that illustrates the instances of classes and their relationships within a system at a
specific point in time. They display objects, their attributes, and the links between
them, providing a snapshot of the system’s structure during execution. Since object
diagrams depict behavior when objects have been instantiated, we can study the
behavior of the system at a particular instant.
 Object Diagram for waste management system:

,
 Software Engineering(102045602)
Department of Computer Engineering

Fig. Object Diagram

PRACTICAL:8

AIM: Prepare a data dictionary for Software project definition.

SOLUTION:
,
 Software Engineering(102045602)
Department of Computer Engineering

1. Users

Field Name Datatype Size Constraint Description

User_id Int 11 Primary Key Unique id of tbl_user
Name Varchar 50 Not null Name of User
Contact Int 15 Not null User Contact no.
Email Varchar 50 Not null User Email
Password Varchar 20 Not null Password
OTP Int 6 Not null OTP Verify
Is_verify Varchar 3 Not null Yes/No for verify
Regi_datetime Datetime Not null | Register date time

2. Categories

Field Name Datatype Size Constraint Description

Catid Int 11 Primary Key Unique id of tbl_category
Catname Varchar 25 Not null Category name
Catimg Varchar 100 Not null Upload image

3. Address

Field Name Datatype Size Constraint Description

Address_id Int 11 Primary Key Unique id of tbl_address
User_id Int 11 Foreign key Unique id of tbl_user
Type Varchar 3 Not null Office/home-type
Addline1 Varchar 50 Not null Address 1
Addline2 Varchar 50 Not null Address 2
Landmark Varchar 15 Not null Landmark
Pincode Int 10 Not null Pincode
Contact_no Int 15 Not null Contact no.

4. Subcategory

Field Name Datatype Size Constraint Description

,
 Software Engineering(102045602)
Department of Computer Engineering
Subcat_id Int 11 Primary Key Unique id of tbl_subcategory
Subcat_name Varchar 25 Not null Sub-category name
Catid Int 11 Foreign key Unique id of tbl_category

5. Admin (Municipal corporation)

Field Name Datatype Size Constraint Description

Admin_id Int 11 Primary Key Unique id of tbl_admin
Username Varchar 25 Not null Admin username
Contact Int 15 Not null Contact no.
Email Varchar 50 Not null Email id.
Password Varchar 25 Not null Password

6. Trash Request

Field Name Datatype Size Constraint Description

Request_id Int 11 Primary Key Unique id of trash request
User_id Int 11 Foreign Key Unique id of tbl_user
Request_date Datetime Not null Date of trash request
Status Varchar 20 Not null Status of trash request (e.g.,
pending, completed)

7. Review

Field Name Datatype Size Constraint Description

Review_id Int 11 Primary Key Unique id of review
User_id Int 11 Foreign Key Unique id of tbl_user
Review_text Text Not null Text for review
Rating Int Not null Rating given by user
Review_date Datetime Not null Date of review

8. Feedback

Field Name Datatype Size Constraint Description

Feedback_id Int 11 Primary Key Unique id of feedback
User_id Int 11 Foreign Key Unique id of tbl_user
Feedback_text Text Not null Text of the feedback
Feedback_date Datetime Not null Date of the feedback

,
 Software Engineering(102045602)
Department of Computer Engineering

9. Gallery

Field Name Datatype Size Constraint Description

Image_id Int 11 Primary Key Unique id of gallery image
Image_url Varchar 100 Not null URL of the image
Caption Varchar 50 Caption or description of the
image
Upload_date Datetime Not null Date of image upload

10. Blog

Field Name Datatype Size Constraint Description

Blog_id Int 11 Primary Key Unique id of blog post

,
 Software Engineering(102045602)
Department of Computer Engineering

Practical-9
Aim: Draw the Deployment Diagram for the project definition.
Deployment Diagram:
A Deployment Diagram in software engineering is a type of Structural UML
Diagram that shows the physical deployment of software components on
hardware nodes. It illustrates the mapping of software components onto the
physical resources of a system, such as servers, processors, storage devices, and
network infrastructure.
 Deployment Diagram for waste management system:

,
 Software Engineering(102045602)
Department of Computer Engineering

PRACTICAL:10
Aim: Design the Test Cases waste management inspection tracking system.
1. User Authentication:

1.1 Test Case: Valid User Login

Input: Valid username and password.
Expected Output: User is logged into the system successfully.

1.2 Test Case: Invalid User Login

Input: Incorrect username or password.
Expected Output: Error message indicating invalid credentials.

2. Inspection Management:

2.1 Test Case: Schedule Inspection

Input: Inspector selects a date, time, and location for an inspection.
Expected Output: Inspection is scheduled and appears in the inspector's task list.

2.2 Test Case: Update Inspection Status

Input: Inspector updates the status of an inspection (e.g., scheduled, ongoing, completed).
Expected Output: Inspection status is updated accordingly.

2.3 Test Case: Record Inspection Findings

Input: Inspector records findings and observations during an inspection.
Expected Output: Inspection findings are saved and associated with the respective
inspection.

3. Reporting:

3.1 Test Case: Generate Inspection Report

Input: Manager selects a date range and generates an inspection report.
Expected Output: Comprehensive report containing inspection details, findings, and
,
 Software Engineering(102045602)
Department of Computer Engineering
recommendations is generated.

3.2 Test Case: Export Report

Input: User exports an inspection report in PDF format.
Expected Output: Report is downloaded in PDF format and is readable and accurate.

4. Notifications and Alerts:

4.1 Test Case: Receive Notification for Upcoming Inspection

Input: Inspection date approaches.
Expected Output: Inspector receives a notification/alert about the upcoming inspection.

4.2 Test Case: Receive Alert for Overdue Tasks

Input: Inspection task remains incomplete past the due date.
Expected Output: Inspector receives an alert/notification about the overdue task.

5. Dashboard:

5.1 Test Case: Monitor Inspection Activities

Input: Manager accesses the dashboard.
Expected Output: Real-time overview of inspection activities, performance metrics, and
analytics are displayed.
6. Mobile Compatibility:

6.1 Test Case: Access System on Mobile Device

Input: User accesses the system using a mobile device.
Expected Output: System interface is responsive and functional on the mobile device.

7. Communication:

7.1 Test Case: Send Message to Another User

Input: User composes and sends a message to another user.
Expected Output: Message is sent successfully and received by the intended recipient.

8. Security:

8.1 Test Case: Unauthorized Access Attempt

Input: User tries to access a feature restricted to another user role.
Expected Output: Access is denied, and an appropriate error message is displayed.

,
 Software Engineering(102045602)
Department of Computer Engineering
9. Performance:

9.1 Test Case: Concurrent User Sessions

Input: Multiple users simultaneously access the system.
Expected Output: System performance remains stable, with no significant degradation in
response time.
10. Compliance:

10.1 Test Case: Compliance with Data Privacy Regulations

Input: Review of system data handling practices.
Expected Output: System complies with relevant data privacy regulations, with
appropriate measures in place to protect user data.

PRACTICAL: 11

AIM: prepare SRS document for waste management inspection tracking system.

 1. Introduction
1.1 Purpose
The purpose of this document is to define the requirements for the development of a
Waste Management Inspection Tracking System. This system aims to streamline and
automate the process of tracking waste management inspections conducted by regulatory
bodies or organizations responsible for waste management.
1.2 Scope
The Waste Management Inspection Tracking System will provide a platform for
managing inspection schedules, recording inspection findings, generating reports, and
facilitating communication among stakeholders involved in waste management.

 2. Overall Description

2.1 Product Perspective

The Waste Management Inspection Tracking System will operate as a standalone web-
based application accessible via web browsers. It will integrate with existing databases
and systems for data exchange and interoperability.

2.2 Product Features

User authentication and authorization
Inspection scheduling and management
Recording inspection findings and observations
,
 Software Engineering(102045602)
Department of Computer Engineering
Generating inspection reports
Dashboard for real-time monitoring and analytics
Notifications and alerts for upcoming inspections or overdue tasks
Integration with GIS for location-based tracking (optional)
Mobile compatibility for field inspectors
Multi-user collaboration and communication features
2.3 User Classes and Characteristics
The system will cater to the following user classes:

Administrators: Responsible for system configuration, user management, and

overseeing overall system operation.
Inspectors: Conduct inspections, record findings, and generate reports.
Managers: Supervise inspection activities, review reports, and monitor performance.

 3. Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces
The system shall provide an intuitive user interface for easy navigation and interaction. It
shall be compatible with major web browsers and mobile devices.

3.1.2 Hardware Interfaces

The system shall not require any specific hardware interfaces beyond standard web
browser capabilities.

3.1.3 Software Interfaces

The system shall integrate with existing databases and systems for data exchange,
including but not limited to waste management databases and GIS systems.

 3.2 Functional Requirements

3.2.1 User Authentication

Users shall be required to authenticate using username and password.
Role-based access control shall be implemented to restrict access to specific features
based on user roles.
3.2.2 Inspection Management
,
 Software Engineering(102045602)
Department of Computer Engineering
Users shall be able to schedule inspections, assign inspectors, and set inspection
priorities.
Inspectors shall be able to view their assigned inspections, update inspection status, and
record findings.

3.2.3 Reporting
The system shall generate comprehensive inspection reports including inspection details,
findings, recommendations, and corrective actions.
Reports shall be exportable in multiple formats such as PDF, Excel, and CSV.

3.2.4 Notifications and Alerts

The system shall send notifications and alerts to users for upcoming inspections, overdue
tasks, or any critical issues.

3.2.5 Dashboard
The system shall provide a dashboard for real-time monitoring of inspection activities,
performance metrics, and analytics.

3.2.6 Mobile Compatibility

The system shall be accessible and functional on mobile devices to facilitate field
inspections.

3.2.7 Communication
The system shall support communication features such as messaging and commenting to
facilitate collaboration among users.

 3.3 Non-functional Requirements

3.3.1 Performance
The system shall be capable of handling concurrent user sessions without significant
performance degradation.
Response time for user interactions shall be within acceptable limits.

3.3.2 Security
The system shall implement industry-standard security measures including encryption,
secure authentication, and access controls to protect sensitive data.
Regular security audits and updates shall be performed to ensure system integrity.

3.3.3 Reliability

,
 Software Engineering(102045602)
Department of Computer Engineering
The system shall have a high level of reliability with minimal downtime for maintenance
or upgrades.
Data backups shall be performed regularly to prevent data loss in case of system failures.

3.3.4 Scalability
The system shall be designed to accommodate future growth in terms of user base and
data volume.
Scalability measures such as load balancing and resource optimization shall be
implemented.

 4. Other Requirements

4.1 Legal and Regulatory Requirements

The system shall comply with relevant laws, regulations, and standards governing waste
management and data privacy.

4.2 Documentation Requirements

Comprehensive user manuals, administrator guides, and technical documentation shall be
provided to support system deployment and maintenance.

 5. Conclusion

This Software Requirements Specification document outlines the functional, non-

functional, and other requirements for the development of the Waste Management
Inspection Tracking System. It serves as a blueprint for system design, implementation,
and testing to ensure the successful delivery of a robust and effective solution for waste
management inspection tracking.

,
 Software Engineering(102045602)
Department of Computer Engineering

Practical- 12

AIM : Why Agile process models with DevOps are recommended in big companies like
Infosys. Justify with one of the case studies (You can explore it with any tool like JIRA).
Write a report of 3-5 pages on case study.
Agile Model | Introduction

The Agile Model is an incremental and iterative process of software development. It defines
eachiteration’s number, duration, and scope in advance. Every iteration is considered a short
“frame” in the Agile process model, which mostly lasts from two to four weeks.

Agile Model divides tasks into time boxes to provide specific functionality for the release.
Each build is incremental in terms of functionality, with the final build containing all the
attributes. The division of the entire project into small parts helps minimize the project risk
and the overall project delivery time.

,
 Software Engineering(102045602)
Department of Computer Engineering
Phases of Agile MODEL:

 Requirements Gathering: In this Agile model phase, you must define the requirements.
The business opportunities and the time and effort required for the project should also be
discussed.
 Design the Requirements: Following the feasibility study, you can work with
stakeholders to define requirements. Using the high-level UML diagram, you can
determine how the new system will be incorporated into your existing software system.
 Develop/Iteration: The real work begins at this stage after the software development
team defines and designs the requirements.
 Test: This phase of the Agile Model involves the testing team. For example, the Quality
Assurance team checks the system’s performance and reports bugs during this phase.
 Deployment: In this phase, the initial product is released to the user.
 Feedback: After releasing the product, in this phase, the team receives feedback about
the product and works on correcting bugs based on the received feedback.

Compared to Waterfall, Agile cycles are short. There may be many such cycles in a project.
Thephases are repeated until the product is delivered.

,
 Software Engineering(102045602)
Department of Computer Engineering

Why Agile process models with DevOps are recommended?

1. Flexibility and Adaptability: Agile processes provide a flexible and adaptable

framework formanaging projects, allowing big companies to respond quickly to changing
business requirements. DevOps complements Agile by promoting a collaborative and
iterative approach to development and operations, ensuring that software can be released
and updated rapidly in response to market demands.

2. Continuous Integration and Delivery (CI/CD): Agile, when combined with DevOps
practices, enables continuous integration and delivery. This means that code changes are
automatically integrated, tested, and delivered to production environments, reducing the
time between development and deployment.

3. Collaboration and Communication: Agile methodologies emphasize collaboration

among cross-functional teams. DevOps extends this collaboration to include operations
teams, breaking down silos between development and operations.

4. Feedback Loops: Agile and DevOps emphasize the importance of feedback loops at
various stages of the development lifecycle. This enables continuous improvement by
identifying issues early in the process, allowing teams to make necessary adjustments.
5. Risk Management: The iterative nature of Agile and the automated testing and
deployment aspects of DevOps contribute to effective risk management. By delivering
smaller, incremental updates, teams can identify and address issues earlier in the
development process.

CASE STUDY: Agile Model with DevOps for NETFLIX.

Netflix: DevOps and Agile Model

Netflix, an entertainment giant, has emerged as a pioneering force in the tech world due to
its unparalleled tech innovation. Their practices, especially in DevOps and Agile, have
significantly influenced the technology world with its world-class engineering efforts,
culture, and product development over the years.

DevOps at Netflix

Netflix's approach to DevOps involves moving their infrastructure from on-premises to the
cloudto scale their service, a process that took several years to complete. One of the key
reasons Netflix is successful today is because they recognized the scalability advantages of
the cloud early on and allowed Amazon to handle the heavy lifting of building the best data
centers.

,
 Software Engineering(102045602)
Department of Computer Engineering
Netflix also implemented containerization, which provides consistency between
environments and allows containers to be destroyed and created very quickly, which helps
with scaling,reliability, and efficient rollbacks.

,
 Software Engineering(102045602)
Department of Computer Engineering
Netflix doesn't enforce using specific programming languages and frameworks. They aim to
hireintelligent people and provide them with the freedom to solve problems in their own
way. Every engineer at Netflix has full access to the production environment, and there are
neither strict policies nor procedures that prevent them from accessing the production
environment.
Netflix is a data-driven, decision-driven company. It doesn't rely on guesses or fall victim to
gut instincts and traditional thinking. Instead, it invests in algorithms and systems that comb
enormous amounts of data quickly and notify when there's an issue.

Agile at Netflix

Netflix operates in an Agile fashion, focusing on fast feedback, iterative changes, and cross-
collaboration. One of the major advantages of Agile is that it allows teams to release
software more often instead of having longer release cycles. Netflix has found that releasing
new movies and shows on a weekly basis keeps customers excited and intrigued, so they
don’t get bored by the same selections over and over.
Netflix takes user stories to the next level by understanding every user story with advanced
personalization. In fact, 75% of Netflix views are a result of their recommendation engine. By
creating different trailers and artwork for content based on viewers' previous movie and
show choices, they’re able to more precisely communicate recommendations with people
based ontheir interests and behavior.

Agile Implementation Process

 Cross-Functional Agile Teams

Netflix organized cross-functional Agile teams to ensure collaboration
andcommunication across various disciplines involved in recommendation system
development. These teams included data scientists, engineers, UX designers, and quality
assurance professionals, fostering a holistic approach to feature development.

 Scrum Methodology
The adoption of the Scrum framework facilitated the iterative and incremental
development of the recommendation system. Sprints, typically lasting two weeks,
allowed teams to prioritize and deliver high-value features rapidly. Regular sprint
reviewsand retrospectives provided valuable feedback loops for continuous
improvement.

 A/B Testing for Algorithmic Enhancements

Netflix employed Agile principles in algorithm development through extensive A/B
testing. This iterative testing approach enabled teams to experiment with different
recommendation algorithms, evaluate their effectiveness through real user interactions,
and make data-driven decisions on algorithmic improvements.

DevOps Implementation Process

 Continuous Integration and Deployment (CI/CD)

Netflix embraced a robust CI/CD pipeline to automate the integration and deployment of
,
 Software Engineering(102045602)
Department of Computer Engineering
recommendation system updates. This automated process allowed for seamless
integration of new algorithms, features, and bug fixes into the production environment.
The continuous deployment approach enabled rapid delivery without compromising
system stability.

,
 Software Engineering(102045602)
Department of Computer Engineering

 Infrastructure as Code (IaC)

Infrastructure as Code (IaC) principles were applied to manage and
provisioninfrastructure programmatically. This approach enhanced consistency across
development, testing, and production environments, reducing the risk of configuration
drift and ensuring that the infrastructure aligned with the requirements of the
recommendation system.

 Collaborative Culture and Shared Responsibility

DevOps practices at Netflix fostered a collaborative culture where development,
operations, and quality assurance teams shared responsibilities. This shared ownership
resulted in increased communication, faster issue resolution, and a collective commitment
to the reliability and performance of the recommendation system.

Benefits Realized

 Rapid Adaptation to User Preferences

The Agile implementation enabled Netflix to quickly respond to changing user
preferences. The iterative development cycles allowed for the swift integration of new
content categories, genres, or features into the recommendation system, ensuring that
users were consistently presented with relevant and engaging content.

 Enhanced Collaboration and Communication

Cross-functional Agile teams facilitated improved collaboration and communication
among team members. The daily stand-ups and regular sprint reviews provided a
platform for sharing progress, addressing challenges, and aligning the team's efforts
with the overarching goals of the content recommendation system.

 Quick Response to Market Trends

Netflix's Agile approach empowered the development teams to respond swiftly to
emerging market trends. Whether it be the popularity of a specific genre or the
introduction of new viewing behaviors, the Agile methodology allowed Netflix to adapt
its recommendation algorithms to align with evolving industry dynamics.

Conclusion

Netflix's Agile implementation for the content recommendation system showcases the
effectiveness of Agile methodologies in the dynamic and fast-paced world of streaming
services. By embracing cross-functional teams, Scrum, and continuous improvement
through A/B testing, Netflix enhanced its ability to deliver a personalized and engaging user
experience. The benefits realized, including rapid adaptation to user preferences and a quick
response to market trends, emphasize the importance of agility in the highly competitive
streaming industry. As Netflix continues to innovate, its Agile practices serve as a valuable
model for other organizations seeking to navigate the ever-changing landscape of digital
entertainment.