SECTZG629T_FR_2012HZ78512

1
Leave Management System with Text Messaging without
Smart Phone or Web
Dissertation work carried out at
Cognizant Technology Solutions Ltd
by
Najeem M
BITS ID: 2012HZ78512
Dissertation submitted for the partial fulfillment of
M.S. Software Engineering Degree
under the Supervision of
Guruprasad Vinjamuri
Assoc. Director – Projects
Cognizant Technology Solutions, Hyderabad
BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE
PILANI (RAJASTHAN)
Nov., 2014

2
BIRLA INSTITUE OF TECHNOLOGY AND SCIENCE,
PILANI
CERTIFICATE
This is to certify that the Dissertation entitled “Leave Management System with
Text Messaging without Smart Phone or Web Interface” submitted by Najeem M,
2012HZ78512 for the partial fulfillment of the requirements of M.S. Software
Engineering degree of BITS, Pilani embodies the work done by him/her under
my supervision.
Signature of the Guide / Spervisor
Assoc. Director – Projects
Cognizant, India
Nov. 22, 2014

3
ABSTRACT
Dissertation Title : Leave Management System with Text
Messaging without Smart Phone or Web
Interface
Name of Supervisor/Guide : Guruprasad Vinjamuri
Name of the Student : Najeem M
BITS ID. No. : 2012HZ78512
Semester : 1st
Semester 2014 – 2015
Course Code : SECTZG629T (DS)
At times we may face internet connectivity issues or PC and smart phone availability
and unable to do our immediate online transactions related to office matters there
arise an alternate idea of simple text messaging based applications or services. In
this approach, an ordinary mobile without smart phone capabilities can be used for
doing all transactions with a few text messages. Many employees wish they could
also do many activities while traveling from one meeting to another and hence
comes the use of mobile phones with SMS.
Proposed solution is based on a web application in PHP and few web services for data
communications. User’s mobile number should be registered with the system to
access the service. User should send username and password via SMS. LMS system
sends data in response to specific user’s query such as leave balance details. At first
the user sends a pre-defined request code via SMS to the SMS gateway service
provider’s registered mobile number. Based on the message code, the gateway
provider forwards the SMS to the PULL application in the mobile application server.
Once the PULL application receives the request it forwards it to the processing
application for further processing. LMS application processes this message and sends
the response to the PULL application which again forwards it to the user via the
service provider.
This solution is useful where user don’t have internet access in PC or no internet
coverage or data plan in mobile where normal carrier network available. User does
not require a data plan for using this service. SMS packages are low cost and sms
works well in poor signal strength as well. This solution also helps in situations where
mobile jammers are active.
Signature of student
Najeem M
BITS ID: 2012HZ78512
Signature of supervisor
Director – Projects
Cognizant, India

4
Acknowledgement
I take this opportunity to express my gratitude to my project guide Guruprasad
Vinjamuri Director – Projects, Cognizant Technology Solutions for providing his
insight, guidance & advice whenever & wherever I needed. His sound understanding
of the IT business, project manager needs, clear communication and guidance has
helped me to shape the direction of this dissertation project work.
I would like to thank Venkatesh Ramaiah, my co-guide for extending the help in
reviewing the documents. I would also like to take this opportunity to thank all my
friends and colleagues who helped me in testing and validating the application.

5
Table of Contents
CHAPTER 1 ................................................................................................... 9
1. BACKGROUND, OBJECTIVE AND SCOPE ................................................. 9
1.1 BACKGROUND........................................................................................9
1.2 OBJECTIVE ...........................................................................................9
1.3 SCOPE ..............................................................................................11
1.3.1 In Scope.......................................................................................11
1.3.2 Out of Scope:................................................................................12
1.4 ASSUMPTIONS, DEPENDENCIES AND RISK.....................................................12
1.4.1 Assumptions .................................................................................12
1.4.2 Dependencies ...............................................................................12
1.4.3 Risks............................................................................................12
CHAPTER 2 ................................................................................................. 13
2. REQUIREMENTS................................................................................... 13
2.1 FUNCTIONAL REQUIREMENTS ....................................................................13
2.2 NON FUNCTIONAL REQUIREMENTS..............................................................14
CHAPTER 3 ................................................................................................. 15
3. REQUIREMENTS ANALYSIS .................................................................. 15
3.1 USE CASE DIAGRAM(S)..........................................................................15
3.2 USE CASE DESCRIPTION .........................................................................16
3.2.1 UC_01_VIEW_ABSENCE_BALANCES: Find the leave balance of employee
16
3.2.2 UC_02_LMS_LEAVE_HISTORY:........................................................17
3.2.3 UC_03_APPLY_SCHEDULE_LEAVE: Searching for a object using the
application..............................................................................................18
3.2.4 UC_04_CANCEL_LEAVE: Cancel Leave .............................................20
3.2.5 UC_05_COMPENSATORY_OFF_REQUEST: Compensatory Off Request...21
3.2.6 UC_06_COMPENSATORY_OFF_STATUS: Compensatory Off Status .......22
3.2.7 UC_07_VIEW_LEAVE_REQUESTS: View leave requests.......................23
3.2.8 UC_08_APPROVE_REJECT_LEAVES: Approve / Reject leaves...............24
3.2.9 UC_09_APPLY_REPORTEE_LEAVE: Apply reports leave .......................26
3.2.10 UC_10_CANCEL_REPORTS_LEAVE: Cancel reports leave .................27
3.2.11 UC_11_LOGIN_AUTHENTICATION: Login authentication .................28
3.2.12 UC_12_ADMIN_ADDUSER: Admin Add user...................................29
3.2.13 UC_13_ADMIN_LISTUSERS: Admin List users................................30
3.2.14 UC_14_COMMAND_OS: Develop command operating system ..........31
3.2.15 UC_15_MOBILE_SIMULATOR: Develop mobile simulator .................32
CHAPTER 4 ................................................................................................. 34
4. SOLUTION ........................................................................................... 34
4.1 PROPOSED SOLUTION ............................................................................34
4.1.1 Architecture:.................................................................................34
4.1.2 LMS Application.............................................................................34
4.1.3 Mobile API ....................................................................................34

