Members Bookmarks Fresher Jobs Funny Pictures MCA Projects New Member FAQ  



My Profile
Active Members
TodayLast 7 Days more...



Awards & Gifts
Online Exams

Fresher Jobs


Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian cities including Bangalore, Chennai, Hyderabad, Pune or Kochi

Resources


Find educational articles, blogs, discussion threads and other resources.

Colleges


Find details about any college in India or search for courses.

Paid Surveys


website counter



Development of a feature-rich, practical online leave management system


Posted Date: 12 Jan 2008    Resource Type: Articles/Knowledge Sharing    Category: General

Posted By: arjun       Member Level: Bronze
Rating:     Points: 5



Title of the project

Development of a feature-rich, practical online leave management system (LMS)

Abstract of the project

This project is aimed at developing an online leave management system that is of importance to either an organisation or a college . The Leave Management System (LMS) is an Intranet based application that can be accessed throughout the organisation or a specified group/Dept. This system can be used to automate the workflow of leave applications and their approvals. The periodic crediting of leave is also automated. There are features like email notifications, cancellation of leave, automatic approval of leave, report generators etc in this system.

Keywords

Generic Technlogy keywords

Databases, Network and middleware, Programming

Specific Technology keywords

MS-SQL server, HTML, Active Server Pages

Unix, Shell, C, Oracle

Project type keywords

Analysis, Design, Implementation, Testing, User Interface

Functional components of the project

Following is a list of functionalities of the system. More functionalities that you find appropriate can be added to this list. And, in places where the description of a functionality is not adequate, you can make appropriate assumptions and proceed.

There are registered people in the system. Some are approvers. An approver can also be a requestor. In an organization, the hierarchy could be Engineers/Managers/Business Managers/Managing Director etc. In a college, it could be Lecturer/Professor/Head of the Department/Dean/Principal etc.

1. A person should be able to

• login to the system through the first page of the application

• change the password after logging into the system

• see his/her eligibility details (like how many days of leave he/she is eligible for etc)

• query the leave balance

• see his/her leave history since the time he/she joined the company/college

• apply for leave, specifying the from and to dates, reason for taking leave, address for communication while on leave and his/her superior’s email id

• see his/her current leave applications and the leave applications that are submitted to him/her for approval or cancellation

• approve/reject the leave applications that are submitted to him/her

• withdraw his/her leave application (which has not been approved yet)

• cancel his/her leave (which has been already approved). This will need to be approved by his/her Superior

• get help about the leave system on how to use the different features of the system

2. As soon as a leave application /cancellation request /withdrawal /approval /rejection /password-change is made by the person, an automatic email should be sent to the person and his superior giving details about the action

3. The number of days of leave (as per the assumed leave policy) should be automatically credited to everybody and a notification regarding the same be sent to them automatically

4. An automatic leave-approval facility for leave applications which are older than 2 weeks should be there. Notification about the automatic leave approval should be sent to the person as well as his superior

5. A summary report of the leave details of his/her sub-ordinates should be sent to every manager periodically

6. A calender giving the public holidays of the organization/college should be available on the system

Steps to start-off the project

There are couple of alternatives to implement such a system.

A. Microsoft platform: The system is developed using Active Server Pages as the
front end and SQL Server as the back end.

B. Unix-based platform: HTML or even Shell scripting, C programming, any
relational database (eg Postgress or Oracle or even flat files) , and tools in
Unix

The following steps will be helpful to start off the project.

1. Study and be comfortable with technologies such as
a. Active Server Pages/HTML and SQL server.
b. Unix commands, Shell programming, C Programming, Tools like AWK etc.
Some links to these technologies are given in the ‘Guidelines and References’
section of this document

2. Decide on a leave policy (ie, the different types of leave such as earned leave, medical leave etc, the number of days of leave that the employees at different levels are eligible to, etc) and define it formally.

3. Make a database of people at different levels with their roles and form a hirearchy of them, like which role reports to which particular role. Decide on the various details of the people and their roles that would be stored in the database (like employee/registeration-number, name, grade, location, system-login, password in cryptic form, etc)

4. Assign a mail-admin who will create mail-ids for the people in the intranet of your lab or in the internet. These mail-ids will be used for sending automatic notifications and reports. The mail-admin will also take care of assigning the logins to the users of the leave system

