A Laboratory Manual for

SOFTWARE ENGINEERING
(3161605)

B.E. Semester 6 (Information Technology)

Directorate of Technical Education, Gandhinagar,

Gujarat.
1
 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 2024-25.

Place:

Date:

Name and Sign of Faculty member

Head of the Department

2
Preface

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

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

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

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

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

3
Software Engineering (3161605)

Practical – Course Outcome matrix

Course Outcomes (COs):

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

Discuss the Project Management: Project Planning and

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

4. Draw the Data Flow Diagram for your selected Project. √ √

Draw the Entity-Relationship Diagram for your selected

5. Project √ √

Draw Usecase Diagram for your selected Project.

6. √ √

Solve the problem by applying basic COCOMO model.

7. √ √

8. Modeling UML Class Diagrams and Sequence diagrams √ √

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

4
Software Engineering (3161605)

Industry Relevant Skills

The following industry relevant competency is expected to be developed in the student by undertaking
the practical work of this laboratory.

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

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

Guidelines for Faculty members

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

Instructions for Students

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

5
 Software Engineering (3161605)

General Guidelines for Software Engineering Laboratory Work

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

2. For performing the practical list, student can able to work individually or work in a team as per
subject teacher guidelines.

3. After establishing the team, every team will have to identify the problem area / definition for
performing the laboratory work.

4. Every team has to approve their problem definition to respective faculty member within 15 days
of the beginning of the semester.
5. Once the problem definition is approved by the faculty member, every team has to perform all the
practical based on their respective problem definition.

6
Software Engineering (3161605)

Index
(Progressive Assessment Sheet)

Sr. Objective(s) of Experiment Pag Date Date Assess Sign. Rem

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

7
 Software Engineering (3161605)

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

Objectives:
• To learn different software process models.
• To compare various software process models and analyze their advantages and disadvantages.
• To identify a suitable model for a specific project based on its requirements.

Theory:
A software process model is a framework that describes the activities performed at each stage of the
software development life cycle (SDLC). Different process models help in managing the software development
process efficiently.

List of Different Process Models

1. Waterfall Model
• Description: Linear and sequential approach with distinct phases (Requirements, Design, Implementation,
Testing, Deployment).
• Phases: Each phase must be completed before the next begins.
• Use Case: Suitable for projects with well-defined, stable requirements.
• Advantages: Simple, easy to understand, and well-documented.
• Disadvantages: Inflexible, difficult to accommodate changes, late testing.

2. V-Model (Verification and Validation Model)

• Description: Extension of the Waterfall model with a corresponding testing phase for each development
phase.
• Phases: Development and testing phases are parallel (e.g., Requirements ⇨ Acceptance Testing, Design
⇨ System Testing).
• Use Case: Ideal for projects requiring rigorous testing and validation.
• Advantages: Early defect detection, clear structure.
• Disadvantages: Rigid, not suitable for changing requirements.

3. Incremental Model
• Description: Divides the project into smaller increments, each delivering a part of the functionality.
• Phases: Each increment goes through requirements, design, implementation, and testing.
• Use Case: Suitable for projects where partial delivery is acceptable.
• Advantages: Early delivery, flexibility, easier to manage risks.
• Disadvantages: Requires good planning, integration challenges.

4. RAD Model (Rapid Application Development)

• Description: Focuses on rapid prototyping and iterative development with minimal planning.
• Phases: Requirements Planning, User Design, Construction, Cutover.
• Use Case: Ideal for projects requiring quick delivery and frequent user feedback.
• Advantages: Fast delivery, high user involvement.
• Disadvantages: Requires skilled teams, not suitable for large projects.

8
 Software Engineering (3161605)

5. Agile Model
• Description: Iterative and flexible approach focusing on delivering small, functional increments.
• Key Principles: Customer collaboration, responding to change, working software.
• Frameworks: Scrum, Kanban, XP.
• Use Case: Suitable for projects with evolving requirements.
• Advantages: Adaptable, continuous feedback, faster delivery.
• Disadvantages: Requires active user involvement, less documentation.

6. Iterative Model
• Description: Develops the product through repeated cycles (iterations), refining it over time.
• Phases: Each iteration includes planning, design, implementation, and testing.
• Use Case: Suitable for large projects where requirements evolve.
• Advantages: Early delivery, flexibility, risk management.
• Disadvantages: Requires careful planning, can be costly.

7. Spiral Model
• Description: Combines iterative development with systematic risk analysis.
• Phases: Planning, Risk Analysis, Engineering, Evaluation (repeated in cycles).
• Use Case: Ideal for large, complex, and high-risk projects.
• Advantages: Risk management, flexibility, early prototyping.
• Disadvantages: Complex, costly, requires expertise.

8. Prototype Model
• Description: Focuses on building a prototype to understand requirements and refine the product.
• Phases: Prototype creation, user feedback, refinement.
• Use Case: Suitable for projects with unclear or evolving requirements.
• Advantages: Early user feedback, reduces risk of misunderstanding requirements.
• Disadvantages: Can lead to scope creep, additional cost and time.

9. Agile Model (Repeated for emphasis)

• Description: Iterative and flexible approach focusing on delivering small, functional increments.
• Key Principles: Customer collaboration, responding to change, working software.
• Frameworks: Scrum, Kanban, XP.
• Use Case: Suitable for projects with evolving requirements.
• Advantages: Adaptable, continuous feedback, faster delivery.
• Disadvantages: Requires active user involvement, less documentation.

Appropriate Process Model for the Mini Payroll Management System

The Incremental Model is the most suitable process model for this project, as highlighted in Practical 2 of the
lab manual. Here’s the detailed justification:

9
 Software Engineering (3161605)

1.1: Prototyping Model for the Payroll System

Why the Prototyping Model?

• The payroll system required iterative feedback from stakeholders (e.g., refining tax calculation logic).
• Initial prototypes focused on core modules (Login, Salary Processing), which were refined based on user
testing (see Fig 1.1).
• Advantages for the Project:
o Early detection of mismatched requirements (e.g., tax rules).
o Reduced risk of scope creep due to phased deliverables.

10
 Software Engineering (3161605)

Why the Incremental Model

1. Project Characteristics:
o The project is modular, with distinct components like login, employee management, attendance
tracking, salary processing, and reporting.
o Requirements are well-defined early (via the SRS document) but require phased implementation.
2. Alignment with Lab Structure:
o The lab experiments follow a step-by-step approach (e.g., SRS → SPMP → DFDs → UML
diagrams → testing), mirroring incremental development.
o Each practical corresponds to a functional increment (e.g., user management, salary calculation).
3. Advantages for a Student Project:
o Manageable Development: Breaks the project into smaller increments (e.g., login → employee
registration → salary processing), reducing complexity.
o Early Feedback: Faculty/stakeholders can review each increment (e.g., SRS, SPMP) before
proceeding to the next phase.
o Flexibility: Allows adjustments within increments (e.g., refining attendance logic) without
disrupting the entire system.
o Risk Management: Errors in one increment (e.g., faulty salary calculation) are isolated and
resolved before moving forward.
4. Practical Implementation:
o Increment 1: Login and user management (Practical 1, 2).
o Increment 2: Employee registration and updates (Practical 4, 5).
o Increment 3: Attendance tracking and salary processing (Practical 6, 7).
o Increment 4: Report generation and deployment (Practical 8, 10).

Why Not Other Models?

• Waterfall: Too rigid for iterative lab tasks and feedback loops.
• Agile: Requires frequent requirement changes, which are restricted after project approval in an academic
setting.
• Spiral: Overly focuses on risk analysis, unnecessary for a small-scale project.
• V-Model: Strict phase-by-phase testing doesn’t align with incremental delivery.

Quiz:

1. Compare waterfall model and incremental model.

Aspect Waterfall Model Incremental Model

Structure Linear and sequential phases (no Divides the project into smaller,
overlap). manageable increments.
Flexibility Rigid; changes are difficult once a Flexible; allows changes between
phase is complete. increments.
Customer Minimal until the final product is Frequent feedback after each increment.
Involvement delivered.
Risk High risk (testing occurs late in the Low risk (risks are identified and resolved
Management lifecycle). early).
Suitability Best for projects with fixed, well- Ideal for modular projects with evolving
defined requirements. requirements (e.g., payroll system).