6
4.2 SYSTEM REQUIREMENTS .........................................................................35
4.2.1 Software Requirements for End Users ..............................................35
4.2.2 Software Used in Development and Deployment................................35
4.3 HARDWARE REQUIREMENTS .....................................................................35
4.4 SOLUTION ARCHITECTURE .......................................................................36
4.4.1 SMS Gateway Server .....................................................................37
4.4.2 LMS API .......................................................................................37
4.4.3 Mobile Carrier ...............................................................................37
4.4.4 Mobile Phone ................................................................................37
4.4.5 Data Source..................................................................................37
4.5 INFRASTRUCTURE DESIGN .......................................................................37
CHAPTER 5 ................................................................................................. 38
5. DETAILED DESIGN (LOW LEVEL) ......................................................... 38
5.1 FLOW DIAGRAMS..................................................................................38
5.2 SEQUENCE DIAGRAMS............................................................................39
5.3 ACTIVITY DIAGRAM ...............................................................................40
CHAPTER 6 ................................................................................................. 42
6. DETAILED SYSTEM DESIGN ................................................................. 42
6.1 COMMAND SYSTEM DESIGN .....................................................................42
6.1.1 Instruction set: .............................................................................42
6.1.2 Outbound end point URL: ...............................................................43
6.1.3 Error Codes: .................................................................................43
6.1.4 Operation Management Design: ......................................................44
6.1.5 Messaging Design..........................................................................44
6.1.6 Simulator Design...........................................................................44
CHAPTER 7 ................................................................................................. 45
7. CONSTRUCTION & UNIT TESTING........................................................ 45
7.1 CODING STRATEGY ...............................................................................45
7.1.1 Using Top-down approach ..............................................................45
7.1.2 Readable code...............................................................................45
7.1.3 Avoid declaring unused variables.....................................................45
7.1.4 Proper indentation .........................................................................45
7.1.5 Incorporated comments wherever necessary.....................................45
7.2 BEST PRACTICES ..................................................................................45
7.3 CODING CONVENTION ............................................................................45
7.4 CONSTRUCTION ...................................................................................45
7.5 CODE REVIEW .....................................................................................46
7.6 UNIT TESTING .....................................................................................46
CHAPTER 8 ................................................................................................. 47
8. QUALITY ASSURANCE (QA) ................................................................. 47
8.1 QA STRATEGY .....................................................................................47
8.2 QA SCOPE .........................................................................................47
8.3 FUNCTIONAL QA ..................................................................................47
8.4 QA ASSESSMENT..................................................................................47
CHAPTER 9................................................................................................... 48
9. A FEW APPLICATION SCREENSHOTS ................................................... 48

7
9.1 LOGIN ..............................................................................................48
9.2 VALIDATE INSTRUCTIONS ........................................................................49
9.3 VALIDATE MOBILE .................................................................................49
9.4 COMMAND ORDER .................................................................................50
9.5 RESPONSE FACTORY METHOD....................................................................51
9.6 AFTER LOGIN CONSTRUCT INITIAL OPTIONS ...................................................52
9.7 CONSTRUCT APPLY LEAVE RESPONSE ...........................................................54
9.8 APPLY LEAVE.......................................................................................56
9.9 VIEW ABSENCE BALANCE ........................................................................57
9.10 ONLINE SIMULATOR (DEVELOPED FOR TESTING AND DEBUGGING) .........................59
CHAPTER 10 ................................................................................................. 60
10. FUTURE EXTENSIBILITY................................................................... 60
10.1 SCOPE FOR FUTURE EXTENSION.................................................................60
10.2 GUIDELINES........................................................................................60
CHAPTER 11 ................................................................................................. 61
11. ADVANTAGES TO COGNIZANT .......................................................... 61
11.1 INTERNAL ADVANTAGES ..........................................................................61
11.2 BUSINESS ADVANTAGES .........................................................................61
APPENDIX A ............................................................................................... 62
TERMINOLOGIES ........................................................................................ 62
REFERENCES .............................................................................................. 63

