Anjuman-I-Islam

MH Saboo Siddik Polytechnic

Operating Systems (OSY)

Microproject
Computer Engineering Department
CO5-I

Title: University Management System

Year: 2024-25

Prepared By:
 Sayyed Abdul Mannan (220447)
 Sayyed Sumaiya Waqar (220448)
 Shaikh Aliya Ambreen (220449)
 Chaudhary Mohd Mujahid (230481)

Under the guidance of: Miss.Ghazala Khan

 MAHARASHTRA STATE BOARD OF
TECHNICAL EDUCATION
Certificate

This is to certify that Mr. Sayyed Abdul Mannan Roll No. 220447 of fifth
semester of Diploma in Computer Engineering of Institute MH Saboo
Siddik Polytechnic (Code: 0002) has completed Microproject satisfactorily
in the subject OSY (22516) for the academic year 2024-25 as prescribed in
the curriculum.

Place: Mumbai Enrolment No.: 2200020319

Date: _____________ Exam Seat No.: _____________

Signature Signature Signature

Project Guide HOD Principal

SEAL OF
INSTITUTE
 MAHARASHTRA STATE BOARD OF
TECHNICAL EDUCATION
Certificate

This is to certify that Sayyed Sumaiya Waqar Ahmed Roll No. 220448 of
fifth semester of Diploma in Computer Engineering of Institute MH Saboo
Siddik Polytechnic (Code: 0002) has completed Microproject satisfactorily
in the subject OSY (22516) for the academic year 2024-25 as prescribed in
the curriculum.

Place: Mumbai Enrolment No.: 2200020324

Date: _____________ Exam Seat No.: _____________

Signature Signature Signature

Project Guide HOD Principal

SEAL OF
INSTITUTE
 MAHARASHTRA STATE BOARD OF
TECHNICAL EDUCATION
Certificate

This is to certify that Shaikh Aliya Ambreen Roll No. 220449 of fifth
semester of Diploma in Computer Engineering of Institute MH Saboo
Siddik Polytechnic (Code: 0002) has completed Microproject satisfactorily
in the subject OSY (22516) for the academic year 2024-25 as prescribed in
the curriculum.

Place: Mumbai Enrolment No.: 2200020363

Date: _____________ Exam Seat No.: _____________

Signature Signature Signature

Project Guide HOD Principal

SEAL OF
INSTITUTE
 MAHARASHTRA STATE BOARD OF
TECHNICAL EDUCATION
Certificate

This is to certify that Chaudhary Mohd Mujahid Roll No. 230481 of fifth
semester of Diploma in Computer Engineering of Institute MH Saboo
Siddik Polytechnic (Code: 0002) has completed Microproject satisfactorily
in the subject OSY (22516) for the academic year 2024-25 as prescribed in
the curriculum.

Place: Mumbai Enrolment No.: 23150360351

Date: _____________ Exam Seat No.: _____________

Signature Signature Signature

Project Guide HOD Principal

SEAL OF
INSTITUTE

Acknowledgement
We wish to express our profound gratitude to our guide Mrs ghazala khan Ma’am who
guided us endlessly in the framing and completion of the micro project. She guided us
on all the main points in that micro project. We are indebted to his constant
encouragement, cooperation, and help. It was her enthusiastic support that helped us in
overcoming various obstacles in the micro-project.

We are also thankful to our Principal, HOD, faculty members and classmates of
Computer Engineering department for extending their support and motivation in the
completion of this micro-project.

Names of Team Members with Roll Nos:

1. Sayyed Abdul Mannan 220447

2. Sayyed Sumaiya Waqar 220448

3. Shaikh Aliya Ambreen 220449

4. Chaudhary Mohd Mujahid 230481

 Annexure I

Microproject Proposal

Title of Microproject: University Management System

I. Aims/Benefits of Microproject
The primary objective of this microproject is to develop reliable, bug-free software. Test cases have
been designed for each page, enabling seamless navigation and transition between them. A test case
is a detailed procedure crafted to assess software functionality, where specific inputs are provided,
and steps are documented. The expected results are then compared with actual outcomes to ensure
accuracy.
II. Course Outcomes Addressed
a) Utilize diverse software testing techniques effectively.
b) Design comprehensive test cases for multiple testing types and levels.
c) Develop a structured test plan tailored to the application’s requirements.
d) Detect and document defects through detailed bug reports.
e) Assess software performance metrics using automated testing tools.