11
Software Engineering (3161605)

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.
Answer: False
Justification:
• The iterative waterfall model is rigid and sequential, with limited scope for
incorporating changes once a phase is completed.
• Customer feedback is only addressed in later iterations, which can delay issue
resolution and reduce satisfaction.
• Example: In the payroll project, iterative waterfall would delay testing until all modules
(login, salary, attendance) are fully developed, leading to late detection of integration
issues.

b) The loops for spiral model are fixed.

Answer: False
Justification:
• The spiral model is risk-driven and adaptive. Each loop (phase) varies in duration and
focus based on risk analysis.
• The number of loops is not fixed; they continue until all risks are mitigated and
stakeholders approve the product.
• Example: For the payroll system, spiral loops might focus first on high-risk areas like
salary calculation accuracy, then shift to user interface design in subsequent loops.

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

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

12
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

implementat implementat implementat implementat implementat
ion as asked ion as asked ion as asked ion as asked ion as asked
Problem Problem Problem Problem
analysis analysis analysis analysis
Development Development Development
of the Solution of the Solution of the Solution
Concept Concept
Clarity & Clarity &
understandin understandin
g g
Correct answer
to all questions

Signature of Faculty:

13
 Software Engineering (3161605)

Practical – 2
AIM: Discuss Project Management: Project Planning and Project Scheduling for the Mini Payroll Management
System.

Objectives:
1. To represent the plan to deliver the project scope over time.
2. To apply project scheduling techniques (Gantt chart, critical path analysis).
3. To use software metrics for cost estimation.

Theory:
Once a software project is found to be feasible, project planning becomes a crucial phase that must be
completed before any development activity begins. Project planning ensures that tasks are well-defined, resources
are allocated efficiently, and timelines are established for smooth project execution.
Among the key aspects of project planning, project-task scheduling plays a significant role in determining
the order, dependencies, and timelines of various project activities. A well-structured scheduling approach helps
in identifying critical tasks, optimizing resource allocation, and ensuring timely project completion.

Key Activities in Project Planning and Scheduling

1. Task Identification and Breakdown

The first step in project planning is identifying all the tasks required to complete the project. This involves
breaking down large tasks into smaller, manageable activities. Work Breakdown Structure (WBS) is used to
systematically organize tasks, ensuring that every aspect of the project is accounted for.

Example: Task Breakdown for a Mini Payroll System

Module Tasks
Login/User Management - Design UI for login and registration

2. Dependency Analysis
Once tasks are broken down, their dependencies must be established. If one task relies on the completion of
another, it must be scheduled accordingly.
Example: Dependency Analysis for Payroll System
• Login/User Management → Employee Management (User must be authenticated to manage
employees).
• Employee Management → Attendance Tracking (Employee data must exist before tracking
attendance).
• Attendance Tracking → Salary Processing (Salary depends on attendance records).
• All modules → Report Generation (Reports compile data from all modules).
Task dependencies define the order of execution, ensuring that interdependent tasks follow a logical sequence.

3. Time Estimation
Accurate estimation of time required for each task is crucial for setting realistic deadlines. The Constructive Cost
Model (COCOMO) or expert judgment methods can be used to estimate effort and duration.
Example: Estimated Duration for Payroll System
Using COCOMO estimation, the project effort is calculated as 14.17 person-months, and the total project
14
 Software Engineering (3161605)

duration is approximately 6.32 months. However, for a student team of three, the adjusted timeline is around 2.1
months.

Increment Tasks Duration

Increment 1 Login/User Management 2 weeks
Increment 2 Employee Management 3 weeks
Increment 3 Attendance Tracking 2 weeks
Increment 4 Salary Processing 3 weeks
Increment 5 Report Generation 2 weeks

4. Resource Allocation
Resource allocation ensures that every activity has the necessary manpower and tools. This process typically
involves assigning specific team members to tasks based on their expertise.
Example: Role-Based Resource Allocation
• Frontend Developer: Responsible for UI design and user interaction.
• Backend Developer: Handles database integration and business logic.
• Tester: Validates functionality and ensures performance efficiency.

5. Project Scheduling and Monitoring

Scheduling involves planning start and end dates for activities, often visualized using Gantt charts and PERT
charts.
Gantt Chart Representation
A Gantt chart (timeline chart) is a bar chart where each task is represented as a bar along a timeline. The length
of the bar corresponds to the estimated duration of the task.
Example: Gantt Chart Timeline for Payroll System
• Week 1-2: Login/User Management
• Week 3-5: Employee Management
• Week 6-7: Attendance Tracking
• Week 8-10: Salary Processing
• Week 11-12: Report Generation and Testing

Work January February March April

tasks

W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4

Problem
statement

Software
lifecycle
model

SRS

ERD

Data

15
 Software Engineering (3161605)

Dictionary

Level-0
DFD

Level-1
DFD

Level-2
DFD

Use Case
Diagram

Use Case
Description

Function
point
metrics

COCOMO
II Model

Risk
Analysis

Testing

2.1: Gantt Chart for Employee Payroll System

6. Critical Path Analysis

The Critical Path Method (CPM) identifies the longest sequence of dependent tasks, which determines the
minimum project completion time. Delays in any critical path task will directly impact the project deadline.
Example: Critical Path for Payroll System
Login → Employee Management → Attendance Tracking → Salary Processing → Report Generation
If there is a delay in the Salary Processing module (e.g., due to faulty calculation logic), the entire project
deadline will be affected.

16
 Software Engineering (3161605)

RISK CATEGORY PROBABILITY IMPACT

1. Size estimation may be PS 40% 2

significantly low
2. Larger number of users PS 60% 3
then planned
3. Less reuse then planned PS 30% 2

4.End user resist system BU 40% 3

5.Delivery date line will BU 60% 2

be tightened

6.Funding will be lost CU 30% 1

7.Technology will not TE 5% 1

meet expectations

8.Staff turnover will be ST 50% 2

high

2.1: Risk Analysis for the Payroll Project

17
 Software Engineering (3161605)

Quiz:

1. Explain the project scheduling process.

The project scheduling process involves:
1. Task Identification: Listing all activities (e.g., UI design, database setup).
2. Task Sequencing: Determining dependencies (e.g., attendance tracking requires employee data).
3. Time Estimation: Using metrics like COCOMO or expert judgment.
4. Resource Allocation: Assigning team members and tools.
5. Timeline Creation: Using Gantt/PERT charts to visualize schedules.
6. Critical Path Analysis: Identifying the longest task sequence to prioritize high-impact activities.
Example for Payroll Project:
• Critical Path: Login → Employee Management → Salary Processing. A delay in Employee
Management would delay the entire project.

2. Explain software metrics used for software cost estimation.

1. Function Points (FP):
o Measures software size based on user inputs, outputs, inquiries, files, and interfaces.
o Formula: FP = UFP × TCF (Unadjusted Function Points × Technical Complexity Factor).
o Payroll Project: Calculated as 169.6 FP (Practical 2).
2. COCOMO (Constructive Cost Model):
o Estimates effort (person-months) and duration based on lines of code (KLOC) and project
complexity.
o Object Points = 48 (19 screens + 2 reports).
o Effort = 48 / 7 ≈ 7 person-months (as calculated for the payroll system).
3. Halstead’s Metrics:
o Predicts effort using operators and operands in the code.
o Formula:
▪ Program Volume: V = N × log2(n)
▪ Effort: E = V / 18

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:

18
 Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked
Problem analysis Problem analysis Problem analysis Problem analysis
Development Development Development
of the of the Solution of the Solution
Solution
Concept Concept
Clarity & Clarity &
understanding understanding
Correct answer
to all questions

Signature of Facult

19
 Software Engineering (3161605)

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

Objectives:

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

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

Theory:

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

IEEE Template for SRS

Software Requirements
Specification
for
Payroll Management System
Version 1.0 approved
Prepared by Meet and Udit
Government Engineering College, Modasa
01-03-2025