8
List of Tables
Table 1 .........................................................................................................13
Table 2 .........................................................................................................17
Table 3 .........................................................................................................18
Table 4 .........................................................................................................20
Table 5 .........................................................................................................21
Table 6 .........................................................................................................22
Table 7 .........................................................................................................23
Table 8 .........................................................................................................24
Table 9 .........................................................................................................25
Table 10 .......................................................................................................26
Table 11 .......................................................................................................27
Table 12 .......................................................................................................29
Table 13 .......................................................................................................30
Table 14 .......................................................................................................31
Table 15 .......................................................................................................32
Table 16 .......................................................................................................33
Table 18 .......................................................................................................43
Table 19 .......................................................................................................44
Table 20 .......................................................................................................62
List of Figures
Figure 1 ........................................................................................................15
Figure 2 ........................................................................................................36
Figure 3 ........................................................................................................37
Figure 4 ........................................................................................................38
Figure 5 ........................................................................................................39
Figure 6 ........................................................................................................40
Figure 7 ........................................................................................................41
Figure 8 ........................................................................................................41
Figure 9 ........................................................................................................48
Figure 10 ......................................................................................................49
Figure 11 ......................................................................................................49
Figure 12 ......................................................................................................50
Figure 13 ......................................................................................................51
Figure 14 ......................................................................................................52
Figure 15 ......................................................................................................53
Figure 16 ......................................................................................................54
Figure 17 ......................................................................................................55
Figure 18 ......................................................................................................56
Figure 19 ......................................................................................................56
Figure 20 ......................................................................................................57
Figure 21 ......................................................................................................58
Figure 22 ......................................................................................................59

9
CHAPTER 1
Background, Objective and Scope
1. Background, Objective and Scope
1.1 Background
Usually web applications and Smart phone applications are helping in accessing
office network and applications to help doing day to day activities. But what will
happen, if there is no internet connection or availability of smart devises? Then
there arises a question of simple text messaging (SMS) based application
interface. Many banks are providing SMS based solutions to their clients for
balance enquiry, check book request, and much more. Thinking in similar lines, I
came across with an idea of accessing office applications via SMS. The proposed
LMS application and its API development made it simple to access the office
network and do emergency transactions. Here the system is built with a
command operating system from scratch.
1.2 Objective
Cognizant is using Leave Management System which has Web Interfaces and Smart
Phone applications. But there are many situations where users can’t access internet
via mobile applications or web applications. I came up with a simple text messaging
system where user can use his mobile without internet but send SMS only to access
the LMS.
There are situations where user can’t access internet:
1. People having no data plan in their mobile
2. No internet access via web
3. This solution is helpful to people who are in location where mobile jammers or
poor network, where SMS work well.
4. In an ODC where Cognizant network is disabled and smart phoned are not
allowed
The main objectives of this solution are:
1. To help employees to do many activities while traveling from one meeting to
another and hence comes the use of mobile phones with SMS.

10
2. To help the employees of the organization to manage absence even if no internet
connectivity.
3. To provide a simple interface to access the leave management system outside the
office network, even in remote areas.
4. To avoid the requirement of a mobile data plan for managing leave in real time.
5. To utilize low cost SMS packages even in poor signal strength to communicate
with LMS systems.
6. To eliminate a client application to install in mobile for accessing the LMS
system

11
1.3 Scope
Develop a Leave Management System with all basic features.
Develop an interactive simple text messaging application based on ordinary
GSM mobiles for employee leave management system. PHP is the business
layer and agile methodology is for project development
1.3.1 In Scope
Develop an LMS application with all basic features, which serves as business
layer
A mobile API application part of the presentation layer in overall system
architecture where PHP based web application will be communicating with
LMS API and mobile gateway server. Services with in mobile gateway server
will communicate with mobile phones for requests and responses.
No internet or smart phones required for the service access
Scope of the solution and development are:
1. Create fully functional LMS application (No UI)
2. Create web application for interfacing with LMS
3. Create web application for listening to the SMS Gateway data
4. Interface the LMS with SMS server API for mobile access.
5. Create Response options and manage it via ordinary mobile
6. Utilize a web interface for managing the registered users for the service
7. Create a web interface (simulator) for testing and validation in real time.
8. Command validation and functional testing
The Platform:
1. User’s ordinary mobile with SMS capability is the client device
2. PHP, MVC (CodeIgniter)
3. Apache server
4. MySQL
5. SMS Gateway
6. SMS mobile command system – custom developed for this project
7. LMS API (Simulation)

12
Development Methodology:
Agile Methodology is in scope for application design, development, testing and deployment. A
progressive elaboration method based on weekly sprints.
1.3.2 Out of Scope:
Mobile client application is not part this whole of system.
1.4 Assumptions, Dependencies and Risk
1.4.1 Assumptions
o Ordinary GSM mobiles might have simple text messaging
capabilities.
o Mobile network availability is not a constraint
o SMS gateway server and web server might be available with 99%
up time.
1.4.2 Dependencies
o SMS gateway server
o Carrier network
1.4.3 Risks
o If the carrier network signal strength is feeble, there is a chance of
losing the SMS.
o If the SMS gateway server has reached a maximum request limit,
response handling may not happen
o TRAI has put limitations on daily SMS from user mobile is 100