III. Proposed Methodology

 Discussion of the given topic among group members.
 Literature survey
 Submission of project proposal
 Analysis of data
 Work divided among group members
 Compilation of content
 Representation
 Editing the content as per the instructions
 Report Preparation
 Viva and presentation

IV. Action Plan

Week Details of activity Planned Planned Name of
s start date finish date responsible
 team members
1& 2 Discussions & finalization of topics

3 Preparation of abstract

4 Literature review

Submission of microproject proposal(Annexure -

5
I)

6 Collection of information on given topic

7 Collection of all relevant contents

Discussion and submission of outline of the

8
project
Analysis/execution of collected data/information
and Preparation of
9
prototypes/drawings/charts/graphs/
tables/models/circuits/programs etc.

10 Compilation of contents of project

11 Compilation of weekly progress report

12 Preparation of the project report (Annexure II)

13 Viva Voce / Delivery of presentation.

V. Resources Required
Name of
Sr. no. Specifications Qty
resources Remarks
1. Internet Google, Reference websites 1
Microsoft word, Visual
2. Desktop 1 for each
Studio 2022, MS access

Names of Team Members with Roll Nos:

1. Sayyed Abdul Mannan 220447

2. Sayyed Sumaiya Waqar 220448

3. Shaikh Aliya Ambreen 220449

4. Chaudhary Mohd Mujahid 230481

Approved by:
Sign of Faculty:
Name of Faculty: Prof Ghazala Khan
 Annexure II

Microproject Proposal
Title of Microproject: University Management Application

I. Rationale
The purpose of this project is to create a dependable university management system by
applying thorough software testing practices. Through structured test cases and automated
tools, we aim to identify and resolve bugs, ensuring high functionality and accuracy, which are
crucial for efficient university administration and reliable academic operations.

II. Aims/Benefits of Microproject

The main aim of the project is to develop error-free software for the university management
system. Test case preparation and execution help to conduct different types and levels of
testing . The primary purpose of test cases is to determine whether various features within the
system are performing as expected and to confirm that the system satisfies all relevant
standards, guidelines, and user requirements.
III. Course Outcomes Achieved
a) Utilize diverse software testing techniques effectively for the university management
system.
b) Design comprehensive test cases for multiple testing types and levels to ensure system
reliability.
c) Develop a structured test plan tailored to the specific requirements of the university
management application.
d) Detect and document defects through detailed bug reports, ensuring thorough issue
tracking.
e) Assess software performance metrics using automated testing tools to enhance system
efficiency and accuracy.

IV. Literature Review

This project examines the aspect of university administration, focusing on developing a

University Management System. In the 21st century, the use of the internet, computers, and
other electronic devices has made handling various administrative tasks significantly easier. This
project involves the design and implementation of an electronic University Management
System that efficiently manages data in a centralized and organized manner. Additionally, it
provides a user-friendly interface, making it accessible for users with only basic computer skills.

The project was developed using Microsoft Visual Studio, a comprehensive integrated
development environment (IDE) by Microsoft. This IDE is suitable for creating both console and
graphical user interface applications, including Windows form applications and websites. The
database system was designed using Microsoft SQL Server.

Test Cases:
A test case is a defined format used in software testing to verify if a particular application or
software functions correctly. It consists of a set of conditions that need to be checked to
determine whether the actual output meets the expected output. Each test case includes
parameters such as ID, condition, steps, input, expected result, actual result, status, and
remarks.
Parameters of a Test Case:
 Test Case Id: A unique identifier assigned to each condition in the test case.
 Test Case Description: A description of the condition being tested, e.g., checking if
Numerical validation works for the student age input box.
 Test Steps: The steps required to verify the condition.
 Prerequisite: Conditions that must be fulfilled before the test begins.
 Test Data: The input data used during the test.
 Test Expected Result: The expected output after the test is executed.
 Actual Result: The actual output displayed upon execution.
 Status: The outcome of the test (pass, fail, NA, etc.).

Methods of Testing:

Static Testing:

 Involves reviewing the software code and documentation without executing the program.
 Performed early in the development lifecycle and serves to verify the software, aiming to
prevent defects.

Advantages:

 Quick and easy to identify errors.

 Helps detect issues early in the development process.