20
Software Engineering (3161605)

Table of Contents

Revision History

Name Date Reason for Changes Version

Meet 1.0
Udit

2. Introduction

2.1 Purpose
This document specifies the requirements for the Library Management System v (LMS), designed
to automate cataloging, member registration, loan tracking, and reporting. It replaces manual processes to
improve efficiency and accuracy.

2.2 Document Conventions

• Bold text: Key terms.
• Italics: Glossary terms (see Appendix A).
• REQ-X: Functional requirements labeled with unique identifiers.
• Priorities: High, Medium, Low.

2.3 Intended Audience

• Librarians: Full access to system features.
• Members: Limited access (e.g., browsing books, viewing loans).
• Developers: For implementation and testing.

2.4 Product Scope

The LMS will:
• Manage book inventory (add, update, remove).
• Track member registrations and loan history.
• Calculate overdue fines automatically.
• Generate reports (loans, inventory, fines).
• Provide a secure web-based interface.

2.5 References
• IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications.
• User Interface Style Guide (Internal Document).

21
Software Engineering (3161605)

3. Overall Description

3.1: Use Case Diagram for the Employee Payroll System

3.1 Product Perspective

The LMS is a standalone system but may integrate with external databases or authentication services. It
replaces manual workflows and enhances library operations.

3.2 Product Functions

Function Description
Employee Management Add, update, or remove employees using employee ID, name, role, and salary.
Attendance Tracking Track employee attendance, leaves, and overtime.
Salary Calculation Calculate monthly salary based on attendance, deductions, and bonuses.
Payroll Reporting Generate PDF/Excel reports for payroll, tax summaries, and employee
payslips.

22
Software Engineering (3161605)

3.3 User Classes and Characteristics

User Class Characteristics

HR Admin Admin privileges: Full access to employee records, payroll, and reporting.
Employees Limited access: View their own payslips, attendance, and tax details.

3.4 Operating Environment

• Frontend: Web-based (HTML, CSS, JavaScript).

• Backend: Python/Django framework.
• Database: MySQL.
• OS: Windows 10/11, Linux (Ubuntu 22.04 LTS).

3.5 Design and Implementation Constraints

• Use responsive design for mobile compatibility.

• Follow OWASP security guidelines for data encryption.

3.6 User Documentation

• User Manual: PDF/online guide with step-by-step instructions.

• In-App Help: Context-sensitive help tooltips.

3.7 Assumptions and Dependencies

• Stable internet connection required.

• Dependency on third-party payment gateways for fine processing (TBD).

4. External Interface Requirements

4.1 User Interfaces

Screen Description
Login Page Role-based access (librarian/member).
Dashboard Overview of total books, active loans, and pending
fines.
Search Interface Search books by title, author, ISBN, or category.

4.2 Hardware Interfaces

• Barcode scanners for quick book check-in/out.
• Standard PCs/tablets for system access.

4.3 Software Interfaces

• Email Service: Send automated reminders for due dates (e.g., SMTP).
• Payment Gateway: Integrate with services like PayPal/Razorpay (TBD).

23
Software Engineering (3161605)

4.4 Communications Interfaces

• HTTPS: Secure data transmission.
• REST API: For future integration with mobile apps.

5. System Feature

System Feature

5.1 Book Management

Priority: High
• REQ-1: Librarians shall add books by entering ISBN, title, author, and category.
• REQ-2: System shall validate ISBN format (13 digits).

5.2 Member Management

Priority: High
• REQ-3: Members can register by providing name, email, and phone number.
• REQ-4: Librarians can deactivate members with overdue fines.

5.3 Loan Management

Priority: High
• REQ-5: Calculate fines at ₹10/day for overdue books.
• REQ-6: Members can borrow up to 5 books simultaneously.

5.4 Reporting
Priority: Medium
• REQ-7: Generate monthly loan reports in PDF/Excel

6. Other Nonfunctional Requirements

6.1 Performance Requirements

• Support 100 concurrent users with a response time <2 seconds.

24
Software Engineering (3161605)

6.2 Safety Requirements

• Daily encrypted backups of the database.

6.3 Security Requirements

• Encrypt passwords using bcrypt hashing.
• Role-based access control (RBAC) for user permissions.

6.4 Software Quality Attributes

• Usability: Intuitive interface for non-technical users.
• Maintainability: Modular codebase with documentation.

6.5 Business Rules

• Fines accrue after 7 days.
• Members with overdue books cannot borrow new items.

7. Other Requirements
• Internationalization: Support for English and regional languages (TBD).

8. Appendices
Appendix A: Glossary

Term Definition
ISBN 13-digit International Standard Book Number.
Check-out Process of borrowing a book.

Appendix B: Analysis Models

• Use Case Diagram: Illustrates interactions between users and system.
• ER Diagram: Defines database schema for books, members, and loans.

Appendix C: To Be Determined List

Item Description
Payment Gateway Integration Finalize third-party service for fine payments.
Multilingual Support Add support for regional languages.

Revision History

Name Date Reason For Changes Version

25
Software Engineering (3161605)

Introduction
Purpose
This document specifies the requirements for the Library Management System (LMS), a software
solution designed to automate library operations such as book cataloging, member registration, loan
tracking, and report generation. It replaces manual workflows to improve efficiency, accuracy, and
user experience.

Document Conventions

• Bold text: Key terms or system components.

• Italics: Glossary terms (see Appendix A).

• REQ-X: Functional requirements labeled with unique identifiers (e.g., REQ-1).

• Priorities: High, Medium, Low (assigned to each requirement).

Product Scope
The LMS will:
• Manage book inventory (add, update, remove).
• Track member registrations and loan history.
• Automatically calculate overdue fines.
• Generate reports (loans, inventory, fines).
• Provide a secure web-based interface for librarians and members.

References
• IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications.
• User Interface Style Guide (Internal Document).

Overall Description

Product Perspective
The LMS is a standalone system but may integrate with external databases or authentication
services. It replaces manual record-keeping and streamlines library workflows, reducing human error
and operational costs.

26
Software Engineering (3161605)

Product Functions

Function Description
Book Management Add, update, or remove books using ISBN, title, author, and category.
Member Management Register, update, or deactivate members.
Loan Management Track check-outs, check-ins, and calculate overdue fines.
Reporting Generate PDF/Excel reports for loans, inventory, and financial summaries.

User Classes and Characteristics

User Class Characteristics

Librarians Admin privileges: Full access to system features.
Members Limited access: Browse books, view loan history, and pay fines via the interface.

Operating Environment

• Frontend: Web-based (HTML, CSS, JavaScript).

• Backend: Python/Django framework.
• Database: MySQL.
• OS: Windows 10/11, Linux (Ubuntu 22.04 LTS).

Design and Implementation Constraints

• Use responsive design for mobile compatibility.

• Follow OWASP security guidelines for data encryption.

User Documentation
• User Manual: PDF/online guide with step-by-step instructions.
• In-App Help: Context-sensitive tooltips for key features.

Assumptions and Dependencies

• Stable internet connection required.

• Dependency on third-party payment gateways for fine processing (TBD).

27
Software Engineering (3161605)

External Interface Requirements

User Interfaces
• Login Page: Role-based access (librarian/member).
• Dashboard: Summary of total books, active loans, and pending fines.
• Search Interface: Search books by title, author, ISBN, or category.

Hardware Interfaces

• Barcode scanners for quick book check-in/out.

• Standard PCs/tablets for system access.

Software Interfaces
• Email Service: Send automated reminders for due dates (e.g., SMTP).
• Payment Gateway: Integrate with services like PayPal/Razorpay (TBD).

Communications Interfaces
• HTTPS: Secure data transmission.
• REST API: For future integration with mobile app

System Features

System Feature 1
4.1.1 Description and Priority
Priority: High
• REQ-1: Librarians shall add books by entering ISBN, title, author, and category.
• REQ-2: System shall validate ISBN format (13 digits).

4.1.2 Stimulus/Response Sequences

Priority: High
• REQ-3: Members can register by providing name, email, and phone number.
• REQ-4: Librarians can deactivate members with overdue fines.