13
CHAPTER 2
Requirements
2. Requirements
2.1 Functional Requirements
Sl. No Requirement Description
1 Find the leave balance of
employee
User should be able to get his/her leave
balance information.
2 View LMS leave history User should be able to get previous old
leave history.
3 Apply / Schedule Leave User should be able apply or schedule
leave. User should have various leave
options such as Sick leave, personal leave,
vacation leave and compensatory off.
4 Cancel Leave User should be able to cancel leave
5 Compensatory Off Request User should be able to request
compensatory off.
6 Compensatory Off Status User should be able to check compensatory
off status
7 View leave requests User should be able view his/her leave
requests
8 Approve / Reject leaves HCM manager should be able to approve or
reject leaves applied by reports
9 Apply reports leave. HCM manager should be able to apply
reports leave
10 Cancel reports leave HCM manager should be able to cancel
reports leave
11 Login Authentication User should be authenticated against
employee id, password and registered
mobile number.
12 Admin Add user (Web) Admin should be able to add new user to
LMS
13 Admin List users (Web) Admin should be able to view list of
registered users
14 Develop command operating
system
Develop a command operating system and
create API for interfacing with LMS
application
15 Develop mobile simulator Develop a simulator application to test and
debug application
Table 1

14
2.2 Non Functional Requirements
2.1.1. Develop Complete LMS application without UI as per functional requirements
2.1.2. Develop web application with UI only for Add new user and list and view users.
2.1.3. Application should support all type of mobile devices which supports short
message service (SMS), without internet access.
2.1.4. System should work with usual SMS charges.
2.1.5. Reduce the number requests for each operational scenarios

15
CHAPTER 3
Requirements Analysis
3. Requirements Analysis
3.1 Use Case Diagram(s)
Figure 1

16
3.2 Use Case Description
Following are the detailed functional requirements in Use case format for the system:
3.2.1 UC_01_VIEW_ABSENCE_BALANCES: Find the leave balance
of employee
Use Case ID: UC_ 01_VIEW_ABSENCE_BALANCES
Use Case Name: Find the leave balance of employee
Summary This use case describes the steps involved by the user to check leave
balance
Primary Actor The Mobile-user
Pre-conditions • SMS capability in mobile is required
Primary Flow:
• User sends specific command word (VAB) to LMS number.
• LMS system send list of result to user as follows:
o Compensatory Off: 0.00 Days
o Personal Leave: 2.00 Days
o Sick Leave: 4.50 Days
o Vacation Leave: 5.00 Days
o Vacation Leave Carry Fwd.2013: 0.00 Days
Trigger None.
Post-conditions • The User successfully gets a list of result leave balances.
Alternate Flow:
AF1.1 • None.
Frequency Multiple

17
Exceptions Send error code and friendly message to mobile and save error to log
Related Use Cases None
Includes None
Extends / Uses None
Table 2
3.2.2 UC_02_LMS_LEAVE_HISTORY:
Use Case ID: UC_ 02_VIEW_LMS_LEAVE_HISTORY
Use Case Name: LMS Leave history of employee for specific year
Summary Summary of total leaves taken by the employee in each category in a
specific year.
Pre-conditions • . SMS capability in mobile is required
Primary Flow:
MF1
• User sends specific command word (LLH) to LMS number
• System responds with a question:
o Enter Year <LLH> <YYYY> [format]
• User enter the command word and year
• Example LLH 2012
• System will send a summary of leaves for each category
o Compensatory Off: 2.00 Days
o Personal Leave: 11.00 Days
o Sick Leave: 7.50 Days
o Vacation Leave: 14.00 Days
Trigger NA

18
Post-conditions • The User successfully gets leave history of specific year
Alternate Flow: • NA
Frequency Multiple
Includes None
Extends / Uses None
Table 3
3.2.3 UC_03_APPLY_SCHEDULE_LEAVE: Searching for a object
using the application
Use Case ID: UC_03_APPLY_SCHEDULE_LEAVE
Use Case Name: Apply / Schedule Leave
Summary User enters the start date, end date, absence name and partial days in
sequence of messages.
Pre-conditions • SMS should be activated in mobile.
Primary Flow:
MF1
• User sends command word ASL start date. end date
• System responds with options as follows:
o Compensatory Off (available balance) <CO>
o Loss of pay (available balance) <LP>
o Personal Leave (available balance) <PL>
o Sick Leave (available balance) <SL>