Disadvantages:

 Time-intensive when done manually.

 Automated tools may support only a limited range of programming languages.

Dynamic Testing:

 Involves executing the software with various inputs to verify that the actual output matches the
expected behavior.
 Conducted later in the development lifecycle to validate the software and fix defects.

Advantages:

 Identifies weak areas that may be missed by static testing.

 Improves software quality by executing the code.

Disadvantages:

 Requires trained professionals to conduct the tests.

 Can be costly as it involves the execution of the software.
 White Box Testing: White box testing involves analyzing the internal structures, data flow, and
code design of the software. It is also referred to as structural testing, clear box testing, or glass box
testing, and its primary goal is to test the inner workings of the software. In white box testing, the
tester has access to the source code and must have knowledge of how the code is structured. Test
cases are developed by examining the code to verify the correctness of the software.

Advantages:

 Easy and straightforward to identify legal input data.

 Can be initiated early in the Software Development Life Cycle (SDLC).

Disadvantages:

 Expensive and complex, especially for large systems.

 Requires testing all possible inputs, which can be time-consuming.

Black Box Testing: Black box testing is a type of software testing where the tester does not need any
knowledge of the internal workings of the software. This method focuses on testing the functionality of
the software, ensuring that it meets user specifications and requirements. It is also known as functional
testing or behavioral testing and is typically performed by software testers. The emphasis is on
validating the software’s functionality based on the provided specifications without knowing the
underlying code.

Advantages:

 Can be performed by non-technical testers.

 Suitable for use in larger systems where focusing only on functionality is critical.
 Disadvantages:

 If the functional specifications are unclear or incomplete, developing effective test cases can be
challenging.

Testing techniques:
1. Static White box testing: It is a type of testing in which program source code is tested without
executing it. Tester only review and examine software design, architecture or code for bug without
executing it. Methods include: Review, Walkthrough and Inspection

a) Reviews: Reviews are a process designed to ensure software quality by evaluating various
aspects of the software. This formal process involves several key elements: identifying
potential problems, following established rules or guidelines, preparing each participant
involved in the review, and compiling a final report based on the findings. Reviews help catch
errors early and verify that the software meets the required standards.
b) Walkthroughs: A walkthrough is initiated by the author of the code or document. During a
walkthrough, the presenter reads through the code or system, and the reviewers listen,
raising questions or concerns as needed. Since it is an informal process, there is no need for a
 moderator, and the emphasis is on verifying the validity and logic of the proposed system. The
presenter then prepares a report based on the feedback received.
c) Inspection: Inspection is a more formal and structured process of reviewing, often involving a
meeting led by a trained moderator. In an inspection, documents or code are thoroughly
reviewed by each participant beforehand. The review process follows a strict methodology,
and participants must be trained to perform the inspection properly. This highly organized
process ensures that every aspect of the software or document is examined in detail, with the
goal of identifying defects early on.

2) Dynamic White box testing: It is a test done by running the code and can also examine the code.
Testers are required to have knowledge of internal implementation. It determines what to test and what
not to test. Methods include: Code functional testing, Code coverage testing, Code complexity testing

A) Code functional testing: This type of testing is done in early phase of testing. It is done before
submitting the code to more extensive phases like coverage testing & complexity testing. Methods of code
functional testing: - Obvious test- Most simplest method. Inputs are known and expected outputs are
covered. - Debug version- In this, we make sure that program is passing through right loops, iterations
right number of times. Entire debugging of code is done using this method. - Debugging tool- They are
tools used to resolve early defects from product/module.
B) Code coverage testing:
Is a measure used to describe the degree to which the source code of a program is tested
• High light aspects of the code which may not be adequately tested and which require additional testing.
- Compiler debugger: it is sufficient for small programs.
- Code coverage analyzer: hook into s/w . Run transparently in the background while testing. ●Each time a
function , line of code , loop is executed , code coverage analyzer record the information
• Code coverage methods:
• Statement Coverage
• Branch Coverage
• Conditional Coverage
• Function Coverage
What is Statement Coverage?
It is one type of white box testing technique that ensures that all the statements of the source code are
executed at least once. It covers all the paths, lines, and statements of a source code. It is used to design
test box cases where it will find out the total number of executed statements out of the total statements
present in the code.
Formula:
Statement coverage = (Number of executed statements / Total number of statements in source code) *
100
Why is statement coverage used?
●To check the quality of the code.
●To determine the flow of different paths of the program.
●Check whether the source code expected to perform is valid or not.
●tests the software’s internal coding and infrastructure