5. Since the real-time project needs to be tested in real-time, you can take ‘hours’ as ‘days’ for testing the system. However, the display will still be in ‘days’ only.

6. Create the front-page of the leave system giving a brief description about the system and a login box

7. Create the help-pages of the system in the form of Q&A. This will help you also when implementing the system

8. Create other sub-systems like automatic notification, screens for various functions (like apply,reject,cancel,withdraw etc)



Requirements

Hardware requirements

Number Description Alternatives (If available)
1 PC with 2 GB hard-disk and 256 MB RAM Not-Applicable
2

Software requirements

Number Description Alternatives (If available)
1 Windows 95/98/XP with MS-office Not Applicable
2 MS-SQL server MS-Access
3 Linux Not Applicable
4 Oracle database system POSTgres

Manpower requirements

2 to 3 students can complete this in 4 – 6 months if they work fulltime on it.

Milestones and Timelines

Number Milestone Name Milestone Description

Timeline

Week no.
from the start
of the project Remarks


1 Requirements Specification Complete specification of the system (with appropriate assumptions) including the framing of leave policy etc constitutes this milestone. A document detailing the same should be written and a presentation on that be made. 2-3 Attempt should be made to add some more relevant functionalities other than those that are listed in this document.
2 Technology familiarization Understanding of the technology needed to implement the project. 4-5 The presentation should be from the point of view of being able to apply it to the project, rather than from a theoretical perspective.
3 Database creation A database of atleast 100 entries of employees of all grades should be created. The number of mail-ids to be created need not be 100. It can be around 10 to 20. 5-7 It is important to finalize on the database at this stage itself so that development and testing can proceed with the actual database itself.
4 High-level and Detailed Design Listing down all possible scenarios (like leave application, approval, rejection, cancellation, automatic credit etc) and then coming up with flow-charts or pseudocode to handle the scenario. 7-9 The scenarios should map to the requirement specification (ie, for each requirement that is specified, a corresponding scenario should be there).
5 Implementation of the front-end of the system Implementation of the main screen giving the login, screen that follows the login giving various options, screens for each of the options (application form, cancellation form etc). 10-12 During this milestone period, it would be a good idea for the team (or one person from the team) to start working on a test-plan for the entire system. This test-plan can be updated as and when new scenarios come to mind.
6 Integrating the front-end with the database The front-end developed in the earlier milestone will now be able to update the employee leave database. Other features like mail notification etc should be functional at this stage. In short, the system should be ready for integration testing. 12-13
7 Integration Testing The system should be thoroughly tested by running all the testcases written for the system (from milestone 5). 14-15 Another 2 weeks should be there to handle any issues found during testing of the system. After that, the final demo can be arranged.
8 Final Review Issues found during the previous milestone are fixed and the system is ready for the final review. 16-18 During the final review of the project, it should be checked that all the requirements specified during milestone number 1 are fulfilled (or appropriate reasons given for not fulfilling the same)

Guidelines and References

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/asptutorial.asp (ASP tutorial)

http://www.functionx.com/sqlserver/ (SQL-server tutorial)

http://heather.cs.ucdavis.edu/~matloff/UnixAndC/Unix/CShellII.html (Shell script introduction)



Students Kit

Objective

These guidelines are for the student to adopt to make progress in the project.
Given below are the templates for the documents related to the project. These are just guidelines only. These can be improved by the team.

Requirements Specification (RS)

Following is a template for the RS document. Some example requirements are entered in to it to show how to use the template. Make sure that you enter even the smallest/most trivial requirements also. That would help in validating the system during testing.

No. Requirement Essentialor Desirable Description of the Requirement Remarks
RS1 The system should have a login Essential A login box should appear when the system is invoked. The logins are assigned by the mail-admin
RS2 The system should have help screens Essential Help about the various features of the system should be provided in sufficient detail in a Q&A format. The leave policy should also be part of the help.
RS3 The system should ‘lock’ the login id if wrong password is entered 3 times in a row Desirable This feature will improve the robustness of the application Since the application is going to be used only by the employees of the organization, this feature is not essential. However, if time is there, this will be implemented.
4
5








