Software Engineering

 EXPERIMENT – 1

Analysis and Identification of Suitable Software Process Models

A Software Process Model defines the systematic approach used for software development. It specifies the order of activities such as requirement analysis, design, coding, testing, deployment, and maintenance.

Selecting an appropriate process model is crucial because it directly affects:

• Project cost
• Development time
• Software quality
• Customer satisfaction

The choice of a process model depends on requirement stability, project size, risk level, customer involvement, and time constraints.

Types of Software Process Models

1 Waterfall Model

A linear and sequential model where each phase must be completed before moving to the next phase.

Characteristics: It is a linear and sequential model where phases are completed one after another. Requirements must be well-understood, predictable, and fixed, making it difficult, costly, and time consuming to accommodate changes. Testing strictly occurs after the development phase is complete.

When to use: Best for small to medium-sized projects with clear, fixed requirements and a strict deadline.

Suitable projects: Embedded systems, safety-critical systems, and simple web applications.

Advantages

• Simple and easy to understand
• Well-defined documentation

Disadvantages

• No flexibility for requirement changes
• Testing occurs late

Suitable For

• Small projects with stable requirements

2 V-Model

An extension of the Waterfall model where testing is planned parallel to development.

Characteristics: Similar to the Waterfall model, it is linear, sequential, and relies on predictable, well defined requirements. However, verification and validation occur alongside each corresponding phase, even though actual testing still happens after development.

When to use: Best for small to medium-sized projects with fixed deadlines and clear requirements.

Suitable projects: Embedded systems, safety-critical systems, and simple web applications.

Advantages

• Early defect detection
• Structured testing

Disadvantages

• Rigid and inflexible
• Changes are costly

3 Incremental Model

The system is developed in multiple increments, each delivering a functional module.

Characteristics: Software is developed in increments using an iterative approach. Requirements are prioritized, and developing in increments reduces the risk of project failure while making maintenance easier.

When to use: Best for large, complex projects that require incremental delivery and have evolving requirements.

Suitable projects: Enterprise software systems, complex web applications, and systems involving multiple stakeholders.

Advantages

• Early delivery of working software
• Easier debugging

Disadvantages

• Integration complexity
• Requires careful planning

4 Spiral Model

A risk-driven model combining iterative development with systematic risk analysis.

Characteristics: An iterative and incremental model that is heavily risk-driven. Risk analysis is performed during each iteration, and continuous user involvement helps reduce the risk of failure.

When to use: Ideal for high-risk projects, complex requirements, and situations where rigorous risk analysis is mandatory.

Suitable projects: Safety-critical systems, highly secure systems, complex systems, and R&D projects.

Advantages

• Effective risk management
• Flexible

Disadvantages

• High cost
• Complex management

5 Agile Model

An iterative and incremental model focusing on customer collaboration and adaptability.

Characteristics: An iterative and incremental methodology where software is developed in iterations heavily reliant on constant user feedback and involvement. Requirements are prioritized per iteration, greatly reducing project risk.

When to use: Ideal for projects with high uncertainty, changing requirements, and a strong need for user feedback.

Suitable projects: Complex systems, systems with high user interaction, and R&D projects

Advantages

• Handles changing requirements effectively
• Faster delivery
• Continuous feedback

Disadvantages

• Less documentation
• Requires experienced team

Case Study: Online Student Attendance Management System

Problem Description:

An educational institute requires an online system to manage student attendance digitally. The system should support:

• Student and faculty login
• Subject-wise attendance
• Attendance reports
• Location-based attendance
• Future integration of face recognition

Requirement Analysis

Parameter	Observation
Requirement Stability	Not stable
Project Size	Medium
Risk Level	Medium
Customer Involvement	High
Future Enhancements	Required

Analysis of Suitable Process Model

Waterfall Model:                Not suitable due to changing requirements

V-Model:                            Too rigid for dynamic requirements

Incremental Model:           Partially suitable

Spiral Model:                    Costly for medium-scale project

Agile Model:                     Best suited due to flexibility and continuous feedback

Identified Software Process Model

Agile Software Process Model is identified as the most suitable model for the given system.

Justification

The Agile model is selected because:

• Requirements are expected to change
• Continuous interaction with faculty and admin is required
• Features can be delivered incrementally
• Future enhancements can be easily integrated

Result

Thus, after analyzing various software process models and project requirements, the Agile Software Process Model was successfully identified as the most suitable model for the given real-world case study.

EXPERIMENT – 2

Work Breakdown Structure (Process-Based, Product-Based, Geographic-Based and Role-Based) and Software Estimation

Theory