- Branch coverage
Branch Coverage is a white box testing method in which every outcome from a code
module(statement or loop) is tested. The purpose of branch coverage is to ensure that each decision
condition from every branch is executed at least once. It helps to measure fractions of independent
code segments and to find out sections having no branches.

Branch Coverage is a testing metric used to measure how well a program's decision points are
tested. It ensures that all possible branches in the code (such as "if" and "else" conditions) have
been executed during testing. The goal is to verify that every branch condition has been
evaluated both as true and false at least once.

The formula for Branch Coverage is:

text{Branch Coverage} = \frac{\text{Total Number of Branches Executed}}{\text{Total
Number of Branches}} \times 100
This metric helps in identifying areas of the code that may not have been thoroughly tested,
improving the effectiveness of testing by ensuring that all logical paths are explored.

Condition Coverage:

Condition coverage is a form of white-box testing that checks all possible outcomes of conditional
expressions in a program, also known as predicate coverage. The formula for condition coverage is:

Advantages:

 Uncovers untested areas: It identifies parts of the program that are not exercised by existing
test cases.
 Measures coverage quality: It provides a quantitative measure of code coverage, indirectly
assessing the quality of the application or product.
Function Coverage:

Function coverage is a metric used to assess how many functions in a program have been
executed during testing. The formula for function coverage is:

Advantages:

 Granular testing: Allows for testing of individual functions or methods, helping to isolate
and resolve issues.
 Early bug detection: Testing individual functions early helps identify bugs before they
spread across the system.
 Better code understanding: It helps testers and developers understand the codebase at a more
detailed level, improving both code quality and documentation.

Code Complexity Testing (Cyclomatic Complexity):

Cyclomatic complexity is a measure of the number of linearly independent paths in a program, which
indicates how complex a piece of code is. It is calculated using a Control Flow Graph (CFG), where:

 Nodes represent processing steps.

 Edges represent control flow between those steps.

Methods to calculate complexity:

1. Number of regions in the flow graph.

2. V(G) = E - N + 2, where:
o E = Number of edges
o N = Number of nodes
3. V(G) = P + 1, where:
o P = Number of decision points (conditional statements)

Example Calculation:

 For a flow graph with E = 14 and N = 12: V(G)=14−12+2=4V(G) = 14 - 12 + 2 =

4V(G)=14−12+2=4
 Alternatively, if P = 3: V(G)=3+1=4V(G) = 3 + 1 = 4V(G)=3+1=4

Static Black Box Testing:

Static black box testing is a technique that examines an application's functionality without
knowledge of its internal workings. It is performed when the system is not running and
focuses on identifying errors in specification, requirement, or design documents.

Key Advantages:

 Allows testers to identify missing functionalities or misinterpretations in the design.

 Can be conducted early in the software development process, reducing costly defects later
on.
Dynamic Black Box Testing

Dynamic black box testing is a technique that involves testing the software without knowledge of its
internal structure. In this approach, the tester runs the application and interacts with it to observe
its behavior. The focus is on validating the software’s response to both expected and unexpected
inputs, testing for:

 Response to user actions: How the system reacts to various inputs.

 Error identification: Uncovering functional errors, crashes, or unexpected behaviors.
 Performance issues: Checking response time, scalability, and system efficiency.
 Usability and reliability: Ensuring the application is easy to use and performs reliably
under different conditions.

Dynamic black box testing is generally used to ensure that the software functions according to
the user requirements and can handle real-world scenarios effectively.

a) Positive and Negative Testing:

b) Boundary Value Analysis (BVA): Boundary value analysis – Boundaries are very good places for
errors to occur. Hence if test cases are designed for boundary values of the input domain then
the efficiency of testing improves and the probability of finding errors also increases. For
example – If the valid range is 10 to 100 then test for 10,100 also apart from valid and invalid
inputs.
 c) Equivalence Partitioning is a software testing technique that divides the input data of a software
application into distinct groups, known as equivalence classes. The premise behind this
approach is that if one test case from a particular equivalence class produces the same result,
then all other test cases within that class are expected to yield similar outcomes.