4.1.3 Functional Requirements

Priority: High
• REQ-5: Calculate fines at ₹10/day for overdue books.
• REQ-6: Members can borrow up to 5 books simultaneously.

28
Software Engineering (3161605)

4.1.4 Reporting
Priority: Medium
• REQ-7: Generate monthly loan reports in PDF/Excel.

System Feature 2 (and so on)

Other Nonfunctional Requirements

Performance Requirements
• The system shall support 100 concurrent users with a response time <2 seconds for all
user actions.
• Scalability: The system shall be designed to handle a 20% annual increase in users and
data volume without performance degradation.

Safety Requirements
• Data Integrity: Implement transaction rollback mechanisms to recover from system failures
during check-in/check-out processes.
• Backups: Daily encrypted backups of the database stored in a secure offsite location.

Security Requirements
• Authentication: Password encryption using bcrypt hashing.
• Authorization: Role-based access control (RBAC) to restrict member access to
administrative functions.
• Data Encryption: HTTPS for secure data transmission; sensitive data (e.g., passwords,
payment details) encrypted at rest.
• Compliance: Adhere to GDPR for user data protection.

Software Quality Attributes

• Usability: Achieve a 90% user satisfaction rate via intuitive UI/UX (measured through
post-deployment surveys).
• Maintainability: Modular codebase with documentation for easy updates.
• Reliability: Ensure 99.9% uptime (excluding scheduled maintenance).
• Portability: Compatibility with Windows 10/11 and Linux (Ubuntu 22.04 LTS).

Business Rules
• Members with overdue books are automatically blocked from borrowing new items.
• Fines accrue at ₹10/day starting 7 days after the due date.
• Maximum 5 books per member can be borrowed simultaneously.

Other Requirements

• Legal Compliance: Adhere to local library regulations for data retention and user privacy.
• Internationalization: Support for English and regional languages (e.g., Hindi, Tamil) to be
added in Phase 2.

29
Software Engineering (3161605)

Appendix A: Glossary
Term Definition
ISBN 13-digit International Standard Book Number.
Check-out Process of borrowing a book.

Appendix B: Analysis Models

• Use Case Diagram: Illustrates interactions between librarians, members, and the system
(e.g., book search, loan management).

• ER Diagram: Defines database schema for entities like Books, Members, and Loans.

Appendix C: To Be Determined List

Item Description
Payment Gateway Integration Finalize third-party service for fine payments.
Multilingual Support Add support for regional languages.

Quiz:

1. Which are properties of good SRS?