19
o Vacation Leave (available balance) <VL>
• User should respond back with the code in bracket
• For example AVL, means apply vacation leave.
• System will respond with the following options for any partial
days
o All days <PAD>
o End day only <PED>
o None <PND>
o Start day only <PSD>
o Start and end days <PSE>
• User responds back with the code in bracket.
• For example PND, means no partial days.
• System respond back as follows
o Duration for your leave is calculated as (number of
days)
o Enter any comments <ALC> <your comment>
• User respond back with comment
• For example: ALC Going home for Pooja
• System responds back and say success message.
• For sick leave and loss of pay reason for leave is an additional
option which will be prompted.
• For loss of pay options will be sent to user’s mobile
o Loss of pay medical <LPM>
o Loss of pay personal <LPP>
• For sick leave <SL>
Trigger NA
Post-conditions • The User successfully applied leave.
Alternate Flow:
AF1.1
• The User can change the options and the system will respond
back accordingly for various leave types.
Frequency Multiple

20
Related Use Cases UC_11_LOGIN_AUTHENTICATION
Includes None
Extends / Uses None
Table 4
3.2.4 UC_04_CANCEL_LEAVE: Cancel Leave
Use Case ID: UC_ 04_CANCEL_LEAVE
Use Case Name: Cancel Leave
Summary User can cancel leave after getting the response on available open
leave requests
Pre-conditions • SMS should be activated in mobile
Primary Flow: MF
• User sends command word (ACL) to LMS number.
• System responds back:
o Start date <STA> <MM/DD/YYY>
o End date <END> <MM/DD/YYYY>
• System cancels the leaves and sends response back.
• If error system will repeat the input question.
Trigger NA.
Post-conditions • The User successfully cancelled leave.
Alternate Flow:
AF1.1 NA

21
Frequency Multiple
Includes None
Extends / Uses None
Table 5
3.2.5 UC_05_COMPENSATORY_OFF_REQUEST: Compensatory
Off Request
Use Case ID: UC_05_COMPENSATORY_OFF_REQUEST
Use Case Name: Request for compensatory off for holiday work
Summary Employee can request compensatory off
Pre-conditions • SMS should be activated in mobile
Primary Flow:
• User sends command word (COR) to LMS number
• System responds with questions successively:
o Reply with Holiday worked info <HW> <number>
<MM/DD/YYYY>
• User responds back with answer
• System records the request and sends response message
Trigger NA.
Post-conditions • The User successfully requested Compensatory Off.

22
Alternate Flow: NA
Frequency Multiple
Includes None
Extends / Uses None
Table 6
3.2.6 UC_06_COMPENSATORY_OFF_STATUS: Compensatory Off
Status
Use Case ID: UC_06_COMPENSATORY_OFF_STATUS
Use Case Name: Compensatory Off Status.
Summary Users can view compensatory Off status by sending relevant command
word and parameters.
Primary Flow:
• User sends command code (COS) to LMS number
• System responds back:
o Date <CS> <MM/DD/YYY>
• User sends the response
• System responds with:
o Approved
o Denied

23
o Pending with HR
o Submitted
Trigger NA.
Post-conditions • User got status message successfully
Alternate Flow: NA
Frequency Multiple
Includes None
Extends / Uses None
Table 7
3.2.7 UC_07_VIEW_LEAVE_REQUESTS: View leave requests
Use Case ID: UC_07_ VIEW_LEAVE_REQUESTS
Use Case Name: View leave requests
Summary User can view the leave requests
Primary Flow:
• User send VLR to LMS number
• System responds with <type of leave> <MM/DD/YYY>
<MM/DD/YYYY>

24
• User sends the response ex: VPL 10/10/2014 10/11/2014
• Type of leaves are:
o View Compensatory Off <VCO>
o View Loss of pay <VLP>
o View Personal Leave <VPL>
o View Sick Leave <VSL>
o View Vacation Leave <VVL>
• System responds with a list of leaves
• System shows last 10 entries from the database
Trigger NA.
Post-conditions • User got leave details successfully
Alternate Flow: NA
Frequency Multiple
Includes None
Extends / Uses None
Table 8
3.2.8 UC_08_APPROVE_REJECT_LEAVES: Approve / Reject leaves
Use Case ID: UC_08_ APPROVE_REJECT_LEAVES
Use Case Name: Approve / Reject leaves
Summary HCM supervisor can approve / reject leave requests.

25
Primary Flow:
• User sends command code <MAR><Report’s ID>
• System asks for <type of leave> <MM/DD/YYYY>
<MM/DD/YYYY>
• System again responds back with from date, to date, type of leave,
number of days as statement
• System asks to respond with options, ex also shows:
o Reply with
APR to Approve
DNY to Deny
PBK to pushback
• User responds back with option
• System responds back with success or failure message
Trigger NA.
Alternate Flow: NA
Frequency Multiple
Includes None
Extends / Uses None
Table 9

26
3.2.9 UC_09_APPLY_REPORTEE_LEAVE: Apply reports leave
Use Case ID: UC_09_ APPLY_REPORTEE_LEAVE
Use Case Name: Apply reports leave.
Summary HCM supervisors can apply leave for reports
Primary Flow:
• User sends command code <ARL><Report’s ID>
<MM/DD/YYYY>
• Follow as in UC_03_APPLY_SCHEDULE_LEAVE
Trigger NA.
Alternate Flow: NA
Frequency Multiple
Related Use Cases UC_03_APPLY_SCHEDULE_LEAVE
Includes None
Extends / Uses None
Table 10