V. Actual Methodology Followed

1. Discussion of topic with guide and group members.

2. Literature survey.
3. Submission of project proposal. (Annexure I).
4. Collection of data/information.
5. Analysis of data/information.
6. Compilation of content.
7. Rough draft submission.
8. Editing and reviewing the content.
9. Weekly progress report submission.
10. Final draft submission.
11. Viva Voce/Delivery of presentation

VI. Actual Resources Used

Name of
Sr. no. Specifications Qty
resources Remarks
1. Internet Google, Reference websites 1
2. Desktop Microsoft word 1 for each
MS access, visual basics
3. Software 1 for each
2022
VII. Outputs of the Microproject

This report explores the fundamentals of Linux commands, directory/file manipulation, and the
FIFO page replacement algorithm. Linux is a widely used operating system, and understanding
its basic commands and file management techniques is essential for efficient system
administration.

BASIC LINUX COMMANDS

1. who

- Description: Displays information about currently logged-in users.

- Syntax: who [options]
- Example: who -a (displays all user information)

2. who am i

- Description: Displays information about the current user.

- Syntax: who am i
- Example: who am i (displays current user information)

3. login

- Description: Allows users to log in to the system.

- Syntax: login [username]
- Example: login john (logs in user 'john')

4. passwd

- Description: Changes user

passwords.
- Syntax: passwd [username]
- Example: passwd john
(changes password for user
'john')

5. su

- Description: Switches user

identity.
- Syntax: su [username]
- Example: su root (switches to
root user)
6. pwd

- Description: Displays the current working directory.

- Syntax: pwd
- Example: pwd (displays current directory path)

DIRECTORY/FILE MANIPULATION COMMANDS

1. ls

- Description: Lists directory contents.

- Syntax: ls [options] [directory]
- Example: ls -l (lists files in long format)

2. rm

- Description: Deletes files or directories.

- Syntax: rm [options] [file/directory]
- Example: rm -r mydir (removes directory 'mydir' recursively)

3. mv

- Description: Moves or renames files.

- Syntax: mv [source] [destination]
- Example: mv file1 file2 (renames 'file1' to 'file2')
4. cp

- Description: Copies files.

- Syntax: cp [source] [destination]
- Example: cp file1 file2 (copies 'file1' to 'file2')

5. join

- Description: Joins two or more files.

- Syntax: join [file1] [file2]
- Example: join file1 file2 (joins 'file1' and 'file2')

6. split

- Description: Splits a file into smaller files.

- Syntax: split [file] [prefix]
 - Example: split file1 split_ (splits 'file1' into smaller files prefixed with 'split_')

-l : Option specifies number of lines to split through.

7. cat

- Description: Displays file contents.

- Syntax: cat [file]
- Example: cat file1 (displays 'file1' contents)

8. head

- Description: Displays first few lines of a file.

- Syntax: head [file]
- Example: head -5 file1 (displays first 5 lines of 'file1')

9. tail

- Description: Displays last few lines of a file.

- Syntax: tail [file]
- Example: tail -5 file1 (displays last 5 lines of 'file1')

10. touch

- Description: Creates a new empty file.

 - Syntax: touch [file]
- Example: touch newfile (creates 'newfile')

PAGE REPLACEMENT ALGORITHM

Page replacement is a memory management scheme that is used when a program requires more
memory than is physically available in the system. Operating systems utilize virtual memory to extend
the apparent memory available to applications. When a process accesses a page (a demand page) that
is not in physical memory (a Page Fault), the operating system must decide which page to evict in
order to make room for the required page (page replacement). If the page is already in the memory,
then it is called a Page Hit.
Why is Page Replacement Needed?
 Limited Physical Memory: Systems have a finite amount of RAM, but processes can demand
more memory than is available.
 Efficiency: To ensure that the most frequently used pages remain in memory, while less-used
pages are swapped out.
 Performance: Efficient page replacement can significantly improve system performance by