A Work Breakdown Structure is a project management tool utilized to break down complex projects into smaller, more manageable tasks. It is considered a productivity technique that makes work more approachable and integrates scope, cost, and schedule baselines to align project plans. By definition, it is a "deliverable-oriented hierarchical decomposition of the work to be executed by the project team".

Characteristics of WBS:

Deliverable-oriented: Focuses primarily on project outcomes or deliverables.

Hierarchical: Tasks are organized in a tree-like structure, breaking down higher-level tasks into smaller, detailed sub-tasks.

Decomposition: The act of breaking down complex tasks into more manageable pieces.

Benefits of WBS:

• Improved project planning: Helps identify every task necessary to successfully complete the project.
• Enhanced team communication: Establishes a common understanding of the scope and tasks involved.
• Better risk management: Aids in identifying potential risks and developing strategies to mitigate them.
• Increased productivity: Allows team members to concentrate on specific deliverables and tasks.

• Project planning

• Scheduling

• Cost estimation

• Resource allocation

Software Estimation is the process of predicting the effort, cost, and duration required to develop a software system.

Types of Work Breakdown Structure

1 Process-Based WBS

A Process-Based WBS organizes tasks around the necessary business processes, activities, or functions needed to achieve project objectives. Work is divided according to software development phases.

Example Phases:

• Requirement Analysis
• System Design
• Coding
• Testing
• Deployment
• Maintenance

• Level 1: Project Management
  • 1.1 Project Initiation, 1.2 Project Planning, 1.3 Project Monitoring and Control, 1.4 Project Closure
• Level 2: Requirements Gathering
  • 2.1 Elicitation (Identify stakeholders, conduct interviews, document requirements)
  • 2.2 Requirements Analysis (Define functional/non-functional requirements, prioritize)
• Level 3: Design
  • 3.1 User Interface (UI) Design (Create wireframes, prototypes, conduct usability testing)
  • 3.2 Technical Design (Define system architecture, data models, technical specs)
• Level 4: Implementation
  • 4.1 Front-end Development (Implement UI components, event handling, client-side validation)
  • 4.2 Back-end Development (Implement server-side logic, data storage/retrieval, authentication/authorization)
  • 4.3 Text Editor Features (Implement font styling, copy/cut/paste, paragraph alignment)
• Level 5: Testing and Deployment
  • 5.1 Unit Testing (Write and execute unit tests)
  • 5.2 Integration Testing (Write and execute integration tests)
  • 5.3 Deployment (Plan and execute deployment)
• Level 6: Maintenance and Support
  • 6.1 Bug Fixing (Identify, prioritize, and fix bugs)
  • 6.2 Feature Updates (Gather requirements and implement new features)

2 Product-Based WBS

Work is divided based on system deliverables or modules.

Example Modules:

1. Login Module
2. Attendance Module
3. Report Module
4. Admin Module

Example Breakdown:

• Level 1: Text Editor Software
  • 1.1 User Interface (UI),
  • 1.2 Text Editing Features,
  • 1.3 Text Formatting Features,
  • 1.4 Copy/Cut/Paste Features,
  • 1.5 Paragraph Alignment Features,
  • 1.6 Data Storage and Retrieval,
  • 1.7 Authentication and Authorization
• Level 2: User Interface (UI)
  • 2.1 Login/Registration Page,
  • 2.2 Text Editor Page
• Level 3: Text Editing Features
  • 3.1 Text Input and Editing,
  • 3.2 Text Selection and Navigation
• Level 4: Text Formatting Features
  • 4.1 Font Formatting (Color, size, style),
  • 4.2 Paragraph Formatting (Alignment, indentation)
• Level 5: Copy/Cut/Paste Features
  • 5.1 Copy Feature,
  • 5.2 Cut Feature,
  • 5.3 Paste Feature
• Level 6: Data Storage and Retrieval
  • 6.1 Data Storage (Store text in database),
  • 6.2 Data Retrieval
• Level 7: Authentication and Authorization
  • 7.1 User Authentication,
  • 7.2 User Authorization

3 Geographic-Based WBS

Tasks are organized around the physical locations or regions where project work occurs, which is highly useful for multi-site projects. The example focuses on deploying the software to different regions with localized data centers

Example:

• UI development – Bangalore
• Backend development – Bhubaneswar
• Testing – Hyderabad

4 Role-Based WBS

Work is divided based on team roles.

Example Roles:

• Project Manager
• System Analyst
• Developer
• Tester
• Database Administrator

Example Breakdown:

• Level 1: Project Team (Project Manager, Software Developers, QA Testers, Technical Writers, Designers, DevOps Engineers)
• Level 2: Project Manager
  • 2.1 Project Planning,
  • 2.2 Project Monitoring and Control
• Level 3: Software Developers
  • 3.1 Front-end Development,
  • 3.2 Back-end Development