27
3.2.10 UC_10_CANCEL_REPORTS_LEAVE: Cancel reports leave
Use Case ID: UC_10_ CANCEL_REPORTS_LEAVE
Use Case Name: Cancel reports leave
Summary Users can cancel reports leave.
Primary Flow:
• User sends command code < CRL ><Report’s ID>
<MM/DD/YYYY>
• Follow as in UC_ 04_CANCEL_LEAVE
Trigger NA.
Post-conditions • User got status message successfully cancelled reports leave
Alternate Flow: NA
Frequency Multiple
Related Use Cases UC_ 04_CANCEL_LEAVE
Includes None
Extends / Uses None
Table 11

28
3.2.11 UC_11_LOGIN_AUTHENTICATION: Login authentication
Use Case ID: UC_11_ LOGIN_AUTHENTICATION
Use Case Name: Login Authentication
Summary Users get authenticated based on input.
Primary Flow:
• User sends initial command < LMS > <User ID> <password>
• System authenticate user and send a list of options to proceed
• Options are the entry command word in each use case.
• Commands are:
o View Absence Balance VAB
o LMS Leave History LLH
o Apply / Schedule Leave ASL
o Cancel Leave Request CLR
o Compensatory off request COR
o Compensatory off status COS
o View leave requests VLR
o Manager approve reject MAR
o Apply reports leave ARL
o Cancel reports leave CRL
Trigger NA.
Post-conditions • User got authentication
Alternate Flow: NA
Frequency Multiple

29
Related Use Cases NA
Includes None
Extends / Uses None
Table 12
3.2.12 UC_12_ADMIN_ADDUSER: Admin Add user
Use Case ID: UC_12_ADMIN_ADDUSER
Use Case Name: Admin Add user (via LMS web interface)
Summary New users added to the system.
Primary Actor Admin
Pre-conditions • None.
Primary Flow:
• User login
• Click on add new user link
• Web form loads
o Name <textfield>
o Employee id <textfield>
o Password <password>
o Email <textfield>
o Mobile <textfield>
o Manager <textfield>
• User fills and submits
Trigger None

30
Post-conditions • Success fully registered. Thank you page.
Alternate Flow: NA
Frequency Multiple
Exceptions Show friendly message to UI and save error to log
Includes None
Extends / Uses None
Table 13
3.2.13 UC_13_ADMIN_LISTUSERS: Admin List users
Use Case ID: UC_13_ADMIN_LISTUSERS
Use Case Name: Admin List users (via LMS web interface)
Summary Users get authenticated based on input.
Primary Actor Admin
Primary Flow:
• User login
• Click on users link
• List will be displayed with
o Name,
o eid,
o type of leaves,
o available balance in each

31
o edit link
• User clicks on edit link.
• Web form loads (pre populated values)
o Name <textfield>
o Employee id <textfield>
o Password <password>
o Email <textfield>
o Mobile <textfield>
o Manager <textfield>
• User changes and submits
Trigger None
Post-conditions • Success fully updated.
Alternate Flow: NA
Frequency Multiple
Exceptions Show friendly message to UI and save error to log
Includes None
Extends / Uses None
Table 14
3.2.14 UC_14_COMMAND_OS: Develop command operating system
Use Case ID: UC_14_COMMAND_OS
Use Case Name: Develop command operating system

32
Summary Based on sms command subroutine API calls to be made with the help of
command operating system.
Primary Actor system
Pre-conditions Command template system should be available in database
Primary Flow:
System receives SMS command. System will check order of command
based on the tracking file with mobile number. System further checks the
existence of the command and route the request to respective API function
internally. Subroutine calls will occur and system responds back with
results.
Trigger None
Post-conditions • Success fully updated.
Alternate Flow: NA
Frequency Multiple
Exceptions Command not found, invalid command, unknown exception
Includes None
Extends / Uses None
Table 15
3.2.15 UC_15_MOBILE_SIMULATOR: Develop mobile simulator
Use Case ID: UC_15_MOBILE_SIMULATOR
Use Case Name: Develop mobile simulator

33
Summary Equivalent to mobile but web based simulator
Primary Actor User
Primary Flow:
• Web form loads with
o Simulator screen <textarea>
• User type in command and input string
• Submits
• System responds with required response.
• User clicks reply button
• New blank simulator box appears
• User types in new command and sends
• Response will be displayed on the same text area.
Trigger None
Post-conditions NA
Alternate Flow: NA
Frequency Multiple
Exceptions Show friendly message to textarea and save error to log
Includes None
Extends / Uses None
Table 16

34
CHAPTER 4
Solution
4. Solution
4.1 Proposed Solution
4.1.1 Architecture:
Infrastructure design based on Web Server, SMS Gateway Server, Mobile Carrier and
Mobile devices and LMS API
4.1.2 LMS Application
LMS application for managing leaves of employees for all types of leaves and partial day
adjustments. Create a relational database schema and design modular application with
MVC architecture.
4.1.3 Mobile API
SMS over HTTP is another concept used here. Various API integrations over multiple
platforms like web server, SMS server, Mobile networks etc.
In PHP development, I'm using MVC framework with full object oriented concepts.
There is one mobile device which sends request command word as SMS to a specific
number. SMS gateway tracks that and passes to a PULL service from web server. Web
application server (web server) process the data and interface with LMS API. Based on
request, it will send the required options to SMS gateway via REST API. SMS server
send that data to mobile as SMS. User further select his/her options and send back to
same number. Server processes each request with command words and information
passed by the user.
The application is based on PHP in the business layer and MySQL in the data layer. User
will use ordinary mobile phone.