1. Correctness: Accurately reflects user needs (e.g., "Calculate fines at ₹10/day for overdue books" in
the LMS).
2. Completeness: Covers all user and system requirements (e.g., includes book management, member
management, and reporting).
3. Consistency: No conflicting requirements (e.g., "Members can borrow up to 5 books" does not
contradict other rules).
4. Unambiguity: Clear and precise language (e.g., "ISBN validation ensures 13 digits").
5. Modifiability: Easy to update (e.g., modular documentation for future integrations like payment
gateways).
6. Verifiability: Requirements can be tested (e.g., "Response time <2 seconds" is measurable).
7. Traceability: Links requirements to their origin (e.g., REQ-1 traces back to the "Book
Management" feature).

2. What is functional and non-functional requirement?

Functional Requirements
Define what the system must do. These are specific actions or behaviors the system performs.
Examples from the LMS:
• REQ-1: Add books with ISBN, title, author, and category.
• REQ-5: Calculate fines for overdue books.
• REQ-7: Generate monthly reports in PDF/Excel.

30
 Software Engineering (3161605)

Non-Functional Requirements
Define how the system performs. These describe system qualities, constraints, and standards.
Examples from the LMS:
• Performance: Support 100 concurrent users with <2s response time.
• Security: Encrypt passwords using bcrypt hashing.
• Usability: Achieve 90% user satisfaction via an intuitive interface.
• Reliability: Ensure 99.9% uptime (excluding maintenance).

Key Difference:
• Functional: What the system does (e.g., manage loans).
• Non-Functional: How well the system does it (e.g., securely, quickly, reliably).

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
Complete Complete Complete Complete Complete
Marks implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked
Problem analysis Problem analysis Problem analysis Problem analysis
Development Development Development
of the Solution of the Solution of the Solution
Concept Clarity Concept Clarity
& &
understanding understanding
Correct answer to
all questions

Signature of Faculty

31
Software Engineering (3161605)

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

• Objectives:
To model the flow of data in the Mini Payroll Management System using Data Flow Diagrams (DFDs)
at different levels (Context, Level 1, Level 2).

• Theory:

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

Extern Interacts with the system (e.g., Admin).

al
entity

Process Transforms data (e.g., "Calculate Salary").

Data store Holds data (e.g., "Employee Database").

Data flow Holds data (e.g., "Employee Database").

32
 Software Engineering (3161605)

Explanation of Symbols used in DFD

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

Levels of DFD

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

• 0-level DFD: The primary external entities (boxes) produce information for use by the
system and consume information generated by the system

Level 0 DFD (Context Diagram)

• System: Mini Payroll Management System (central process).
• External Entities: Admin, Database.
• Key Data Flows:
o Inputs: Login credentials, employee data, attendance records.
o Outputs: Reports (salary slips, attendance), updated database.

33
Software Engineering (3161605)

Fig 4.1: Context Diagram for the Payroll System

• 1-level DFD: It represents the main functions of the system and how they interact with
each other.

Level 1 DFD
Decomposes the system into core sub-processes:
1. Login Management
2. User Management
3. Employee Management
4. Attendance Management
5. Salary Management
6. Report Generation

Data Stores:
• User Data, Employee Data, Attendance Data, Salary Data.

34
Software Engineering (3161605)

Fig 4.2: Level 1 DFD for the Payroll System

• 2-level DFD: It represents the processes within each function of the system and how they
interact with each other.

35
Software Engineering (3161605)

Fig 4.3: Level 2 DFD for Login Module

Breaks down the "Salary Management" process:

1. Calculate Daily Salary
o Input: Attendance records, salary per annum.
o Process: Compute per-day salary.
2. Apply Deductions
o Input: LOP (Loss of Pay) days.
o Process: Deduct salary for absent days.
3. Update Salary Records
o Output: Updated salary data stored in the database.
o

• Tools / Material Needed:

o Hardware:
External Entity: Rectangle
Process: Circle
Data Store: Open Rectangle
Data Flow: Labeled Arrow

36
Software Engineering (3161605)

o Software:
Lucidchart, Draw.io, or Visio for diagramming

Quiz:

1. In a data flow diagram, does an arrow represent a flow of control or something else?
Answer:
In a Data Flow Diagram (DFD), an arrow does NOT represent a flow of control. Instead, it represents
the flow of data between components of the system.

• What the arrow signifies:

o Data Flow: The arrow shows how data moves between external entities, processes, and data
stores.
o Example:
▪ If an admin inputs employee attendance data, the arrow would show the flow of
"Attendance Data" from the "Admin" (external entity) to the "Attendance Management"
process.

• Difference from control flow:

o In flowcharts or UML activity diagrams, arrows often represent the order of operations (control
flow).
o In DFDs, arrows only depict data movement, not the sequence of steps.

2. What is “information flow continuity” and how is it applied as a data flow diagram is refined?
Answer:
Information flow continuity ensures consistency between DFD levels. When refining a DFD from a
high-level (e.g., Level 0) to a detailed level (e.g., Level 1 or 2), the inputs and outputs of a parent process
must match those of its child processes.

• How it works:
o Level 0 (Context Diagram): Shows the system as a single process with inputs/outputs.
o Level 1: Breaks the Level 0 process into sub-processes. All data flows entering/exiting the Level
0 process must appear in Level 1.
o Level 2: Further decomposes Level 1 processes. The inputs/outputs of each sub-process must
align with its parent process.

• Example:
o Level 0: The system receives "Employee Data" as input and generates "Salary Report" as output.
o Level 1: The "Salary Management" process (a child of Level 0) must also accept "Employee
Data" and produce "Salary Report."

• Purpose:
o Prevents data loss or inconsistency during decomposition.
o Ensures traceability across DFD levels.

37
Software Engineering (3161605)

3. What are the advantages of DFD?

Answer:
DFDs offer several benefits in system analysis and design:
1. Visual Clarity:
o Simplifies complex systems by breaking them into hierarchical, easy-to-understand
diagrams.
o Example: A payroll system’s data flow is split into processes like "Login," "Salary
Calculation," and "Report Generation."

2. Focus on Data Movement:

o Highlights how data is transformed (e.g., raw attendance data → processed salary).
o Identifies data dependencies (e.g., salary calculation requires attendance records).

3. Facilitates Communication:
o Bridges gaps between technical teams and non-technical stakeholders (e.g., clients,
managers).
o Example: A DFD helps a client visualize how their employee data flows through the system.

4. Identifies Redundancies and Errors:

o Exposes duplicate processes (e.g., two modules updating the same data store).
o Detects missing data flows (e.g., salary reports not being generated due to a broken flow).

5. Supports System Design:

o Acts as a blueprint for developers to code the system.
o Guides database design by clarifying data storage needs (e.g., "Employee Database" vs.
"Salary Database").

6. Documentation:
o Serves as a reference for future upgrades or troubleshooting.

Suggested Reference:

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

International Editions

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

References used by the students:

38
Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked
Problem analysis Problem analysis Problem analysis Problem analysis
Development of Development of Development of
the Solution the Solution the Solution
Concept Clarity Concept Clarity
& &
understanding understanding
Correct answer
to all questions

Signature of the Facul

39
Software Engineering (3161605)

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

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

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

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

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

The Entity-Relationship (ER) model is used to abstract real-world objects (entities) and their
relationships. Key components include:
• Entity Sets: Collections of similar entities (e.g., Employee, User).
• Attributes: Properties describing entities (e.g., EmpID, Salary).
• Relationships: Associations between entities (e.g., "manages," "has").
• Keys:
o Primary Key (PK): Uniquely identifies an entity (e.g., EmpID).
o Foreign Key (FK): Links entities (e.g., EmpID in Attendance references Employee).
• Weak Entities: Depend on another entity for identity (e.g., Attendance depends on Employee).

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.

40
Software Engineering (3161605)

1. Entity Sets

Entity Attributes Primary Key

User UserID, Name, Email, Password, Role, Address, UserID
DateOfBirth
Employee EmpID, Name, PAN, BankDetails, Mobile, EmpID
Email, Address, DateOfBirth
Attendance EmpID (FK), Year, Month, TotalDays, (EmpID, Year,
WorkingDays, PresentDays, AbsentDays, LOP Month)
Salary EmpID (FK), JoinDate, SalaryPerAnnum EmpID

2. Relationships
Relationship Entities Cardinality Description
Involved
Manages User (Admin) 1:N One admin user can
→ Employee manage multiple
employees.
Has_Attendance Employee → 1:N One employee can have
Attendance multiple attendance
records (e.g., monthly
entries).
Has_Salary Employee → 1:1 One employee has one
Salary salary entry (updated
over time).

3. Weak Entities
• Attendance: Depends on Employee (identified by EmpID + Year + Month).
• Salary: Depends on Employee (identified by EmpID).

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.

41
Software Engineering (3161605)

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.

1. User: Admins manage employees. Attributes include credentials and role.

2. Employee: Core entity with personal and job-related details.
3. Attendance: Weak entity linked to Employee via EmpID. Tracks monthly attendance.
4. Salary: Weak entity storing salary details for each employee.

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

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

Entity Generalization and Specialization

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

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

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

42
Software Engineering (3161605)

One to one: An entity in E1 is related to at most a single entity in E2, and vice versa
One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in E2 could
be related to at most a single entity in E1.

Many to one: Zero or more number of entities in E1 could be associated to a single entity in E2.
However, an entity in E2 could be related to at most one entity in E1.

Many to many: Any number of entities could be related to any number of entities in E2, including
zero, and vice versa.

ER Diagram
From a given problem statement we identify the possible entity sets, their attributes, and
relationships among different entity sets. Once we have these information, we represent them
pictorially, called an entity-relationship (ER) diagram.

43
 Software Engineering (3161605)

Fig 5.1: ER Diagram for the Employee Payroll System

Data Design:

1. Name: ADMIN

Sr.No. Field Data Type Field Constraints Description Example

Name Length
1. AId Numeric 5 Primary Key Unique Admin 29045
ID
2. SSN Numeric 8 Not Null System Security 11902378
Number
Table 5.1: Entity-Attribute Mapping for Admin

44
 Software Engineering (3161605)

2. Name: EMPLOYEE

Sr.No. Field Name Data Field Constraints Description Example

Type Length
1. Name Char 50 Not Null Employee Suresh Kumar
Name
2. EId Numeric 3 Primary Key Employee ID 198
3. Contact no. Numeric 10 Not Null Contact 9811100000
numbers
4. Email ID Char 50 Not Null Employee mail [email protected]
ID
5. Address Char 50 Unique Full address 11 A, abc society
,Delhi-91
6. Designation Char 20 Not Null Designation Manager
assigned
Table 5.1: Entity-Attribute Mapping for Employee

3. Name: TAX

Sr.No. Field Name Data Type Field Constraints Description Example

Length
1. EId Numeric 3 Primary Key Employee ID 239
2. TDS Float 10 Not Null Tax deducted 2380
according to
slab
3. EPF Float 10 Not Null Employee PF 235
tax
4. Ptax Float 10 Not Null Professional 540
tax
Table 5.1: Entity-Attribute Mapping for Tax

4. Name : Work-Hour
Sr.No. Field Name Data Type Field Constraints Description Example
Length
1. EId Numeric 3 Primary Key Employee ID 239
2. Min.Hours Numeric 2 Not Null Minimum hours 6
to complete by
employee
3. Hours Worked Numeric 3 Not Null Number of 30
hours worked in
a month
4. Holiday Numeric 2 Not Null Number of 3
Holidays
availed in a
month
Table 5.1: Entity-Attribute Mapping for Work Hour

45
 Software Engineering (3161605)

5. Name: SALARY
Sr.No. Field Name Data Type Field Constraints Description Example
Length
1. EId Numeric 3 Primary Key Employee ID 239
2. HRA Float 5 Not Null HRA added on 2300
basic
3. DA Float 4 Not Null DA added on 2378
basic
4. MA Float 4 Not Null MA added on 5678
basic
5. Basic Float 8 Not Null Basic Salary 30000
Table 5.1: Entity-Attribute Mapping for Salary

Quiz:

1. What is a Weak Entity Set?

Answer:
A weak entity set is an entity set that cannot be uniquely identified by its own attributes and depends on
another entity set (called the owner entity) for its existence.

• Key Characteristics:
o No Primary Key: It lacks a primary key (a unique identifier) and uses a foreign key from the
owner entity set.
o Partial Key: It may have a discriminator (or partial key) that, combined with the owner’s primary
key, uniquely identifies a weak entity.
o Total Participation: Weak entities always depend on the owner entity (e.g.,
an Attendance record cannot exist without an Employee).

Example from Payroll Management System:

• Entity Set: Attendance
o Attributes: EmpID (foreign key), Year, Month, TotalDays, WorkingDays, etc.
o Dependency: The Attendance entity is weak because it uses EmpID (from Employee)
+ Year + Month as its identifier.

Why It Matters:
Weak entity sets model real-world dependencies (e.g., attendance data is meaningless without an employee).

2. What is Mapping Cardinality?

Answer:
Mapping cardinality (or cardinality ratio) defines how many entities in one entity set can be associated with
entities in another entity set through a relationship. It specifies the numerical constraints of relationships.

Types of Cardinality:
1. One-to-One (1:1)
o One entity in set A is linked to at most one entity in set B, and vice versa.
o Example: A Salary record is assigned to exactly one Employee, and an Employee has only

46
 Software Engineering (3161605)

one Salary.

2. One-to-Many (1:N)
o One entity in set A can be linked to multiple entities in set B, but an entity in set B is linked to only
one entity in set A.
o Example: One User (Admin) can manage many Employee records, but an Employee is managed
by only one Admin.

3. Many-to-One (N:1)
o Opposite of 1:N. Many entities in set A are linked to one entity in set B.
o Example: Many Attendance records (for different months) belong to one Employee.

4. Many-to-Many (M:N)
o Entities in set A can be linked to multiple entities in set B, and vice versa.
o Example: In a university system, a Student can enroll in many Courses, and a Course can
have many Students.

Example from Payroll Management System:

• Relationship: Manages (User → Employee)
o Cardinality: 1:N (One Admin User manages many Employees).

Why
Cardinality ensures data integrity by defining how relationships behave (e.g., preventing duplicate salary entries
for an employee).

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 Development Development
of the of the Solution of the Solution
Solution
Concept Concept
Clarity & Clarity &
understanding understanding
Correct answer
to all questions

47
 Software Engineering (3161605)

Signature of Faculty:

48
Software Engineering (3161605)

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

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

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

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

49
Software Engineering (3161605)

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

Background / Preparation:

How to draw a Use Case diagram?

Fig 6.1: Use Case Diagram for the Employee Payroll System

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.

50
 Software Engineering (3161605)

Once both the actors and use cases are enlisted, the relation between the actor and use case/ system
is inspected. It identifies the no of times an actor communicates with the system. Basically, an
actor can interact multiple times with a use case or system at a particular instance of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable
way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.
The purposes of use case diagrams can be as follows:

• Used to gather requirements of a system.

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

A description of the state when the scenario finishes.

Steps to Draw a Use Case Diagram:

1. Identify Actors: Determine external entities interacting with the system (e.g., Admin, Employee).
2. Define Use Cases: List functionalities (e.g., Login, Generate Reports).
3. Establish Relationships: Link actors to use cases and define include/extend dependencies.
4. Define System Boundary: Enclose use cases within a box labeled with the system name.

Rules:
• Use clear, descriptive names for actors and use cases.
• Avoid overcrowding; split complex diagrams into smaller ones.

Procedure / Steps
Use Case Diagram for Mini Payroll Management System

51
 Software Engineering (3161605)

Actors:
1. Admin: Manages system operations (e.g., user/employee management).
2. Employee: Views personal details and payslips.

Use Cases:
1. Login: Authenticate user credentials.
2. Manage User: Register, update, or delete user profiles.
3. Manage Employee: Add, modify, or remove employee records.
4. Generate Reports: Create payroll, attendance, or salary reports.
5. Calculate Salary: Compute salary based on attendance.

Relationships:
• Association: Admin ↔ Manage User, Manage Employee, Generate Reports.
• Include: Login is included in all admin/employee actions.
• Extend: "Forgot Password" extends the Login use case.

Scenarios
1. Login Scenario:
o Actor: Admin/Employee.
o Flow: User enters credentials; system validates and grants access.
o Exception: Invalid credentials trigger an error message.
2. Generate Salary Report:
o Actor: Admin.
o Flow: Admin selects "Generate Report," system compiles salary data into a PDF.
o Post-Condition: Report saved in the database.
3. Update Employee Details:
o Actor: Admin.
o Flow: Admin edits employee records (e.g., bank details), system updates the database.

Below are real-world use case descriptions from the Employee Payroll System project:

1. Use Case: Login

Description:
"Brief Description: Allows Admin or Employee to access the system using valid credentials.
Actors: Admin, Employee.
Flow of Events:
• Basic Flow:
1. System prompts for User ID, Password, and Role (Admin/Employee).
2. User enters credentials.
3. System validates credentials against the database.
4. If valid, access is granted to the respective dashboard.
• Alternative Flow:
1. Invalid credentials trigger an error message: “Invalid ID/Password. Try again.”
2. User retries or cancels login.
Special Requirements: Password encryption (bcrypt hashing).
Pre-Conditions: User must have a registered account.
Post-Conditions: On success, user gains role-based access."

52
 Software Engineering (3161605)

2. Use Case: Generate Payslip

Description:
"Brief Description: Generates a payslip for an employee with salary details.
Actors: Employee.
Flow of Events:
• Basic Flow:
1. Employee selects “Generate Payslip” from the dashboard.
2. System retrieves salary data (gross pay, deductions, net pay).
3. Payslip is displayed as a PDF; employee can download or print it.
• Alternative Flow:
1. If no salary data exists, system displays: “Payslip not available for this month.”
Special Requirements: PDF formatting compliant with company standards.
Pre-Conditions: Salary must be calculated for the current month.
Post-Conditions: Payslip is saved to the database."

3. Use Case: Salary Revision

Description:
"Brief Description: Admin updates salary components (e.g., HRA, DA) for an employee.
Actors: Admin.
Flow of Events:
• Basic Flow:
1. Admin selects “Salary Revision” and enters Employee ID.
2. System displays current salary structure.
3. Admin edits fields (e.g., Basic, HRA, Tax%).
4. System validates and updates the database.
• Alternative Flow:
1. Invalid Employee ID triggers error: “Employee not found.”
Special Requirements: Audit trail for salary changes.
Pre-Conditions: Admin must be logged in.
Post-Conditions: Updated salary reflects in the next payroll cycle."

Tools / Material Needed:

Hardware:
• Computer/Laptop: A standard computer or laptop with sufficient processing power to run
diagramming software (minimum 4GB RAM, 2GHz processor).
• Internet Connection: Required for accessing web-based UML tools (e.g., Lucidchart, draw.io).
Software:
1. UML Diagramming Tools:
o Lucidchart: A web-based tool for creating UML diagrams with drag-and-drop functionality.
o draw.io: Free online tool for designing use case diagrams (no installation required).
o Microsoft Visio: Desktop application for professional-grade diagrams (supports UML
standards).

53
 Software Engineering (3161605)

o Visual Paradigm: Advanced UML modeling software with collaborative features.

o PlantUML: Open-source tool for generating diagrams from text-based syntax.

2. Documentation Software:
o Microsoft Word/Google Docs: For documenting scenarios, use cases, and quiz answers.
o Markdown Editors: Tools like Typora or VS Code for formatting reports.
3. Collaboration Tools (Optional):
o Miro/Whimsical: For team-based brainstorming and diagram refinement.

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

Quiz:
1. What are the four main components of a use case diagram?
o Actors: External entities interacting with the system (e.g., Admin, Employee).
o Use Cases: Functionalities or tasks the system performs (e.g., Login, Generate Reports).
o Relationships: Connections between actors and use cases (e.g., association, include, extend).
o System Boundary: A box enclosing use cases to define the system’s scope (labeled with the
system name, e.g., "Mini Payroll Management System").
Example from Practical:
o In the Mini Payroll System, the Admin actor is linked to use cases like "Manage Employee"
and "Generate Reports," all enclosed within the system boundary.
2. List relationships used in use case diagrams.
o Association: A line connecting an actor to a use case (e.g., Admin → Manage Employee).
o Include: A mandatory relationship where one use case requires another (e.g., Login
is included in all actions like "Generate Reports").
o Extend: An optional relationship for conditional behavior (e.g., "Forgot
Password" extends the Login use case).
o Generalization: Inheritance between actors or use cases (e.g., "Admin" and "Employee"
could generalize to a "User" actor).
Example from Practical:
o The "Forgot Password" use case extends the Login functionality, indicating it is an optional
scenario.
3. What tests can help find useful use cases?
o Scenario Testing: Validate if use cases cover real-world workflows (e.g., testing the
"Calculate Salary" use case with sample attendance data).
o Requirement Traceability Matrix (RTM): Map use cases to requirements to ensure coverage

54
 Software Engineering (3161605)

(e.g., linking "Generate Reports" to the requirement for payroll transparency).

o User Acceptance Testing (UAT): Confirm use cases meet end-user needs (e.g., verifying that
employees can view payslips).

oFunctional Testing: Test each use case’s functionality (e.g., ensuring "Manage User"
correctly updates profiles).
Example from Practical:
o During UAT, the Admin verified that the "Generate Reports" use case produced accurate
salary slips, aligning with user expectations.

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 Development Development
of the of the Solution of the Solution
Solution
Concept Concept
Clarity & Clarity &
understanding understanding
Correct answer
to all questions

55
 Software Engineering (3161605)

Signature of Faculty:

56
Software Engineering (3161605)

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

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

• Theory

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

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

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

The concept of organic, semidetached, and embedded systems are described below.

57
Software Engineering (3161605)

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

Basic COCOMO Model

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

where

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

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

OBJECT TYPE COMPLEXITIY WEIGHT

SIMPLE MEDIUM DIFFICULT
SCREEN 1 2 3
REPORT 2 5 8
3GL COMPONENT 10

Table 7.1: COCOMO II Complexity Weights for the Payroll System

58
Software Engineering (3161605)

Fig 7.1: COCOMO Effort Calculation Steps for the Payroll System

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.

Given:
• Object Points = 48 (19 screens + 2 reports).
• Productivity Rate = 7 (low).
• Effort = 48 / 7 ≈ 7 person-months.

Step 1: Calculate Effort (PM)

Using the formula:
Effort=a×(KDSI)bEffort=a×(KDSI)b
Substitute values for organic projects (a=2.4a=2.4, b=1.05b=1.05):
Effort=2.4×(32)1.05Effort=2.4×(32)1.05

Calculation:
• 321.05=321×320.05321.05=321×320.05
• 320.05=e0.05×ln⁡(32)320.05=e0.05×ln(32)
o ln⁡(32)≈3.4657ln(32)≈3.4657
o 0.05×3.4657≈0.17330.05×3.4657≈0.1733
o e0.1733≈1.19e0.1733≈1.19

59
Software Engineering (3161605)

• 321.05≈32×1.19=38.08321.05≈32×1.19=38.08
• Effort = 2.4×38.08≈91.39 person-months2.4×38.08≈91.39 person-months

Step 2: Calculate Nominal Development Time (Tdev)

Using the formula:
Tdev=2.5×(Effort)cTdev=2.5×(Effort)c
Substitute values for organic projects (c=0.38c=0.38):
Tdev=2.5×(91.39)0.38Tdev=2.5×(91.39)0.38

Calculation:
• ln⁡(91.39)≈4.515ln(91.39)≈4.515
• 0.38×4.515≈1.71570.38×4.515≈1.7157
• e1.7157≈5.56e1.7157≈5.56
• Tdev = 2.5×5.56≈13.9 months2.5×5.56≈13.9 months

Step 3: Calculate Total Cost

Total Cost=Effort×Salary per person-monthTotal Cost=Effort×Salary per person-
monthTotal Cost=91.39×15,000=₹1,370,850Total Cost=91.39×15,000=₹1,370,850

Quiz Answer
1. Effort Required: 91.39 PM91.39 PM
2. Development Time: 13.9 months13.9 months
Total Cost: ₹1,370,850₹1,370,850

Suggested Reference:

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

International Editions

60
 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

implementa implementatio implementatio implementatio implemen
tion as n as asked n as asked n as asked tation as
asked asked
Problem analysis Problem analysis Problem analysis Problem
analysis
Development of Development of Developme
the Solution the Solution nt of the
Solution
Concept Concept
Clarity & Clarity &
understanding understan
ding
Correct
answer to all
questions

Signature of Faculty:

61
Software Engineering (3161605)

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

Objectives:

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

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

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

Elements in class diagram

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

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

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

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

Example

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

62
Software Engineering (3161605)

Admin
Aid Int (PK)
SSN Int

Employee
Eid int (PK)
Name string
Contact string
Salary float

Salary
Eid int (FK)
Basic float
HRA float
DA float

Tax
Eid int (FK)
TDS float
EPF float

Relationships:
Admin -- Manages --> Employee (1:N)
Employee -- Has --> Salary (1:1)
Employee -- Has --> Tax (1:1)

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

63
 Software Engineering (3161605)

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

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

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

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

Example

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

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

64
Software Engineering (3161605)

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

Example

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

Composition [i]

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

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

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

65
Software Engineering (3161605)

o Sequence diagram:
▪ The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios. It
portrays the communication between any two lifelines as a time-ordered sequence
of events, such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a vertical
dotted line that extends across the bottom of the page. It incorporates the iterations
as well as branching.

o Purpose of a Sequence Diagram

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

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

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.

66
Software Engineering (3161605)

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.

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.

67
Software Engineering (3161605)

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.

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

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

68
 Software Engineering (3161605)

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.

Diagram For Each Operation :

1) Add Employee :

2) Delete Employee :