reducing page faults and speeding up process execution.
How Page Replacement Works:
1. Page Fault: Occurs when a process tries to access a page not currently in physical memory.
2. Eviction Decision: The OS uses a page replacement algorithm to determine which page to evict.
3. Loading the Page: The required page is loaded from disk into the now-available memory space.
4. Updating Tables: The page table and other relevant data structures are updated to reflect the
changes.
Frame: The frame size in memory management refers to the fixed-size block of main memory that is
used to store a page from the secondary storage (like a hard disk).
In operating systems, memory is divided into these small, equal-sized frames, and the logical address
space (like a program or process) is divided into pages of the same size. When a program needs to
access a page that is not in main memory, a page fault occurs, and the operating system loads the page
from secondary memory into an available frame in main memory.

PAGE REPLACEMENT ALGORITHMS

First In First Out (FIFO)
Pages are removed in the order they were added. The oldest
page in memory is replaced first.

Least Recently Used (LRU)

Replaces the page that has not been used for the longest time.
This method tracks page usage over time.
 Let’s focus on the simplest to implement page replacement algorithm that is “First In First
Out” (FIFO).

FIRST IN FIRST OUT

The simplest algorithm for page replacement.
As we know when the demand page is not available in memory, that is a Page Fault, we need
to bring that page from secondary memory to main memory.
When the main memory is already full, we need to replace any of the page in main memory
with demand page. We have to choose which page to replace/remove?
For this purpose, we have some Page Replacement Algorithms, out of which FIFO is the
simplest to implement.
How FIFO works?
1. FIFO algorithm associates the pages with their respective time when that page is loaded
into memory.
2. The oldest page is chosen to be removed from the memory.
3. For this purpose, data structure “Queue” is implemented.
4. Whenever page is loaded into main memory, that page is inserted at the tail of the
queue.
5. Whenever to remove any page, we remove the page at the head of the queue, which is
the oldest one/ the first one to enter into memory or queue.
Let’s look at a visual example below…

Page1 Page2 Page3 Memory

with Frame

TAIL
HEAD
 Demand page: Page4

Page4 is
Page4 Page2 Page3 inserted at
TAIL Tail

HEAD

OR

Page2 Page3 Page4

HEAD TAIL

FIFO Algorithm:

1. Initialize:
 Set up a queue to hold the pages in memory.
 Initialize an empty list or array to store the pages currently in memory.
 Set a counter for page faults to zero.
2. For each page request:
 Check if the page is in memory:
o If the page is already in memory (in the queue), move to the next page
request (no page fault occurs).
 If the page is not in memory (Page Fault):
o If memory is not full (i.e., the queue has space for new pages):
 Add the requested page to the end of the queue.
 Increase the page fault counter by one.
o If memory is full (i.e., the queue is at maximum capacity):
 Remove the page at the front of the queue (the oldest page).
 Insert the new page at the end of the queue.
 Increase the page fault counter by one.
3. End of requests:
 Output the number of page faults.
 Optionally, display the final state of pages in memory.

PROBLEM 1: Find the number of page faults and page hits for the given reference
string.
7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1 Frame Size: 3

7 7 7 2 2

0 0 0 3

1 1 1
 0 0 7 7 7

1 1 1 0 0

3 2 2 2 1

Page Fault: 15
Page Hit: 5 (Page Hit = No of pages – Page faults)

Considering the same problem, but with frame size = 4

7, 0, 1, 2, 0, 3, 0, 4, 2, 3, 0, 3, 2, 1, 2, 0, 1, 7, 0, 1

7 7 7 7 3

0 0 0 0

1 1 1

2 2

3 3 3 2 3
Page Fault: 10
Page Hit: 10

Conclusion and Interpretation:

We came to interpret by solving the above problem with different frame sizes, the Page fault is
inversely proportional to frame size.
 More the frame size, less the page fault occurs.
 The page remaining in the memory for longest time is chosen to be removed, and the
longest time is same as frame size.
 If frame size is 3, then no pages will remain in memory consecutively more than 3
times, instead it will be removed.

C Program to implement FIFO Page Replacement Algorithm:

#include <stdio.h>