• Level 4: Quality Assurance (QA) Testers
  • 4.1 Test Planning,
  • 4.2 Test Execution
• Level 5: Technical Writers
  • 5.1 User Documentation,
  • 5.2 Technical Documentation
• Level 6: Designers
  • 6.1 User Interface (UI) Design,
  • 6.2 Visual Design
• Level 7: DevOps Engineers
  • 7.1 Infrastructure Setup,
  • 7.2 Deployment

Estimation Techniques

1 LOC (Lines of Code) Based Estimation

Effort is estimated based on the total number of source code lines.

Formula:

Effort = LOC / Productivity

2 Function Point (FP) Estimation

Estimation based on system functionality instead of code size.

Components:

• External Inputs
• External Outputs
• External Inquiries
• Internal Logical Files
• External Interface Files

3 COCOMO Model

An algorithmic model used to estimate effort and cost.

Basic COCOMO Formula:

Effort (Person-Months) = a × (KLOC)^b

Where:

a, b are constants

KLOC = Thousand Lines of Code

Case Study

Project: Online Student Attendance Management System

WBS Preparation

1 Process-Based WBS

Requirement Analysis

• System Design
• Module Development
• Testing
• Deployment
• Maintenance

2 Product-Based WBS

• User Authentication Module
• Attendance Management Module
• Report Generation Module
• Admin Management Module

3 Geographic-Based WBS

• Frontend Development – Location A
• Backend Development – Location B
• Testing & QA – Location C

4 Role-Based WBS

• Project Planning – Project Manager
• Requirement Analysis – System Analyst
• Coding – Developers
• Testing – Test Engineers

Software Estimation

Assumptions:

Estimated LOC = 25,000

Productivity = 500 LOC/month

Effort Calculation:

Effort = 25,000 / 500 = 50 Person-Months

Cost Estimation:

Assuming cost per person-month = ₹40,000

Total Cost = 50 × 40,000 = ₹20,00,000

Result

Thus, different types of Work Breakdown Structures were successfully prepared and software effort and cost estimation was calculated for the given project.

EXPERIMENT – 3

Requirement Modeling using Entity Relationship Diagram (ERD) (Structural Modeling)

Theory

Requirement Modeling is the process of representing user requirements in a structured and visual form.

Entity Relationship Diagram (ERD) is a structural modeling technique used to represent:

Data requirements

Relationships among data objects

ERD is widely used during database design and helps developers understand how data is stored and related within the system.

Components of ER Diagram

1 Entity

An entity represents a real-world object or concept.

Examples: Student, Faculty, Subject

2 Attributes

Attributes describe the properties of an entity.

Examples:

Student ID

Name

Email

3 Relationships

Relationships show how entities are connected.

Examples:

Student enrolls in Subject

Faculty teaches Subject

4 Cardinality

Cardinality defines the number of instances involved in a relationship.

Types:

One-to-One (1:1)

One-to-Many (1:M)

Many-to-Many (M:N)

Case Study

System Name: Online Student Attendance Management System

Identification of Entities and Attributes

1 Student Entity

1. Student_ID (Primary Key)
2. Name
3. Roll_Number
4. Email
5. Department

2 Faculty Entity

1. Faculty_ID (Primary Key)
2. Name
3. Email
4. Department

3 Subject Entity

1. Subject_ID (Primary Key)
2. Subject_Name
3. Semester
4. Credits

4 Attendance Entity

1. Attendance_ID (Primary Key)
2. Date
3. Status
4. Student_ID (Foreign Key)
5. Subject_ID (Foreign Key)

Identification of Relationships

Entity 1	Relationship	Entity 2	Cardinality
Student	Enrolls	Subject	M:N
Faculty	Teaches	Subject	1:M
Student	Has	Attendance	1:M
Subject	Has	Attendance	1:M

ER Diagram Description

• Student entity is connected to Subject through an Enrolls relationship
• Faculty teaches one or more subjects
• Attendance entity maintains daily attendance records
• Primary and foreign keys ensure data integrity

(Neat ER diagram should be drawn in the lab record as per this description)

Procedure

• Study the system requirements
• Identify all entities
• Assign attributes to each entity
• Identify relationships and cardinality
• Draw the ER Diagram

Input

System requirement specification for Online Attendance Management System.

Output

Entity Relationship Diagram representing the structural requirements of the system.

Result

Thus, the Entity Relationship Diagram was successfully designed to model the structural requirements of the given system. ER diagrams provide a clear and structured representation of system data, helping in effective database design and requirement understanding.

EXPERIMENT – 4

Requirement Modeling using Context Diagram and Data Flow Diagram (DFD)

1. Aim