69
 Software Engineering (3161605)

3) Update Employee :

SEQUENCE DIAGRAM :-

A sequence diagram in Unified Modelling Language (UML) is a kind of interaction diagram that shows how
processes operate with one another and in what order. It is a construct of a Message Sequence Chart.

70
Software Engineering (3161605)

Sequence Diagram

Quiz:

1. In a sequence diagram:
(a) What does a box depict?
• Box (Lifeline): A rectangular box at the top of a sequence diagram represents a lifeline, which is an
object or actor participating in the interaction.
o Example: In a library system, a lifeline could be User, Book, or Database.
o Purpose: Shows the existence of an object/actor over time.

71
Software Engineering (3161605)

(b) What does a dashed line depict?

• Dashed Line (Lifeline Timeline): The vertical dashed line descending from a lifeline box represents
the passage of time during which the object exists or is active.
o Example: For a User lifeline, the dashed line shows the user’s interaction timeline from login
to logout.
o Key Feature: Time flows from top to bottom.

(c) What does an arrow between boxes depict?

• Arrow (Message): An arrow between two lifelines represents a message (communication or
interaction) between objects.

o Types of Messages:
1. Synchronous Call (Solid Line with Filled Arrowhead): A method call that waits for a
response (e.g., user → System: login()).
2. Return Message (Dashed Line with Open Arrowhead): Response to a synchronous
call (e.g., System → user: success).
3. Asynchronous Message (Solid Line with Half Arrowhead): A non-blocking message
(e.g., System → EmailService: sendConfirmation()).