int main() {
int pageFrames, pages, pageFaults = 0, currentIndex = 0;

printf("Enter the number of frames: ");

scanf("%d", &pageFrames);

printf("Enter the number of pages: ");

scanf("%d", &pages);

int pageArray[pages], frames[pageFrames];

int found;

printf("Enter the page reference string:\n");

for (int i = 0; i < pages; i++) {
scanf("%d", &pageArray[i]);
}

// Initialize frames array

for (int i = 0; i < pageFrames; i++) {
frames[i] = -1;
 }

for (int i = 0; i < pages; i++) {

found = 0;

// Check if page is already in a frame

for (int j = 0; j < pageFrames; j++) {
if (frames[j] == pageArray[i]) {
found = 1;
break;
}
}

// If page is not found, perform page replacement

if (!found) {
frames[currentIndex] = pageArray[i];
currentIndex = (currentIndex + 1) % pageFrames; //
FIFO order
pageFaults++;
}

// Display current frames content

printf("Frames: ");
for (int j = 0; j < pageFrames; j++) {
if (frames[j] == -1)
printf("- ");
else
printf("%d ", frames[j]);
}
printf("\n");
}

printf("Total
Page Faults: %d\n",
pageFaults);
printf("Total
Page Hits: %d", pages-
pageFaults);
return 0;
}
 ADVANTAGES OF FIFO DISADVANTAGES OF FIFO
Simplicity: FIFO is straightforward to Poor Performance: FIFO often leads to a
implement, making it ideal for initial learning higher page fault rate, especially in cases
and simple applications. where recently accessed pages are more likely
to be accessed again (i.e., the lack of temporal
locality).
Predictability: Since pages are removed in Belady’s Anomaly: FIFO can exhibit
the order they arrive, the algorithm is easy to Belady’s Anomaly, where increasing the
predict and analyse. number of page frames can lead to an
increased number of page faults, contrary to
what is typically expected.
Low Overhead: FIFO requires less Lack of Adaptability: FIFO doesn't adapt
processing power and minimal additional to different workloads, such as programs
resources, so it performs well under simple with high locality of reference, making it
memory management systems. less efficient than other algorithms like
LRU (Least Recently Used).

FIFO is best suited for systems that require minimal processing and can tolerate a
relatively high page fault rate.

VIII. Skills developed/Learning outcomes

- Derive: Derive different possible solutions creatively.
- Data Collection: Collect relevant data from different sources (books/the internet/the
market/suppliers/experts and others through surveys/interviews)
- Designing- Designing microproject with minimum required resources and at low cost.
- Teamwork- Learning to work in team and boost individual confidence.
- Time management- Completion of microproject as scheduled.
- Technical writing- Preparing a report of proposed plan and report.
- Presentation and communication skills: Giving presentation of the micro project
confidently
- Algorithms: Writing and practicing algorithms

IX. Applications of this microproject

1. Performance Optimization: Enhances resource utilization and execution times in various

computing environments.
 2. Operating System Development: Serves as a reference for implementing and comparing
scheduling strategies in OS design.
3. Educational Tool: Provides practical demonstrations of scheduling algorithms for
academic purposes.
4. Real-Time Systems: Informs task prioritization in critical applications like embedded
systems and telecommunications.
5. Cloud Computing and Virtualization: Improves load distribution and minimizes latency in
cloud infrastructures.
6. Job Scheduling in Databases: Aids in efficient task scheduling for data retrieval and
processing in database management systems.
7. Simulation and Modeling: Useful for predicting system behaviour through simulations of
process scheduling scenarios.

Annexure IV
Micro Project Evaluation Sheet

Name of student & Roll No. Sayyed Abdul Mannan - 220447 Enrolment No. 2200020319
Name of programme. Computer Engineering Semester: 5th
Course title: Operating Systems Code: 22516
Title of Micro project: Basic Linux Commands, Directory/File Manipulation and FIFO Page
Replacement Algorithm
Course Outcomes Achieved:
b) Use Operating System tools to perform various functions.
e) Calculate efficiency of different memory management techniques.
f) Apply file management techniques.

Sr Poor Good
Average Excellent Sub
N Characteristics to be accessed (Marks 1- (Marks 6-
(Marks 4-5) (Marks 9-10) total
o 3) 8)
(A) Process and Product Assessment (Convert above total marks out of 6 Marks)
1 Relevance to the course
Literature
2 Review/Information
collection
Completion of the target as
3
per project proposal

Analysis of Data and

4
representation
 5 Quality of Prototype/Model

6 Report presentation
(B) Individual Presentation/Viva (Convert above total marks out of 4 Marks)
7 Presentation

8 Viva

(A) (B)
Total Marks
Process and Product Assessment Individual Presentations & Viva
10
(6 Marks) (4 Marks)