35
4.2 System Requirements
4.2.1 Software Requirements for End Users
Operating System: Ordinary GSM mobile phones or any other mobile
phones
4.2.2 Software Used in Development and Deployment
Operating System : Linux for Web Hosting, Ordinary Mobile
Languages : PHP 5.4
Framework : Code Igniter
Database : MySQL 5.5
Messaging : SMS Gateway Server
Web server : Apache
Application Server : NA
Custom tools : Mobile command system (developed for this project)
Commercial Packages (COTS): None
Testing : Manual testing using custom web based simulator
: Using Samsung galaxy, Android mobile
: Using ordinary Samsung mobile (not smart phone)
Development environment (IDE): Eclipse
4.3 Hardware Requirements
This configuration is oriented for standard environments to support up to 500 mobile
phones.
Recommended configuration:
• 100 GB of disk volume
• 4 CPU cores
• 8 GB RAM memory
• Cache size based on the amount of recalls and downloads performed from Web
Console.

36
4.4 Solution Architecture
Figure 2
Data Sources
MySQL
Services LDAP / LMS
Data Access Layer
Code Igniter
Data Access
Components
Code Igniter
Data Helpers Service Agents
Business Layer
Apache Server PHP LMS
Presentation Layer
Code Igniter
Framework
Code Igniter
Service Helpers SMS Server API
Mobile Carrier
Network/Server Mobile
SMS
H
T
T
P
SMS Gateway
Server
SMS

37
4.4.1 SMS Gateway Server
A gateway server which has applications those supports http requests and responses from
the mobile carrier server
4.4.2 LMS API
LMS API is a business layer application programming interface for LMS application
which is used by web server.
4.4.3 Mobile Carrier
Mobile phone connection providers network with server
4.4.4 Mobile Phone
End user input devise which is an ordinary mobile.
4.4.5 Data Source
Local data accessibility components and databases
4.5 Infrastructure Design
Figure 3

38
CHAPTER 5
Detailed Design (Low Level)
5. Detailed Design (Low Level)
5.1 Flow Diagrams
Figure 4

39
5.2 Sequence Diagrams
Figure 5

40
5.3 Activity Diagram
Figure 6

41
5.4 Class Diagrams
Figure 7
Figure 8

42
CHAPTER 6
Detailed System Design
6. Detailed System Design
6.1 Command System Design
Command system is the main operating system for the application
6.1.1 Instruction set:
Ordinary mobile phone can send SMS in plain text format only. So there is a requirement
for identifying and tracking user request for each operation. For one specific operation,
multiple instructions to be send. A command system is developed for the same.
For example, initially user needs to send LMS <USERID> <PASSWORD> to get
authentication. Her LMS is a command. Similarly there are more than 60 commands in
this system.
Every time system will instruct user to respond with proper command and data to
perform the desired operation. This command based instructions are custom built for this
project, which is major part of the work.
A few of the instructions for the command set used in the application are bellow:
Sl.No. Command Example Data Operation
1 LMS 335886 mypass Login authentication
Initial commands
2 VAB View Absence Balance
3 LLH LMS Leave History
4 ASL Apply / Schedule Leave
5 CLR Cancel Leave Request
6 COR Compensatory off
request
7 COS Compensatory off status
8 VLR View leave requests
9 MAR Manager approve reject
10 ARL Apply reports leave
11 CRL Cancel reports leave

43
Leave Request
12 CO Comp Off
13 PL PL PND 10/10/2014 10/11/2014 Personal Leave
14 SL Sick Leave
15 VL Vacation Leave
Partial leaves
16 PAD All
17 PED End
18 PND None
19 PSD Start
20 PSE Start end
Table 17
6.1.2 Outbound end point URL:
In SMS API, the end point URL is set as:
http://lms.najeem.com/getdata/sim
Request is tracked in the end point URL where the application initiated. Mobile
number of sender and message will be tracked in the URL.
$message = $_REQUEST[‘msg’];
$mobile = $_REQUEST[‘’mobile];
$message usually contains the command and data.
6.1.3 Error Codes:
A validation system has been developed to check the command is sending in a
right order or not. If user is sending a command in wrong place, system will
respond back with proper error codes. On failure due to any reason, an error
message with error code will be sent to the mobile phone. On error, user can
repeat the same step immediately.
For example:
Invalid mobile number – code 6007
A few error codes are listed here:
Sl.No. Error Code
1 Not authenticated 6000
2 Invalid request 6001