Database Fields Specification

Employee Number/Registration Number is the Key of the database. The range of valid values entered below as examples need not be taken as such. They can be modified by the team.

No. Field Name Range of valid values for the field Remarks
1 Employee Number/Registration Number 1 to 1000 This is the key field of the database as it is unique for an employee in the organization. This will also serve as the login for the system.
2 Name Up to 15 characters in length. Special characters like underscore are not allowed.
3 Role Pre-defined set (like engineers/managers/etc) The reporting hierarchy is based on the role of the person. For example, an engineer reports to a manager, a manager reports to a business manager etc
4 Email Id Up to 25 characters in length (including the domain name) This field should also be unique for a person because no two employees in an organization can have the same email id.
5 Superior’s Employee Number/Registration Number 1 to 1000 This is the employee number/registration number of the superior of this employee. Other details about the manager can be found in this same database by using the employee number as the key.

If this field is zero, it means the employee is at the highest level in the organization (MD/CEO etc)
5
6


















High Level/Detailed Design (HLD/DD)

Overview of the system

Provide a block diagram depicting where the database will be located, where the application will run etc. Also, provide details about the database server that is going to be used etc.

Design Components

Split the system into its design components. In this case, the components would be user-verification, mail notification, report generation, application, cancellation, approval etc. For each of the components, provide information in the following format. User-verification component is taken as the example.

Component one
User-verification

Purpose
This component will verify if the user who is trying to access the system is a valid user.

Pseudocode
Pseudocode is written to get more clarity on the component so that the actual implementation is made easier. For the user-verification component :

Bool verify_user (emp_no, password1)
{
% get the emp_no (which is the login) and the password from the user.
Get_login_and_password();

% verify if this is a valid login (ie, from 1 to 1000).
If login_id_valid(emp_no)
{
report_error(‘invalid login id’);
return false;
};

% access the database entry for this
if get_database_entry(emp_no, database_entry)
{
% get the encrypted password.
Get_encrypted_password(emp_no, password2);

% decrypt the password. The decrypted password is password3.
Decrypt_password(password2, password3);
% compare the passwords.
If compare_passwords (password1, password3)
{
% enter in to the system.
Enter_system();
}
else % password comparison failed.
Report_error(‘incorrect password. Try again.’);
}
else % unable to get the database entry
report_error (‘invalid login’);
}

Component two

Component three
..














Test-Plan (TP)

The test-plan is basically a list of testcases that need to be run on the system. Some of the testcases can be run independently for some components (report generation from the database, for example, can be tested independently) and some of the testcases require the whole system to be ready for their execution. It is better to test each component as and when it is ready before integrating the components.

It is important to note that the testcases cover all the aspects of the system (ie, all the requirements stated in the RS document).

No. Testcase Title Description Expected Outcome The requirement in RS that is being tested Result
1 Successful User Verification The login to the system should be tried with the login assigned by the admin and the correct password Login should be successful and the user should enter in to the system RS1 Passed
2 Unsuccessful User Verification due to wrong password Login to the system with a wrong password Login should fail with an error ‘Invalid Password’ RS1 Passed
3 Unsuccessful User Verification due to invalid login id Login to the system with a invalid login id Login should fail with an error ‘Invalid user id’ RS1 Passed
4
5



For more details, visit http://www.functionx.com/sqlserver




Responses

Author: punnarao    08 Feb 2008Member Level: Bronze   Points : 3
hi sir
u r project is good

may i know about u r project details

i want how many member r done this project
and what are the each one role and
tell ma please



i have intrest learn about new things
ok thanks sir please reply to me


Feedbacks      
Popular Tags   What are tags ?   Search Tags  
(No tags found.)

Post Feedback


This is a strictly moderated forum. Only approved messages will appear in the site. Please use 'Spell Check' in Google toolbar before you submit.
You must Sign In to post a response.
Next Resource: Some interesting facts we never knew
Previous Resource: PIN CODE AND PUK CODE
Return to Discussion Resource Index
Post New Resource
Category: General


Post resources and earn money!
 
Related Resources


Contact Us    Privacy Policy    Terms Of Use   

SpiderWorks Technologies Pvt Ltd. 2006 - 2007 All Rights Reserved.