o Example: In an e-commerce system, a Customer sends a placeOrder() message to

the OrderManager.

2. What does an X over a lifeline indicate?

• X (Destruction Marker): An X at the end of a lifeline indicates the destruction or deletion of the
object.
o Purpose: Shows when an object is removed from memory or ceases to exist.
o Trigger: Typically follows a «destroy» message.
o Example: After a User logs out, the Session object is destroyed, marked by an X on its lifeline.

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:

72
 Software Engineering (3161605)

Rubric wise marks obtained:

Rubric 1 2 3 4 5 Total
s
Marks Complete Complete Complete Complete Complete
implementatio implementatio implementatio implementatio implementa
n as asked n as asked n as asked n as asked tion as
asked
Problem analysis Problem analysis Problem analysis Problem
analysis
Development of Development of Development
the Solution the Solution of the
Solution
Concept Concept
Clarity & Clarity &
understanding understandi
ng
Correct
answer to all
questions

Signature of Faculty:

73
Software Engineering (3161605)

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

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

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

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.
▪ Verification answers the question– "Are we developing this product by firmly
following all design specifications ?"
▪ Verifications concentrates on the design and system specifications.

o Target of the test are -

• Errors - These are actual coding mistakes made by developers. In addition, there is a
difference in output of software and desired output, is considered as an error.

74
Software Engineering (3161605)

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

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

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

o Integration Testing

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

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

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

75
Software Engineering (3161605)

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

Fig 9.1: Control Flow Graph for Employee Registration

• Tools / Material Needed:

o Hardware:
o Software:

76
 Software Engineering (3161605)

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

o Test case template

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

Variou Types of Testing :

o Unit Testing
o Integration Testing
o System Testing
o Acceptance Testing

In Unit Testing, we tested individual components like each controls for their validations to ensure that they operate
correctly.

The next level is called Integration Testing. In this many unit tested modules are combined into subsystems, which
are then tested. The goal here is to see if the modules can be integrated properly. This testing activity can be
considered testing the design.

77
 Software Engineering (3161605)

