SOFTWARE ENGIEERING

(BBCAMAJ10C)
LAB ASSIGNMENT
SUBMITTED TO
BENGAL INSTITUTE OF SCIENCE & TECHNOLOGY

DEPARTMENT OF BCA
By
<NAME>
REGISTRATION No.: <your university regn. number>
ROLL No.: <your university roll number>
Under the guidance of
KAUSTAV SANYAL
(Asst. Professor, BCA)

June, 2026
Exp.
Title Date Remarks
No.

1 Problem Statement Development

2 Software Requirement Specification (SRS) – IEEE Standard

3A UML – Use Case Diagram

3B UML – Class Diagram

3C UML – Sequence Diagram

3D UML – Collaboration / Communication Diagram

3E UML – State Chart Diagram

3F ERD, EERD and DFD

4 Project Scheduling – Gantt Chart & PERT Chart

5 Software Configuration & Risk Management Documents

6 Design Phase CASE Tool – Study & Usage

7 Test Cases – Unit Testing & Integration Testing

8 Test Cases – White Box & Black Box Techniques

 Software Engineering Lab
Experiment No. 1
Development of Problem Statement

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim / Objective

To understand the concept of a problem statement in software engineering and to develop a well-
defined, unambiguous problem statement for a given software project.

2. Theory

2.1 What is a Problem Statement?

A problem statement is a concise description of the issue that needs to be addressed by a software
system. It sets the context for the entire project and answers the questions: What is the problem?
Who is affected? What are the expected outcomes?

2.2 Characteristics of a Good Problem Statement

• Clear and Concise: Avoids ambiguity; states the problem in simple language.
• Specific: Defines scope; does not over-generalise.
• Measurable: Provides a basis for verifying that the problem has been solved.
• Relevant: Directly linked to the project objectives.
• Time-bound: States any deadline or urgency if applicable.

2.3 Components
Context / Background The environment or situation in which the problem exists.

Problem Description A clear articulation of the gap between the current state and the desired state.
 Impact Who is affected and how?

A high-level indication of what the solution might look like (optional at this
Proposed Solution Hint
stage).

Constraints Budget, time, technology, regulatory limitations.

2.4 Sample Project Context

Throughout this manual the following sample project will be used as a running example:

Sample Project: Online Library Management System (OLMS)

The college library currently manages all book-issue and return transactions manually using paper
registers. This leads to frequent errors, loss of records, and inability to search for book availability in real
time. An online system is required to automate cataloguing, issue/return, fine calculation, member
registration, and report generation.

3. Procedure

1. Identify the stakeholders (students, library staff, admin).

2. Understand the current (AS-IS) process through observation or interviews.
3. Identify pain points and inefficiencies in the current process.
4. Define the desired (TO-BE) state.
5. Draft the problem statement using the template below.
6. Review and refine with peers and instructor.

4. Problem Statement Template

The problem of [describe the problem]

affects [the stakeholders affected by the problem],
the impact of which is [what is the impact of the problem].
A successful solution would [describe some key benefits of a successful solution].
 5. Observation / Result

Write your problem statement for the given project below:

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

6. Conclusion

(Write your conclusion here after completing the experiment.)

7. Questions for Viva Voce

7. What is a problem statement and why is it important?

8. Differentiate between problem statement and project scope.
9. What are the consequences of a poorly defined problem statement?
10. How does a problem statement relate to the SRS document?
11. Give an example of a bad problem statement and improve it.
 Software Engineering Lab
Experiment No. 2
Preparation of SRS Document (IEEE Std 830)

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To prepare a Software Requirement Specification (SRS) document for the sample project following
IEEE Std 830-1998 guidelines.

2. Theory

2.1 What is SRS?

An SRS is a formal description of the behaviour expected of a software system. It acts as a contract
between the customer and the developer, defining WHAT the system must do, not HOW it will do it.

2.2 IEEE Std 830 Structure

Sec. Title Contents

1 Introduction Purpose, Scope, Definitions, Acronyms, References, Overview

Product Perspective, Product Functions, User Characteristics, Constraints,

2 Overall Description
Assumptions

3 Specific Requirements Functional, Non-Functional, External Interface Requirements

4 Appendices Supporting information

5 Index Optional
2.3 Functional vs Non-Functional Requirements
Functional Describe what the system must do (login, add book, generate report).

Non-Functional Quality attributes – performance, security, usability, reliability, scalability.

Interface Hardware, software, communication and user interfaces.

2.4 Characteristics of Good Requirements