44
3 Command failed, try again same command 6008
4 Invalid credentials 6003
5 Invalid command 6005
6 Command not found 6004
7 Unusual access attempt 6009
8 Invalid mobile number 6007
9 Unknown error 6006
Table 18
6.1.4 Operation Management Design:
Up on each instruction from mobile, the gateway transfers the SMS to the web-
server via the listening end point URL from the web server. On receiving the
SMS, system will parse the information and based on instruction and its sequence,
respective API functionality will be called based on a factory method. On
successful operation response will be sent to mobile. On failure, a code is sending
to mobile with friendly message.
6.1.5 Messaging Design
SMS is sending to the LMS specific number and system is responding to the
sender number via SMS API.
6.1.6 Simulator Design
Before testing with real time mobile, simulator based testing has been performed.
A custom simulator has been created with GUI. This web based simulator works
exactly as mobile phone.

45
CHAPTER 7
Construction & Unit Testing
7. Construction & Unit Testing
7.1 Coding Strategy
The below coding strategy was followed for coding,
7.1.1 Using Top-down approach
7.1.2 Readable code
7.1.3 Avoid declaring unused variables
7.1.4 Proper indentation
7.1.5 Incorporated comments wherever necessary
7.2 Best Practices
The concept of reusability and modularization is adapted in the project. Project is
strictly following Agile methodology for iterative development.
7.3 Coding Convention
The standard coding convention for CodeIgniter is followed as mentioned in the
below links
Reference section 1
7.4 Construction
Environment is based on eclipse IDE in local development machine. Code has
been developed in local machine and deployed to internet web server.

46
Production application is live in the following location.
http://lms.najeem.com
This application has no manual accessing via web browser but through the SMS
API only.
7.5 Code Review
Manual code review process is adopted.
7.6 Unit Testing
PHPUnit testing strategy is used for testing the various scenarios. Unit testing has
been performed for the following
o Test for functionality of mobile number validation
o Test for functionality of user authentication (username, password, mobile)
o Test for mobile success response
o Test for mobile failure response
o Test for command validation
o Test for command sequence validation
o Test for database update validation

47
CHAPTER 8
Quality Assurance (QA)
8. Quality Assurance (QA)
8.1 QA Strategy
For this project, I have devised a testing strategy to ensure the end to end quality
of the application and over all communication networks. Important strategies are:
o Perform Functional testing via mobile phone and simulator
o Validate commands and data input
o Validate command sequence and operational success.
8.2 QA Scope
Scope of the testing is limited to mobile devise which is the I/O devise.
8.3 Functional QA
o Test for functionality of mobile number validation
o Test for functionality of user authentication (username, password, mobile)
o Test for Apply/ Request Leave
o Test for View Absence Balance
o Test for LMS Leave History
o Test for Cancel Leave Request
o Test for Compensatory off request
o Test for Compensatory off status
o Test for View leave requests
o Test for Manager approve reject
o Test for Apply reports leave
o Test for Cancel reports leave
8.4 QA Assessment
o Ensure all commands are working
o Ensure command sequence is maintaining
o Ensure only authenticated user can access
o Verify basic mobile devises are supported

48
CHAPTER 9
A few application Screenshots
9. A few application Screenshots
9.1 Login
Figure 9

49
9.2 Validate instructions
Figure 10
9.3 Validate mobile
Figure 11

50
9.4 Command order
Figure 12

51
9.5 Response Factory method
Figure 13

52
9.6 After login construct initial options
Figure 14

54
9.7 Construct apply leave response
Figure 16

56
9.8 Apply Leave
Figure 18
Figure 19

57
9.9 View Absence Balance
Figure 20

59
9.10 Online simulator (developed for testing and debugging)
Figure 22

60
CHAPTER 10
Future Extensibility
10. Future Extensibility
10.1 Scope for Future Extension
As an enhancement this application can extent to other one Cognizant
applications such as cab booking, hospitality management, holiday tracking,
transport management, time sheets etc.
10.2 Guidelines
The following are tips and guidelines for application designers and developers
o Further reduce the number of interaction per operation.
o Keep the common authentication system for all new applications

61
CHAPTER 11
Advantages to Cognizant
11. Advantages to Cognizant
11.1 Internal Advantages
Various advantages internally to Cognizant are:
• Helping employees in accessing leave management system even
in remote locations, while traveling from place to place, no
internet access zones etc
• Future extendibility of this platform help employees to access
other applications and services such as
o conference booking
o cab booking
o hospitality management
o employee self management portal
o transport management
o Guest management
o Access management
and much more
11.2 Business Advantages
• Extending client applications and platforms with this additional
facility will invite more business.

62
Appendix A
Terminologies
LMS Leave management system
SMS Simple text messaging service
API Application programming interface
UML Unified modeling language
UI User interface
GUI Graphical user interface
Table 19

63
References
1. https://ellislab.com/codeigniter/user-guide/general/styleguide.html
2. https://ellislab.com/codeigniter/user-guide/index.html

SECTZG629T_FR_2012HZ78512

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (19)

Similar to SECTZG629T_FR_2012HZ78512

Similar to SECTZG629T_FR_2012HZ78512 (20)

SECTZG629T_FR_2012HZ78512