To analyze the functional requirements of a system and represent them using a Context Diagram and Data Flow Diagrams (DFD).

Functional Requirement Modeling represents what the system should do.

Data Flow Diagram (DFD) is a graphical representation of the flow of data through a system.

A Context Diagram is the highest-level DFD that shows:

The system as a single process

Interaction with external entities

Components of DFD

• Process – Transformation of data
• Data Flow – Movement of data
• Data Store – Storage of data
• External Entity – Source or destination of data

Case Study

System Name: Online Student Attendance Management System

Context Diagram Description

External Entities:

• Student
• Faculty
• Admin

Process:

• Online Attendance Management System

Data Flows:

• Login details
• Attendance data
• Reports

(System is represented as a single process interacting with all external entities)

Level-0 DFD Description

Major Processes:

• User Authentication
• Attendance Management
• Report Generation

Data Stores:

• Student Database
• Attendance Database

External Entities:

• Student
• Faculty
• Admin

Level-1 DFD Description

Process 1: User Authentication

• Validates login credentials
• Stores user details

Process 2: Attendance Management

• Records daily attendance
• Updates attendance database

Process 3: Report Generation

• Generates subject-wise and student-wise reports

Procedure

• Identify system boundaries
• Identify external entities
• Draw Context Diagram
• Decompose system into Level-0 DFD
• Further decompose processes into Level-1 DFD

Input

System requirements of Online Attendance Management System.

Output

Context Diagram, Level-0 DFD, and Level-1 DFD representing functional requirements.

Result

Thus, Context Diagram and Data Flow Diagrams were successfully designed to represent the functional requirements of the system.

EXPERIMENT – 5

Requirement Modeling using State Transition Diagram (Behavioral Modeling)

A State Transition Diagram (STD) is a behavioral modeling tool used to represent:

• Different states of a system
• Events that trigger transitions
• Actions performed during transitions

A system changes its state when an event occurs. The diagram helps in understanding how the system behaves over time.

Components of State Transition Diagram

• State – A condition in which the system exists at a particular time
• Event – An occurrence that causes state change
• Transition – Movement from one state to another
• Initial State – Starting state
• Final State – Ending state

Case Study

System Name: Online Student Attendance Management System

Identification of States

For the Attendance System, the following states are identified:

• Initial State
• Login State
• Authenticated State
• Attendance Marking State
• Report Viewing State
• Logout State

Current State	Event	Next State
Initial	Enter Credentials	Login State
Login State	Valid Credentials	Authenticated State
Login State	Invalid Credentials	Login State
Authenticated State	Select Attendance	Attendance Marking State
Authenticated State	View Report	Report Viewing State
Attendance Marking State	Submit	Authenticated State
Report Viewing State	Back	Authenticated State
Authenticated State	Logout	Logout State

State Transition Diagram helps in modeling system behavior clearly and ensures proper handling of events and state changes in software systems.

EXPERIMENT – 6

Object-Oriented Design – Use Case Diagram and Class Diagram

Theory

Object-Oriented Design (OOD) is a methodology that organizes software design around objects and classes rather than functions.

Unified Modeling Language (UML) is used to represent object-oriented systems.

Two important UML diagrams used in requirement modeling are:

• Use Case Diagram – Represents system functionality from user’s perspective
• Class Diagram – Represents static structure of the system

Part A: Use Case Diagram

Use Case Diagram

A Use Case Diagram represents:

1. Actors (users interacting with system)
2. Use cases (functionalities provided by system)
3. Relationships between actors and use cases

Case Study

System Name: Online Student Attendance Management System

Identification of Actors

• Student
• Faculty
• Admin

Identification of Use Cases

• Login
• Mark Attendance
• View Attendance
• Generate Report
• Manage Users
• Logout

Actor	Use Cases
Student	Login, View Attendance, Logout
Faculty	Login, Mark Attendance, Generate Report, Logout
Admin	Login, Manage Users, Generate Report, Logout

Part B: Class Diagram

Class Diagram

A Class Diagram represents:

• Classes
• Attributes
• Methods
• Relationships between classes

It describes the static structure of the system.

Identification of Classes

1. Student

Attributes:

• studentID
• name
• email
• department

Methods:

• login()
• viewAttendance()

2. Faculty

Attributes:

• facultyID
• name
• email

Methods:

• login()
• markAttendance()
• generateReport()

3. Subject

Attributes:

• subjectID
• subjectName
• semester

Methods:

• assignFaculty()

4. Attendance

Attributes:

• attendanceID
• date
• status

Methods:

• updateAttendance()

Relationships Between Classes

• Student → Attendance (One-to-Many)
• Faculty → Subject (One-to-Many)
• Subject → Attendance (One-to-Many)