• Correct
• Unambiguous
• Complete
• Consistent
• Ranked (priority)
• Verifiable
• Modifiable
• Traceable

3. Procedure

12. Refer to the problem statement from Experiment 1.

13. Identify all stakeholders and elicit requirements through interviews/questionnaires.
14. Categorise requirements as functional, non-functional, and interface.
15. Assign unique IDs to each requirement (e.g., FR-01, NFR-01).
16. Prepare the SRS document following IEEE Std 830 template.
17. Review for completeness and consistency.

4. Sample SRS Outline (OLMS)

4.1 Functional Requirements (Partial)

Req. ID Description Priority Source

The system shall allow a librarian to add, edit and delete book
FR-01 High Librarian
records.

The system shall allow students to search for books by title, author
FR-02 High Student
or ISBN.
 The system shall issue books to registered members and record
FR-03 High Librarian
the due date.

The system shall calculate and display overdue fines

FR-04 Medium Admin
automatically.

The system shall generate monthly issue/return reports in PDF

FR-05 Low Admin
format.

4.2 Non-Functional Requirements (Partial)

Req. ID Category Description

The system shall respond to any search query within 2 seconds

NFR-01 Performance
for up to 500 concurrent users.

All passwords shall be stored using bcrypt hashing with a

NFR-02 Security
minimum cost factor of 10.

New users shall be able to perform a book search without

NFR-03 Usability
training.

The system shall achieve 99.5% uptime during working hours

NFR-04 Availability
(8 AM – 8 PM).

5. Observations / Deliverable

Prepare and attach the complete SRS document for your project. Ensure all sections of IEEE Std 830
are covered.

6. Questions for Viva Voce

18. What is the difference between SRS and design document?

19. What makes a requirement 'verifiable'?
20. Why should requirements be assigned unique IDs?
21. What is the difference between 'shall', 'should' and 'may' in IEEE SRS?
22. How are non-functional requirements tested?
 Software Engineering Lab
Experiment No. 3A
UML – Use Case Diagram

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To create a Use Case Diagram for the sample project using an open-source UML tool.

2. Theory

2.1 Use Case Diagram

A Use Case Diagram is a behavioural UML diagram that captures the functional requirements of a
system. It shows interactions between actors (users or external systems) and use cases (system
functions).

2.2 Notations
Element Notation Description

External entity that interacts with the

Actor Stick figure
system

Use Case Oval / Ellipse A function or feature of the system

Association Solid line Relationship between actor and use case

Include Dashed arrow <<include>> A use case always includes another

Extend Dashed arrow <<extend>> A use case optionally extends another

Generalisation Solid arrow with hollow head Inheritance between actors or use cases

System Boundary Rectangle Encloses all use cases of the system