In System Testing, we tested whether system elements have been properly integrated and perform allocated
functions to detect the errors that may result from unanticipated interactions between sub-system and system
components.

Finally, in Acceptance Testing, we tested whether the system is accepted for operational use or not.

In this employee management system I have used unit testing & integration Testing

TEST CASE :

Following test cases were carried out :

78
Software Engineering (3161605)

79
Software Engineering (3161605)

Test Test Test Steps Expected Actual Pass/Fail

case Scenario Results Results
ID

1
2

Example

80
Software Engineering (3161605)

Test Test Test Steps Expected Actual Pass/Fail

Case Scenario Results Results
ID

TU01 Check 1. Go to User As Pass

Customer should Expected
site http://demo.guru99.c
Login with Login into
om
application

valid Data 2. Enter UserId

3. Enter Password
4. Click Submit

TU02 Check 1. Go to User As Pass

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

Quiz:

1. What elements of the WebApp can be “unit tested”? What types of tests must be conducted only after
the WebApp elements are integrated?
Unit-Testable Elements in the Mini Payroll System:
• Salary Calculation Logic:
o Example: A function that calculates net_salary = (salary_per_annum / 12) * present_days.
o Unit test: Verify correct output for valid/invalid inputs (e.g., negative days).

81
Software Engineering (3161605)

• User Authentication:
o Example: A method validating login credentials (Admin/Employee).
o Unit test: Test with valid/invalid username-password combinations.
• Input Validation:
o Example: Checking PAN number format or email syntax during employee registration.
o Unit test: Ensure invalid formats (e.g., ABCDE1234X) are rejected.
• Database CRUD Operations:
o Example: Testing if addEmployee() correctly inserts data into the database.
Tests Requiring Integration:
• Attendance-Salary Integration:
o Test if attendance data (present/absent days) is correctly used in salary calculation.
o Example: Ensure Attendance module feeds accurate data to Salary module.
• Report Generation:
o Verify that reports (e.g., payroll, attendance) pull data from integrated modules.
• User Role Access:
o Test if Admin can access all modules (e.g., delete employees), while Employees can only view
payslips.

2. What is white box testing? What are the different coverage-based testing strategies?
White Box Testing:
• Definition: Testing the internal code structure, logic, and workflows of the Mini Payroll System.
• Example: Checking the algorithm for calculating LOP (Loss of Pay) days in the salary module.
Coverage-Based Strategies:
1. Statement Coverage:
o Ensure every line of code is executed.
o Example: Test all code paths in the login() method (success, invalid password, empty fields).
2. Branch Coverage:
o Test all decision branches (e.g., if-else conditions).
o Example: Validate both conditions in if (role == "Admin") { ... } else { ... }.

3. Path Coverage:
o Test all possible paths through the code.
o Example: Cover all combinations in a multi-condition salary calculation (e.g., bonuses,
deductions).
4. Condition Coverage:
o Ensure all boolean expressions are tested for true/false.

82
 Software Engineering (3161605)

o Example: Test if (attendance > 0 && salary > 0) for both true and false cases.

3. What is black box testing?

Black Box Testing:
• Definition: Testing the system’s functionality without knowledge of internal code, focusing on inputs
and outputs.
• Examples in the Mini Payroll System:
o Functional Testing:
▪ Verify Admin can add/delete employees.
▪ Test if salary reports are generated in PDF format.
o Usability Testing:
▪ Check if the dashboard navigation is intuitive for users.
o Security Testing:
▪ Ensure sensitive data (e.g., passwords) is encrypted.
o Boundary Value Analysis:
▪ Test attendance input for valid ranges (e.g., 0 ≤ days ≤ 31).
Techniques:
• Equivalence Partitioning: Group inputs (e.g., valid/invalid PAN numbers).
• User Story Validation: Ensure the system meets requirements (e.g., "As an Admin, I want to generate
monthly payroll reports").

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:

83
Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementat implementat implementat implementat implementat
ion as asked ion as asked ion as asked ion as asked ion as asked
Problem Problem Problem Problem
analysis analysis analysis analysis
Development Development Development
of the of the of the
Solution Solution Solution
Concept Concept
Clarity & Clarity &
understandin understandin
g g
Correct
answer to all
questions

Signature of Faculty:

84
Software Engineering (3161605)

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

• Objectives: to learn how DevOps tools works.

• Theory:

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

How DevOps Works

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

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

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

85
Software Engineering (3161605)

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

Why DevOps Matters

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

DevOps Practices

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

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

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

86
Software Engineering (3161605)

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

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

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

Monitoring and Logging

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

Communication and Collaboration

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

87
Software Engineering (3161605)

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

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

Quiz:
1. What are the challenges with DevOps implementation?
Challenges in Implementing DevOps for the Mini Payroll System:
1. Cultural Resistance:
o Merging development and operations teams (e.g., developers and IT admins) can
lead to resistance due to differing priorities.
o Example: Developers might prioritize rapid feature releases, while operations
focus on system stability.
2. Tool Integration Complexity:
o Integrating tools like Jenkins (CI/CD), Ansible (Configuration
Management), and Prometheus (Monitoring) requires expertise.
o Example: Ensuring Jenkins pipelines automate payroll deployment without
disrupting existing workflows.
3. Security Compliance (DevSecOps):
o Embedding security into automated pipelines (e.g., encrypting payroll data, role-
based access control).
o Example: Automating vulnerability scans for the salary calculation module.
4. Infrastructure as Code (IaC) Management:
o Managing cloud resources (e.g., AWS/Azure) via code (Terraform) for
scalability.
o Example: Scaling server capacity during peak payroll processing times.
5. Monitoring Distributed Systems:
o Tracking performance of microservices (e.g., attendance, salary modules) in real-
time.

88
Software Engineering (3161605)

o Example: Using Grafana to visualize response times for report generation.

2. What is DevOps? How it works? What are the DevOps principles & best practices?
DevOps Definition:
A cultural and technical approach that combines software development (Dev) and IT operations
(Ops) to accelerate delivery through automation, collaboration, and continuous feedback.

How DevOps Works in the Mini Payroll System:

1. Collaboration: Developers and Ops teams jointly design CI/CD pipelines for deploying
payroll updates.
2. Automation:
o CI/CD: Jenkins automates code testing and deployment.
o IaC: Terraform provisions cloud servers for hosting the payroll app.
3. Monitoring: Prometheus alerts if the system fails during salary calculation.
DevOps Principles & Best Practices:
1. Continuous Integration (CI):
o Merge code changes daily; run automated tests (e.g., unit tests for salary logic).
2. Continuous Delivery (CD):
o Automatically deploy tested code to staging/production (e.g., payroll updates).
3. Infrastructure as Code (IaC):
o Define servers and databases using Terraform for reproducibility.
4. Microservices Architecture:
o Decouple modules (e.g., attendance, salary) for independent scaling.
5. Monitoring & Logging:
o Use ELK Stack (Elasticsearch, Logstash, Kibana) to track user login failures.

3. Explain 7Cs of DevOps lifecycle.

The 7Cs of DevOps for the Mini Payroll System:
1. Continuous Development:
o Plan and code payroll features (e.g., tax calculation) using Agile sprints.
2. Continuous Integration:
o Merge code into a shared repo; run automated tests (e.g., validate attendance
data).
3. Continuous Testing:
o Use Selenium for UI testing of the employee dashboard.

89
Software Engineering (3161605)

4. Continuous Deployment:
o Automatically deploy to AWS after successful tests.
5. Continuous Monitoring:
o Track system uptime and errors using Prometheus + Grafana.
6. Continuous Feedback:
o Gather user input (e.g., HR team) to refine payroll report formats.
7. Continuous Operations:
o Ensure 24/7 availability during payroll processing cycles.

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

implementa implementa implementa implementa implementa
tion as tion as tion as tion as tion as
asked asked asked asked asked
Problem Problem Problem Problem
analysis analysis analysis analysis
Development Development Development
of the of the of the
Solution Solution Solution
Concept Concept
Clarity & Clarity &
understandi understandi
ng ng
Correct
answer to all
questions

90
Software Engineering (3161605)

Signature of Faculty:

91