Comments/Suggestions about teamwork/leadership/interpersonal communication

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Name and designation of teacher: _____________________________________________________

Dated Signature: ___________________________________________________________________
Annexure IV
Micro Project Evaluation Sheet

Name of student & Roll No. Shaikh Tauheed - 220457 Enrolment No. 2200020360
Name of programme. Computer Engineering Semester: 5th
Course title: Operating Systems Code: 22516
Title of Micro project: Basic Linux Commands, Directory/File Manipulation and FIFO Page
Replacement Algorithm
Course Outcomes Achieved:
b) Use Operating System tools to perform various functions.
e) Calculate efficiency of different memory management techniques.
f) Apply file management techniques.

Sr Poor Good
Average Excellent Sub
N Characteristics to be accessed (Marks 1- (Marks 6-
(Marks 4-5) (Marks 9-10) total
o 3) 8)
(A) Process and Product Assessment (Convert above total marks out of 6 Marks)
1 Relevance to the course
Literature
2 Review/Information
collection
Completion of the target as
3
per project proposal

Analysis of Data and

4
representation
 5 Quality of Prototype/Model

6 Report presentation
(B) Individual Presentation/Viva (Convert above total marks out of 4 Marks)
7 Presentation

8 Viva

(A) (B)
Total Marks
Process and Product Assessment Individual Presentations & Viva
10
(6 Marks) (4 Marks)

Comments/Suggestions about teamwork/leadership/interpersonal communication

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Name and designation of teacher: _____________________________________________________

Dated Signature: ___________________________________________________________________
Annexure IV
Micro Project Evaluation Sheet

Name of student & Roll No. Deepak Yadav - 220463 Enrolment No. 2200020343
Name of programme. Computer Engineering Semester: 5th
Course title: Operating Systems Code: 22516
Title of Micro project: Basic Linux Commands, Directory/File Manipulation and FIFO Page
Replacement Algorithm
Course Outcomes Achieved:
b) Use Operating System tools to perform various functions.
e) Calculate efficiency of different memory management techniques.
f) Apply file management techniques.

Sr Poor Good
Average Excellent Sub
N Characteristics to be accessed (Marks 1- (Marks 6-
(Marks 4-5) (Marks 9-10) total
o 3) 8)
(A) Process and Product Assessment (Convert above total marks out of 6 Marks)
1 Relevance to the course
Literature
2 Review/Information
collection
Completion of the target as
3
per project proposal

Analysis of Data and

4
representation
 5 Quality of Prototype/Model

6 Report presentation
(B) Individual Presentation/Viva (Convert above total marks out of 4 Marks)
7 Presentation

8 Viva

(A) (B)
Total Marks
Process and Product Assessment Individual Presentations & Viva
10
(6 Marks) (4 Marks)

Comments/Suggestions about teamwork/leadership/interpersonal communication

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Name and designation of teacher: _____________________________________________________

Dated Signature: ___________________________________________________________________
Annexure IV
Micro Project Evaluation Sheet

Name of student & Roll No. Khan Farhan - 230484 Enrolment No. 23150360354
Name of programme. Computer Engineering Semester: 5th
Course title: Operating Systems Code: 22516
Title of Micro project: Basic Linux Commands, Directory/File Manipulation and FIFO Page
Replacement Algorithm
Course Outcomes Achieved:
b) Use Operating System tools to perform various functions.
e) Calculate efficiency of different memory management techniques.
f) Apply file management techniques.

Sr Poor Good
Average Excellent Sub
N Characteristics to be accessed (Marks 1- (Marks 6-
(Marks 4-5) (Marks 9-10) total
o 3) 8)
(A) Process and Product Assessment (Convert above total marks out of 6 Marks)
1 Relevance to the course
Literature
2 Review/Information
collection
Completion of the target as
3
per project proposal

Analysis of Data and

4
representation
 5 Quality of Prototype/Model

6 Report presentation
(B) Individual Presentation/Viva (Convert above total marks out of 4 Marks)
7 Presentation

8 Viva

(A) (B)
Total Marks
Process and Product Assessment Individual Presentations & Viva
10
(6 Marks) (4 Marks)

Comments/Suggestions about teamwork/leadership/interpersonal communication

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

Name and designation of teacher: _____________________________________________________

Dated Signature: ___________________________________________________________________