2.3 Open-Source Tools
• [Link] / [Link] ([Link] – Free, browser-based
• StarUML – Free community edition
• PlantUML – Text-based UML, integrates with VS Code
• Umbrello (Linux) – Free KDE UML modeller

3. Procedure

23. Open [Link] or any UML tool.

24. Identify actors for the OLMS (Student, Librarian, Admin, Email Server).
25. List all use cases (Search Book, Issue Book, Return Book, Pay Fine, Generate Report, Manage
Members, etc.).
26. Draw the system boundary rectangle and label it.
27. Place actors outside the boundary; use cases inside.
28. Draw associations between actors and use cases.
29. Add <<include>> and <<extend>> relationships where applicable.
30. Save the diagram as .xml ([Link]) and export as PNG/PDF.

4. Sample PlantUML Code (OLMS)

@startuml
left to right direction
actor Student
actor Librarian
actor Admin

rectangle "Online Library Management System" {

usecase "Search Book" as UC1
usecase "Issue Book" as UC2
usecase "Return Book" as UC3
usecase "Pay Fine" as UC4
usecase "Calculate Fine" as UC5
usecase "Generate Report" as UC6
usecase "Manage Members" as UC7
}

Student --> UC1

Student --> UC2
Student --> UC3
Student --> UC4
Librarian --> UC2
Librarian --> UC3
Admin --> UC6
Admin --> UC7
UC3 .> UC5 : <<include>>
UC4 .> UC5 : <<extend>>
@enduml

5. Diagram (Attach here)

[Paste / Draw your Use Case Diagram here]

6. Questions for Viva Voce

31. What is the purpose of a Use Case Diagram?

32. Differentiate between <<include>> and <<extend>>.
33. Can an actor be a system? Give an example.
34. What is generalisation in the context of use cases?
35. How is a Use Case Diagram related to requirements?
 Software Engineering Lab
Experiment No. 3B
UML – Class Diagram

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To create a Class Diagram representing the static structure of the sample project.

2. Theory

2.1 Class Diagram

A Class Diagram is a structural UML diagram that describes the classes in a system, their attributes,
methods, and the relationships between them.

2.2 Key Elements

Class Rectangle divided into 3 compartments: name, attributes, methods.

Association A plain line; represents a uses/knows relationship.

Aggregation Hollow diamond; 'has-a' weak ownership.

Composition Filled diamond; 'contains-a' strong ownership (part destroyed with whole).

Inheritance Solid line with hollow arrowhead; 'is-a' relationship.

Dependency Dashed arrow; one class uses another transiently.

Multiplicity e.g. 1, 0..*, 1..* placed at association ends.

2.3 Visibility Symbols
• + Public - Private # Protected ~ Package

3. Procedure

36. Identify all entities from the OLMS requirements (Book, Member, Librarian, Loan, Fine,
Catalogue, Report).
37. Define attributes (name, type) and methods (name, parameters, return type) for each class.
38. Identify relationships: which classes associate, which are composed, which inherit.
39. Specify multiplicities at both ends of each association.
40. Draw the diagram using [Link] or StarUML.

4. Sample Classes (OLMS)

@startuml
class Book {
-isbn : String
-title : String
-author : String
-copiesAvailable : int
+search(query: String) : List<Book>
+updateAvailability() : void
}

class Member {
-memberId : String
-name : String
-email : String
+register() : void
+getActiveLoans() : List<Loan>
}

class Loan {
-loanId : String
-issueDate : Date
-dueDate : Date
+calculateFine() : double
}

class Fine {
-amount : double
-paid : boolean
+pay() : void
}
Member "1" -- "0..*" Loan : takes
Book "1" -- "0..*" Loan : covered by
Loan "1" *-- "0..1" Fine : generates
@enduml

5. Diagram (Attach here)

[Paste / Draw your Class Diagram here]

6. Questions for Viva Voce

41. What is the difference between aggregation and composition?

42. How do you decide multiplicity for an association?
43. What is an abstract class? How is it shown in UML?
44. Differentiate Class Diagram from Object Diagram.
45. Can a class have multiple inheritances in UML?
 Software Engineering Lab
Experiment No. 3C
UML – Sequence Diagram

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To create a Sequence Diagram showing the order of messages exchanged between objects for a
specific scenario.

2. Theory

2.1 Sequence Diagram

A Sequence Diagram is a behavioural (interaction) UML diagram that shows the time-ordered
sequence of messages between objects or components for a particular use case scenario.

2.2 Notations
Lifeline Vertical dashed line below an object/actor box.

Activation Bar Narrow rectangle on a lifeline; shows when an object is active.

Synchronous Message Solid arrow with filled head; caller waits for response.

Asynchronous Message Solid arrow with open head; caller does not wait.

Return Message Dashed arrow; shows return value.

Self-call Arrow looping back to the same lifeline.

Alt / Opt / Loop Combined fragment boxes for conditional / optional / loop logic.

Create / Destroy <<create>> / X mark on lifeline.

3. Procedure

46. Choose a specific scenario (e.g., 'Issue Book' use case).

47. List all participating
objects: :Student, :IssueController, :BookRepository, :LoanRepository, :Book, :Loan.
48. Determine the order of method calls step by step.
49. Draw lifelines horizontally across the page.
50. Draw messages as arrows between lifelines in top-to-bottom order.
51. Add activation bars for the duration of each method execution.
52. Add any alt/loop fragments for conditional flows.

4. Sample Scenario – Issue Book

@startuml
actor Student
participant IssueController
participant BookRepository
participant LoanRepository

Student -> IssueController : requestIssue(isbn, memberId)

IssueController -> BookRepository : findBook(isbn)
BookRepository --> IssueController : book
IssueController -> BookRepository : checkAvailability(book)
BookRepository --> IssueController : available=true
IssueController -> LoanRepository : createLoan(book, memberId)
LoanRepository --> IssueController : loan
IssueController -> BookRepository : decrementCopies(book)
IssueController --> Student : issueConfirmation(loan)
@enduml

5. Diagram (Attach here)

[Paste / Draw your Sequence Diagram here]

6. Questions for Viva Voce

53. What is the difference between synchronous and asynchronous messages?

54. How does a Sequence Diagram differ from a Collaboration Diagram?
55. What are combined fragments? Name three.
56. When is a return message shown on a Sequence Diagram?
57. How do you represent a loop in a Sequence Diagram?
 Software Engineering Lab
Experiment No. 3D
UML – Collaboration (Communication) Diagram

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To create a Collaboration/Communication Diagram for the same scenario used in Experiment 3C and
compare it with the Sequence Diagram.

2. Theory

2.1 Collaboration Diagram

A Collaboration Diagram (called Communication Diagram in UML 2.x) emphasises the structural
organisation of objects and the messages sent between them. Unlike the Sequence Diagram, time is
not shown on an axis; instead, message sequence numbers convey ordering.

2.2 Key Differences from Sequence Diagram

Aspect Sequence Diagram Collaboration Diagram

Structural relationships between

Focus Time ordering of messages
objects

Axis Time flows top-to-bottom No time axis; uses sequence numbers

Better for showing object

Complexity Easy to read for scenarios
relationships

Collaboration (1.x) / Communication

UML version UML 1.x & 2.x
(2.x)
2.3 Sequence Numbering
Messages are numbered hierarchically: 1, 2, 3 for top-level; 1.1, 1.2 for messages triggered by
message 1, and so on.

3. Procedure

58. Take the same 'Issue Book' scenario from Experiment 3C.
59. Place object boxes (rectangles) on the diagram.
60. Draw links (lines) between objects that communicate.
61. Label each link with the message name and a sequence number.
62. Show return values using the direction of arrows.

4. Diagram (Attach here)

[Paste / Draw your Collaboration Diagram here]

5. Questions for Viva Voce

63. What is the primary advantage of a Collaboration Diagram over a Sequence Diagram?
64. What do sequence numbers like 1.1, 1.2 indicate?
65. Can both diagrams represent the same information? Explain.
66. In UML 2.x, what is the Collaboration Diagram renamed to?
 Software Engineering Lab
Experiment No. 3E
UML – State Chart Diagram

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To create a State Chart (State Machine) Diagram showing the life cycle of a key object in the sample
project.

2. Theory

2.1 State Chart Diagram

A State Chart Diagram (Statechart or State Machine Diagram) models the dynamic behaviour of a
single object by showing the states it can be in and the transitions between those states in response
to events.

2.2 Notations
Initial State Filled black circle (pseudo-state).

Final State Filled black circle inside a larger circle.

State Rounded rectangle; may contain entry/exit/do actions.

Transition Arrow labelled event [guard] / action.

Guard Condition Boolean expression in square brackets on a transition.

Composite State A state that contains nested (sub)states.

3. Procedure
 67. Select an entity whose lifecycle is interesting (e.g., Book, Loan).
68. List all states the object can be in.
69. Identify events that trigger transitions between states.
70. Identify any guard conditions.
71. Identify entry/exit/do actions for states.
72. Draw the diagram in your UML tool.

4. Sample – States of a Loan

@startuml
[*] --> Active : issue(book, member)
Active --> Overdue : dueDate < today
Active --> Returned : return(book)
Overdue --> Returned : return(book) / calculateFine()
Returned --> FinePending : [fine > 0]
FinePending --> Closed : payFine()
Returned --> Closed : [fine == 0]
Closed --> [*]
@enduml

5. Diagram (Attach here)

[Paste / Draw your State Chart Diagram here]

6. Questions for Viva Voce

73. What is the difference between a State Chart Diagram and an Activity Diagram?
74. What are entry and exit actions in a state?
75. What is a composite state?
76. Give a real-world example of an object with at least 4 distinct states.
77. How are guard conditions different from events?
 Software Engineering Lab
Experiment No. 3F
ERD, EERD and DFD

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To create an Entity-Relationship Diagram (ERD), an Enhanced ERD (EERD), and a Data Flow Diagram
(DFD) for the sample project.

2. Theory

2.1 Entity-Relationship Diagram (ERD)

An ERD models the data requirements of a system. It shows entities, their attributes, and the
relationships between entities.

Entity Rectangle – a real-world object with data stored about it.

Attribute Ellipse – a property of an entity (underlined = primary key).

Relationship Diamond – association between two or more entities.

Cardinality 1:1, 1:N, M:N placed on relationship lines.

2.2 Enhanced ERD (EERD)

EERD extends ERD to include:
• Specialisation / Generalisation (super/sub-type entities).
• Aggregation (treating a relationship as an entity).
• Participation constraints (total vs. partial participation).

2.3 Data Flow Diagram (DFD)

A DFD shows how data flows through a system. It does not show control logic, only data movement.
 External Entity Rectangle (Yourdon) – data source or sink outside the system.

Process Circle / Rounded rectangle – transforms data.

Data Store Open-ended rectangle – stores data (e.g., database table).

Data Flow Arrow labelled with data name.

DFDs are levelled: Level 0 (Context Diagram) → Level 1 → Level 2 … decomposing each process.

3. Procedure

ERD / EERD
78. Identify all entities from the OLMS requirements.
79. Identify attributes for each entity and mark primary keys.
80. Identify relationships and determine cardinality.
81. Extend to EERD: identify any super/sub-types (e.g., Member → Student, Faculty).

DFD
82. Draw Context Diagram (Level 0): one central process, all external entities.
83. Explode the central process into sub-processes for Level 1.
84. Continue decomposing until each process is simple enough.

4. Diagrams (Attach here)

ERD:

[Paste ERD here]

DFD Level 0 (Context Diagram):

 [Paste DFD Level 0 here]

5. Questions for Viva Voce

85. What is the difference between ERD and EERD?

86. What is total participation vs. partial participation?
87. How does a DFD differ from a flowchart?
88. What is a Context Diagram?
89. Can a data store appear in a Context Diagram? Why / why not?
 Software Engineering Lab
Experiment No. 4
Project Scheduling – Gantt Chart & PERT Chart

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To prepare project scheduling documents, including a Gantt Chart and a PERT chart, for the sample
project using open-source tools.

2. Theory

2.1 Gantt Chart

A Gantt Chart is a horizontal bar chart that represents a project schedule over time. Each bar
represents a task; its left end marks the start date and its right end marks the end date.
• Developed by Henry L. Gantt in the 1910s.
• Shows task durations, sequence, and parallelism.
• Easily identifies critical tasks and overall project timeline.
• Open-source tools: GanttProject, ProjectLibre, LibreOffice Calc with conditional formatting.

2.2 PERT Chart

Program Evaluation and Review Technique (PERT) is a network-based scheduling method. It
represents tasks as nodes (or arcs) connected by arrows showing dependencies.

Optimistic Time (O) Shortest possible time to complete the task.

Most Likely Time (M) Most realistic time under normal conditions.

Pessimistic Time (P) Longest time if everything goes wrong.

Expected Time (TE) TE = (O + 4M + P) / 6

Critical Path The longest path through the network; determines project duration.
 Float / Slack Amount of time a task can be delayed without affecting project end.

3. Procedure

Gantt Chart
90. List all project phases and tasks (Requirement Analysis, Design, Coding, Testing,
Deployment).
91. Estimate duration for each task.
92. Identify dependencies between tasks.
93. Plot tasks on a time-axis using GanttProject or ProjectLibre.
94. Add milestones for key deliverables.

PERT Chart
95. List all activities with their predecessors.
96. Estimate O, M, P for each activity.
97. Calculate Expected Time TE = (O + 4M + P) / 6.
98. Draw the network diagram.
99. Identify the Critical Path.

4. Sample Activity Table (OLMS)

Duration
ID Activity Predecessor O M P TE
(weeks)

A Requirement Analysis - 1 2 3 2.0 2

B SRS Document A 1 1 2 1.2 1

C System Design B 2 3 5 3.2 3

D Database Design B 1 2 3 2.0 2

E Frontend Development C 3 4 6 4.2 4

F Backend Development C,D 3 5 8 5.2 5

G Integration E,F 1 2 4 2.2 2

H Testing G 2 3 5 3.2 3

I Deployment H 1 1 2 1.2 1

5. Gantt / PERT Diagram (Attach here)

[Paste Gantt Chart and PERT Chart here]

6. Questions for Viva Voce

100. What is the Critical Path and why is it important?

101. How is PERT different from CPM?
102. What is float/slack in project scheduling?
103. What are milestones in a Gantt Chart?
104. How do you handle resource conflicts in a Gantt Chart?
 Software Engineering Lab
Experiment No. 5
Software Configuration & Risk Management Documents

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To prepare a Software Configuration Management (SCM) plan and a Risk Management document for
the sample project.

2. Theory

2.1 Software Configuration Management (SCM)

SCM is the discipline of tracking and controlling changes to software. It ensures the integrity and
traceability of the software product throughout its lifecycle.

2.2 Key SCM Activities

Configuration Identification Identifying all items (code, docs, test scripts) that need to be controlled.

Configuration Control Formal process of evaluating and approving changes (Change Control Board).

Configuration Status Accounting Recording and reporting the status of all CIs and changes.

Configuration Auditing Verifying that CIs conform to their documented requirements.

Version Control Managing multiple versions of software (Git, SVN).

2.3 Risk Management

Risk Management is the process of identifying, assessing, and mitigating risks that could adversely
affect a software project.

Risk Identification Brainstorming, checklists, lessons learned, expert judgment.

 Risk Analysis Qualitative (probability × impact matrix) or quantitative analysis.

Risk Prioritisation Ranking risks by Risk Exposure = Probability × Impact.

Risk Mitigation Avoidance, reduction, transfer, acceptance strategies.

Risk Monitoring Tracking risks throughout the project lifecycle.

3. Procedure

SCM Plan
105. List all Configuration Items (CIs): source code, SRS, design docs, test plans, build
scripts.
106. Define a version numbering scheme (e.g., [Link]).
107. Set up a Git repository (GitHub / GitLab – free); define branching strategy.
108. Define the Change Control Board (CCB) members and change request process.

Risk Management
109. Identify at least 10 risks for the OLMS project.
110. Estimate probability (1-5) and impact (1-5) for each risk.
111. Calculate Risk Exposure = Probability × Impact.
112. Propose mitigation strategy for each risk.

4. Sample Risk Register (OLMS)

Prob Impact
ID Risk Description RE Mitigation Owner
(1-5) (1-5)

Requirement changes Freeze requirements

R01 3 5 15 PM
late in development after SRS sign-off

Document code;
Key developer leaves
R02 2 4 8 cross-train team PM
project
members
 Database performance Performance testing
R03 3 4 12 DBA
issues under load in Sprint 3; indexing

Security vulnerabilities Use ORM; conduct

R04 4 5 20 Dev Lead
(SQL injection) security code review

Delayed hardware Use cloud (AWS free

R05 2 3 6 PM
procurement tier) as backup

5. Deliverable

Submit the complete SCM Plan document and Risk Register for your project.

6. Questions for Viva Voce

113. What is a Configuration Item (CI)?

114. What is the role of a Change Control Board?
115. Differentiate between risk avoidance and risk acceptance.
116. What is Risk Exposure?
117. Name two popular version control systems and compare them.
 Software Engineering Lab
Experiment No. 6
Design Phase CASE Tool – Study & Usage

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To study and use a Computer-Aided Software Engineering (CASE) tool for the design phase of the
software development life cycle.

2. Theory

2.1 CASE Tools

CASE tools are software applications that support the activities of software development processes.
They provide automation, diagramming, code generation, and documentation capabilities.

2.2 Classification
Support early lifecycle phases: planning, analysis, design (e.g., Rational Rose,
Upper CASE
StarUML, [Link]).

Support later phases: coding, testing, maintenance (e.g., Eclipse, NetBeans with
Lower CASE
plugins).

Integrated CASE (I-CASE) Cover the entire lifecycle (e.g., Enterprise Architect).

2.3 Recommended Open-Source CASE Tools

Tool Type Key Features

UML, ERD, DFD, Flowcharts; free; no install

[Link] / [Link] Online Diagram Tool
needed
 StarUML UML CASE Tool All UML diagrams; code generation; extensions

UML from text; VS Code plugin; CI/CD

PlantUML Text-to-Diagram
integration

ArgoUML UML CASE Tool Java-based; all 9 UML diagrams; code gen

Enterprise Architect (trial) Full I-CASE MDA, code gen, requirements traceability

Umbrello Linux UML Tool KDE-based; all major UML diagrams

3. Procedure (Using [Link])

118. Open [Link] in a browser (free, no login required).

119. Select 'Create New Diagram' and choose UML template.
120. Explore the shape library: UML, Entity Relation, Flowchart.
121. Recreate the Use Case Diagram from Experiment 3A.
122. Recreate the Class Diagram from Experiment 3B.
123. Export diagrams as PNG and PDF.
124. Optionally: install the [Link] VS Code extension for diagramming inside the IDE.

4. Exercise – Reverse Engineering

Using any CASE tool:

125. Import or re-enter the Book, Member, and Loan classes.
126. Auto-generate a skeleton class diagram from the class definitions.
127. Verify the diagram matches the one you drew manually in Experiment 3B.

5. Observations

Record the tool used, diagrams created, features explored, and any limitations observed:

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________
____________________________________________________________________________________________________

____________________________________________________________________________________________________

6. Questions for Viva Voce

128. What is a CASE tool? List its benefits.

129. Differentiate between Upper CASE and Lower CASE tools.
130. What is forward engineering and reverse engineering in CASE?
131. What is MDA (Model-Driven Architecture)?
132. Compare [Link] with StarUML. When would you use each?
 Software Engineering Lab
Experiment No. 7
Test Cases – Unit Testing & Integration Testing

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To design test cases for unit testing and integration testing of the sample project modules.

2. Theory

2.1 Testing Levels

Testing individual modules/functions in isolation. Developer tests their own
Unit Testing
code. Tools: JUnit, pytest, NUnit.

Testing interactions between integrated modules. Approaches: Big Bang, Top-

Integration Testing
Down, Bottom-Up, Sandwich.

System Testing Testing the complete integrated system against requirements.

Acceptance Testing User validates that the system meets their needs (UAT).

2.2 Unit Testing

Unit tests verify a single function or method. Each test should be independent, repeatable, and fast. A
test typically follows the AAA pattern:
• Arrange: set up inputs and expected outputs.
• Act: call the function under test.
• Assert: verify the output matches expectations.

2.3 Integration Testing Strategies

Big Bang All modules integrated at once. Hard to locate faults.
 Top-Down Testing starts from top-level modules; lower modules are stubbed.

Bottom-Up Lower-level modules tested first; higher modules use drivers.

Sandwich / Hybrid Combines top-down and bottom-up.

2.4 Test Case Template

Actual
TC ID Description Input Expected Output Status
Output

TC-001

3. Procedure

133. Identify modules to test: calculateFine(), issueBook(), searchBook().

134. For each module, identify valid and invalid inputs.
135. Write test cases covering: normal cases, boundary conditions, error cases.
136. For integration testing, define the integration order and stubs/drivers needed.
137. Execute tests and record actual output vs. expected output.

4. Sample Unit Test Cases – calculateFine()

Function: calculateFine(dueDate, returnDate, ratePerDay) → double

TC ID Description Input Expected Output Actual Status

On-time return (no due=5 Jan, ret=5 Jan,

UT-01 Fine = 0.00
fine) rate=1

due=5 Jan, ret=6 Jan,

UT-02 1 day overdue Fine = 2.00
rate=2

due=1 Jan, ret=6 Jan,

UT-03 5 days overdue Fine = 10.00
rate=2
 due=10 Jan, ret=8 Jan,
UT-04 Return before due date Fine = 0.00
rate=2

due=5 Jan, ret=6 Jan, Throw

UT-05 Negative rate (invalid)
rate=-1 IllegalArgumentException

due=null, ret=5 Jan, Throw

UT-06 Null dates
rate=1 NullPointerException

5. Sample Integration Test Cases – Issue Book Flow

TC ID Scenario Precondition Expected Outcome Actual Status

Issue available book to Book available, member Loan created, book

IT-01
valid member registered count -1

Error: Book not

IT-02 Issue unavailable book Book count = 0
available

Issue to member with Member has unpaid

IT-03 Error: Clear fine first
existing fine fine

Member already has 3 Error: Issue limit

IT-04 Issue limit exceeded
books reached

6. Questions for Viva Voce

138. What is a stub? What is a driver? When are they used?

139. What is the difference between unit testing and integration testing?
140. What is test coverage? Name types of coverage metrics.
141. What is regression testing?
142. Name two Java unit testing frameworks and compare them.
 Software Engineering Lab
Experiment No. 8
White Box & Black Box Testing Techniques

Date of Performance Roll No. / Batch Grade / Marks

____________ ____________ ____________

1. Aim

To design test cases using white box (structural) and black box (functional) testing techniques for the
sample project.

2. Theory

2.1 Black Box Testing

Black Box Testing treats the software as a black box. The tester has no knowledge of internal
implementation. Tests are derived from specifications and requirements.

2.2 Black Box Techniques

Equivalence Partitioning Divides inputs into equivalence classes. One test per class is sufficient.

Boundary Value Analysis (BVA) Tests at the boundaries of input partitions (min, min+1, max-1, max).

Decision Table Testing Tests combinations of conditions. Good for business rule testing.

State Transition Testing Tests transitions between states (linked with State Chart Diagrams).

Cause-Effect Graphing Maps causes (inputs) to effects (outputs) and derives test cases.

Use Case Testing Test cases derived directly from use case scenarios.
2.3 White Box Testing
White Box Testing (Glass Box / Structural Testing) examines the internal structure of the code. The
tester needs access to the source code.

2.4 White Box Techniques

Every executable statement is executed at least once. Coverage % = (executed
Statement Coverage
stmts / total stmts) × 100.

Every branch (true/false) of every decision is taken. Stronger than statement

Branch Coverage
coverage.

Every possible path through the code is tested. Most thorough but often
Path Coverage
impractical.

Condition Coverage Each boolean sub-expression evaluates to both true and false.

Cyclomatic Complexity M = E − N + 2P. Indicates minimum number of test cases for branch coverage.

2.5 Cyclomatic Complexity Formula

M = E − N + 2P
Where: E = number of edges in the flow graph
N = number of nodes in the flow graph
P = number of connected components (usually 1 for a single function)
Alternatively: M = Number of decision points + 1

3. Procedure

Black Box Test Cases

143. Choose a function: searchBook(query, filter).
144. Apply Equivalence Partitioning: valid query (title/author/isbn), empty query,
special characters.
145. Apply BVA: query length = 0, 1, 2, 255, 256, 257 characters.
146. Design a Decision Table for multi-condition logic (e.g., book available AND member
registered AND no fine).
White Box Test Cases
147. Select a function: calculateFine().
148. Draw the control flow graph.
149. Calculate Cyclomatic Complexity.
150. Identify independent paths (basis paths).
151. Design one test case per basis path.

4. Black Box – Equivalence Partitioning (searchBook)

TC ID Partition Input Expected Output Actual Status

List of books with 'Java' in

BB-01 Valid – Title query='Java', filter='title'
title

query='9781234567890',
BB-02 Valid – ISBN Single matching book
filter='isbn'

Invalid – Error: Query cannot be

BB-03 query='', filter='title'
Empty empty

Invalid – query='<script>',
BB-04 Sanitised / error message
Special chars filter='title'

BVA – Max query=256 chars,

BB-05 Error: Query too long
length filter='title'

5. White Box – Basis Path Testing (calculateFine)

double calculateFine(Date dueDate, Date returnDate, double ratePerDay) {

if (dueDate == null || returnDate == null) // Node 1 – Decision 1
throw new NullPointerException(); // Node 2
if (ratePerDay < 0) // Node 3 – Decision 2
throw new IllegalArgumentException(); // Node 4
long overdueDays = [Link](dueDate, returnDate); // Node 5
if (overdueDays <= 0) // Node 6 – Decision 3
return 0.0; // Node 7
return overdueDays * ratePerDay; // Node 8
}

Cyclomatic Complexity M = 3 (decision points) + 1 = 4 → 4 independent paths

Path Description Input Expected Output Status

dueDate=null, ret=5
P1 Null date → exception NullPointerException
Jan, rate=1

due=5 Jan, ret=6 Jan,

P2 Negative rate → exception IllegalArgumentException
rate=-1

due=10 Jan, ret=8 Jan,

P3 Return on or before due date 0.0
rate=2

Normal overdue fine due=1 Jan, ret=6 Jan,

P4 10.0
calculation rate=2

6. Comparison: Black Box vs White Box

Criteria Black Box White Box

Knowledge of code Not required Required

Basis for tests Requirements / Specification Source code / Control flow

Who performs Testers Developers

Logic errors, dead code, unreachable

Finds Missing functions, interface errors
paths

Coverage measure Requirement coverage Statement/Branch/Path coverage

7. Questions for Viva Voce

152. What is Cyclomatic Complexity? How is it calculated?

153. What is the difference between branch coverage and path coverage?
154. Explain Equivalence Partitioning with an example.
155. What is Boundary Value Analysis? Why are boundaries important?
156. When would you prefer white box testing over black box testing?
157. What is 100% statement coverage? Does it mean the code is bug-free?
References & Recommended Resources

Textbooks
158. Pressman, R.S. & Maxim, B. (2015). Software Engineering: A Practitioner's Approach
(8th ed.). McGraw-Hill.
159. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson.
160. Jalote, P. (2005). An Integrated Approach to Software Engineering (3rd ed.). Narosa.

IEEE Standards
161. IEEE Std 830-1998 – Recommended Practice for Software Requirements
Specifications.
162. IEEE Std 828-2012 – Standard for Configuration Management in Systems and
Software Engineering.

Open-Source Tools
[Link] / [Link] [Link]

PlantUML [Link]

StarUML [Link]

GanttProject [Link]

ProjectLibre [Link]

Git [Link]

JUnit 5 [Link]

pytest [Link]