Description
The doc is to describe the functional and technical implementation details of the Fee management system being developed with reference of the statement of work.
Software Project Management
Fee Management
Introduction 1.1. Purpose
The objective of this document is to describe the functional and technical implementation details of the Fee management system being developed with reference of the statement of work. 1.2. Scope And Objective
The Objective of this application software is to manage the Fee payments and Fee dues of an Educational Institution so as to achieve a better and effective control of Fee payments and details. The Phase I: Implementation of the Fee Management System would address the following through the SRS document: ? Identification of various type of fee. ? Identification of student details. ? Administrative services. ? Fees, outstanding fees and various forms. ? Student information regarding the student ID and Fee out standing.
The Phase II: Implementation will have the following features as an add-on to the above mentioned functionalities ? Facilitation of various modes of payments. ? Feedback System
? Complaint re-addressable mechanism 1.3. Product Overview
The Application software, here, is intended to help the Fee department of the institute to manage the Fee system of the educational institute in such a way that results in efficiency and ease for both the student and the Fee Department. The software will address those students who have registered themselves with the Fee department to login and see the out standing fee and with the various type of out standing, give their feedback, and register complaints online. In addition it will also address to those who are newly getting admitted or registered in the institute. The software will help the Fee department people to effectively plan and manage the Fee payment services, and help the student and parents in their monthly, quarterly, half yearly and annual payment for the different type of fees.
2. General Description 2.1. Functions
The main function that this Fee management system has to perform is the management of the Fee system of the Educational Institution in way that reduces chaos, is effective, efficiently manages the available resources and is beneficial to the students/parents who use it.
This software also is supposed to help the Fee department plan and manage the services, keep a detailed record of its students plan and schedule the fee payments alerts and data up gradation. User Characteristics The system will be used by students or having proper authentication (user id and password). The first set of users would be the passengers who have registered themselves with the Fee department to use the Payment services and receipt generation. General Constraints The main constraints of this system is network resources (internet availability), proper functioning of the hardware and the server.
3. Specific Requirements 3.1. Functional requirements: The main functional requirements of this application software are: ? Information of the current students and the various classes they belong to. ? Details about number of students and their different student ID. ? Listing of students with their past payment records. ? Out standing late fee. ? A list of all past payment and with their respective dates and the type of fee paid.
? The record of vehicle maintenance incurred and the schedule of maintenance ? Details of the various payments options and the benefits the student and parents can avail. 3.2. Performance requirements
Many factors affect the performance of a software application, including available computing resources, network connectivity, and performance of integrated systems. The numbers of records processed per sec should be at least 100 no matter their complexity and the network response time on a 256Kbps line should not exceed 30ms.
3.3.
Non functional requirements Reusability
3.3.1.
The code should be so developed so that the phase 1 code can be used for further development of the system and new stand alone features could be integrated into the existing code. 3.3.2. Reliability
The code should be reliable as in the quality defects and the performance issues should never be major. The system should not breakdown under huge no. of uses at the same time and making the payment through various payment options available.
3.3.3.
Documentation
The system, its build, the requirements, the overall system architecture, database requirements, performance standards all should be well documented so as to aid in the future development and maintenance of the system. Use Case Diagram
System
CHECK ACCOUNTS
FEE OFFICER PAYMENTS MODES ______________ BY CASH THROUGH BANK
OUTSTANDING FEE _______________ CLASS-WISE OUTSTANDING STUDENT-WISE OUTSTANDING
LOGIN/ REGISTRATION
STUDENT/ PARENT/ NEW USER
RECEIPT GENERATION
DATABASE UPDATION
ADMINISTRATOR ALERT GENERATION
ACTOR: Fee Officer Use Cases: ? calculate outstanding ? Calculate fee ? Generate receipts ? Update fee details
Generate fee collection report Change/ manage own password
ACTOR: Administrator Use Cases: ? Edit fee set up ? Edit fee receipt ? Manage/change password ? Back up data ? Generate alerts ? Restore data
ACTOR: Students/Parents Use Cases: ? Check fee status ? Check fee alerts
? View voucher list ? Print receipt ? Change/manage password
Class Diagram
ADMINISTRATOR/ DATABASE FEE OFFICER -LOGIN ID #PASSWORD -EMAIL ADDRESS -PHONE NUMBER +ADD NEW ACCOUNT() -UPDATE EXISTING() -DELETE EXISTING() -UPDATE FEE() +ISSUE RECEIPTS() -UPDATE STATUS() +VIEW ALERTS() +VIEW PAYMENT HISTORY() * 1 1 1 +NAME +CLASS -TYPES OF FEE -TOTAL FEE PAID -OUTSTANDINGS -DIFFERENT TIME FRAMES -ADD FEE PAID() -REMOVE PENDING FEE() -SHOW ALL FEE DETAILS() +PAYMENT HISTORY()
*
* 1
* * 1
* * N
STUDENT -LOGIN ID -NAME -DATE OF BIRTH -ADMISSION DETAILS -FEE DETAILS -CONTACT INFO -ADDRESS +FEE DUES() +FEE PAID() +RECEIPT ISSUED() +RECEIPT PRINTED() +()
1
*
*
N
*
1
*
N
ALERTS +FEE DUE +TYPE OF FEE DUE +DUE DATE +LATE FEE +SEND TO ADMIN() +SEND TO FEE OFFICER() +SEND TO USER()
PAYMENT -NAME -CLASS -ID No. -PAYMENT DETAILS -OUTSTANDING -PAYMENT UPDATE() -REMOVE FEE FROM DATABASE() +UPDATE DATABASE()
*
*
N
1
*
Deployment Diagram
SERVER
-*
DATABASE SERVER
*
DATABSE
WEB SERVER * -* -1 -1 * * SERVER TX
* LOG
-1
ADMINISTRATION * -*
PC PILOT EX
*
-1 * -1..10
PC PILOT -*
PRINTER ASSEMBLY
*
The diagram describes the nature of the communication links between the various nodes. The server and the PCs are connected via an IPX link; the X-terminals and the server communicate via TCP/IP. The nature of the connections between other nodes is not specified. In this deployment diagram server and PCs, pilot, are connected via IPX link. Server TX is web server. Data base web server, log, administrator are the components of server.
WORK BREAKDOWN STRUCTURE (WBS)
FEE MANAGEMENT SYSTEM
Analysis
•Scope Statement •SRS
Plan
•Scheduling •Resource allocation •Manpower Resourcing •Budgeting
Design
•UML modeling •Algorithm Design •Interface Design •Database Design
Code
•Database Development •Back-end Application Development •User Interface Development
Test
•Unit testing •Acceptance Testing •Integration Testing •System Testing
Deploy
•Trainining of Users •Beta Testing •Delivery
Activity Diagram
STUDENT
FEE OFFICER
ADMINISTRATOR
FILL REGISTRATION FORM
VERIFY SUBMIT
OUTSTANDING DUES LOG IN
SELECT PAYMENT MODE
PAYS FEES
SUBMIT
UPDATE DATABASE
GENERATE RECEIPTS
States of objects are represented as rectangles with rounded corners. The transition between difference states is represented as an arrow between states, and a condition of that transition
occurring may be added between square braced. Activity diagram with providing information about the student’s registration carrying out by administrator, than submission of fee is done by fee officer.
GANTT CHART
CPM/PERTAnalysis
Function Point Analysis
Particulars
Values (V)
Number of User inputs 3 12 Number of User output 2 10 Number of Enquiries 3 12 Number of files 2 20 Number of External Interface 3 21 Total 75 * Since our project is of average difficulty so we have used the average weights to calculate the Function points. ? Number of files are 2, viz, fee structure and student database. ? Number of enquiries are 3, viz., Data verification by administrator, modification in fee status, selection of fee structure by students. ? User inputs are three student, fee-officer and administrator. ? Number of external interface is 3, viz, student, feeofficer/institute administration, system administrator. Total unadjusted functional points, UFP = 75 For Complexity multiplier: We have 12 points of average complexity1) Data communication 2) Distributed data processing 3) Performance criteria 4) End-user efficiency 5) Online data entry 6) Online data modification 7) Online efficiency 8) Reusability 9) Ease of installation 10) Ease of operation
Weightages (W)* 4 5 4 10 7
VxW
11) Portability 12) Maintainability So, Complexity Factor = 0.65 + 0.01 x 12 = 0.77 Hence, No. Of function points = 75 x .77 = 57.75 The project is implemented in JAVA language and technologies, and hence we assume 1 Function Point = 500 lines of code, So, Total No. of Lines of Code = 57.75 x 500 = 28875. Assuming 75 lines of code is coded daily, Then, No. of days = 28875 / 75 = 385. Assuming an additional of 15 days taken, Hence total days to complete project = 400.
Cost Estimation Assuming average daily cost of Rs. 5000 So, Total cost of the project = 5000 x 400 = 20,00,000 PROJECT COSTS Rs. 20,00,000.
References and Bibliography 1. Joseph Phillips, “IT Project Management”, Tata McGraw Hill. 2. Pankaj Jalote, “Software Project Management in Practice “,Addison Wesley, 2002.
doc_163207075.docx
The doc is to describe the functional and technical implementation details of the Fee management system being developed with reference of the statement of work.
Software Project Management
Fee Management
Introduction 1.1. Purpose
The objective of this document is to describe the functional and technical implementation details of the Fee management system being developed with reference of the statement of work. 1.2. Scope And Objective
The Objective of this application software is to manage the Fee payments and Fee dues of an Educational Institution so as to achieve a better and effective control of Fee payments and details. The Phase I: Implementation of the Fee Management System would address the following through the SRS document: ? Identification of various type of fee. ? Identification of student details. ? Administrative services. ? Fees, outstanding fees and various forms. ? Student information regarding the student ID and Fee out standing.
The Phase II: Implementation will have the following features as an add-on to the above mentioned functionalities ? Facilitation of various modes of payments. ? Feedback System
? Complaint re-addressable mechanism 1.3. Product Overview
The Application software, here, is intended to help the Fee department of the institute to manage the Fee system of the educational institute in such a way that results in efficiency and ease for both the student and the Fee Department. The software will address those students who have registered themselves with the Fee department to login and see the out standing fee and with the various type of out standing, give their feedback, and register complaints online. In addition it will also address to those who are newly getting admitted or registered in the institute. The software will help the Fee department people to effectively plan and manage the Fee payment services, and help the student and parents in their monthly, quarterly, half yearly and annual payment for the different type of fees.
2. General Description 2.1. Functions
The main function that this Fee management system has to perform is the management of the Fee system of the Educational Institution in way that reduces chaos, is effective, efficiently manages the available resources and is beneficial to the students/parents who use it.
This software also is supposed to help the Fee department plan and manage the services, keep a detailed record of its students plan and schedule the fee payments alerts and data up gradation. User Characteristics The system will be used by students or having proper authentication (user id and password). The first set of users would be the passengers who have registered themselves with the Fee department to use the Payment services and receipt generation. General Constraints The main constraints of this system is network resources (internet availability), proper functioning of the hardware and the server.
3. Specific Requirements 3.1. Functional requirements: The main functional requirements of this application software are: ? Information of the current students and the various classes they belong to. ? Details about number of students and their different student ID. ? Listing of students with their past payment records. ? Out standing late fee. ? A list of all past payment and with their respective dates and the type of fee paid.
? The record of vehicle maintenance incurred and the schedule of maintenance ? Details of the various payments options and the benefits the student and parents can avail. 3.2. Performance requirements
Many factors affect the performance of a software application, including available computing resources, network connectivity, and performance of integrated systems. The numbers of records processed per sec should be at least 100 no matter their complexity and the network response time on a 256Kbps line should not exceed 30ms.
3.3.
Non functional requirements Reusability
3.3.1.
The code should be so developed so that the phase 1 code can be used for further development of the system and new stand alone features could be integrated into the existing code. 3.3.2. Reliability
The code should be reliable as in the quality defects and the performance issues should never be major. The system should not breakdown under huge no. of uses at the same time and making the payment through various payment options available.
3.3.3.
Documentation
The system, its build, the requirements, the overall system architecture, database requirements, performance standards all should be well documented so as to aid in the future development and maintenance of the system. Use Case Diagram
System
CHECK ACCOUNTS
FEE OFFICER PAYMENTS MODES ______________ BY CASH THROUGH BANK
OUTSTANDING FEE _______________ CLASS-WISE OUTSTANDING STUDENT-WISE OUTSTANDING
LOGIN/ REGISTRATION
STUDENT/ PARENT/ NEW USER
RECEIPT GENERATION
DATABASE UPDATION
ADMINISTRATOR ALERT GENERATION
ACTOR: Fee Officer Use Cases: ? calculate outstanding ? Calculate fee ? Generate receipts ? Update fee details
Generate fee collection report Change/ manage own password
ACTOR: Administrator Use Cases: ? Edit fee set up ? Edit fee receipt ? Manage/change password ? Back up data ? Generate alerts ? Restore data
ACTOR: Students/Parents Use Cases: ? Check fee status ? Check fee alerts
? View voucher list ? Print receipt ? Change/manage password
Class Diagram
ADMINISTRATOR/ DATABASE FEE OFFICER -LOGIN ID #PASSWORD -EMAIL ADDRESS -PHONE NUMBER +ADD NEW ACCOUNT() -UPDATE EXISTING() -DELETE EXISTING() -UPDATE FEE() +ISSUE RECEIPTS() -UPDATE STATUS() +VIEW ALERTS() +VIEW PAYMENT HISTORY() * 1 1 1 +NAME +CLASS -TYPES OF FEE -TOTAL FEE PAID -OUTSTANDINGS -DIFFERENT TIME FRAMES -ADD FEE PAID() -REMOVE PENDING FEE() -SHOW ALL FEE DETAILS() +PAYMENT HISTORY()
*
* 1
* * 1
* * N
STUDENT -LOGIN ID -NAME -DATE OF BIRTH -ADMISSION DETAILS -FEE DETAILS -CONTACT INFO -ADDRESS +FEE DUES() +FEE PAID() +RECEIPT ISSUED() +RECEIPT PRINTED() +()
1
*
*
N
*
1
*
N
ALERTS +FEE DUE +TYPE OF FEE DUE +DUE DATE +LATE FEE +SEND TO ADMIN() +SEND TO FEE OFFICER() +SEND TO USER()
PAYMENT -NAME -CLASS -ID No. -PAYMENT DETAILS -OUTSTANDING -PAYMENT UPDATE() -REMOVE FEE FROM DATABASE() +UPDATE DATABASE()
*
*
N
1
*
Deployment Diagram
SERVER
-*
DATABASE SERVER
*
DATABSE
WEB SERVER * -* -1 -1 * * SERVER TX
* LOG
-1
ADMINISTRATION * -*
PC PILOT EX
*
-1 * -1..10
PC PILOT -*
PRINTER ASSEMBLY
*
The diagram describes the nature of the communication links between the various nodes. The server and the PCs are connected via an IPX link; the X-terminals and the server communicate via TCP/IP. The nature of the connections between other nodes is not specified. In this deployment diagram server and PCs, pilot, are connected via IPX link. Server TX is web server. Data base web server, log, administrator are the components of server.
WORK BREAKDOWN STRUCTURE (WBS)
FEE MANAGEMENT SYSTEM
Analysis
•Scope Statement •SRS
Plan
•Scheduling •Resource allocation •Manpower Resourcing •Budgeting
Design
•UML modeling •Algorithm Design •Interface Design •Database Design
Code
•Database Development •Back-end Application Development •User Interface Development
Test
•Unit testing •Acceptance Testing •Integration Testing •System Testing
Deploy
•Trainining of Users •Beta Testing •Delivery
Activity Diagram
STUDENT
FEE OFFICER
ADMINISTRATOR
FILL REGISTRATION FORM
VERIFY SUBMIT
OUTSTANDING DUES LOG IN
SELECT PAYMENT MODE
PAYS FEES
SUBMIT
UPDATE DATABASE
GENERATE RECEIPTS
States of objects are represented as rectangles with rounded corners. The transition between difference states is represented as an arrow between states, and a condition of that transition
occurring may be added between square braced. Activity diagram with providing information about the student’s registration carrying out by administrator, than submission of fee is done by fee officer.
GANTT CHART
CPM/PERTAnalysis
Function Point Analysis
Particulars
Values (V)
Number of User inputs 3 12 Number of User output 2 10 Number of Enquiries 3 12 Number of files 2 20 Number of External Interface 3 21 Total 75 * Since our project is of average difficulty so we have used the average weights to calculate the Function points. ? Number of files are 2, viz, fee structure and student database. ? Number of enquiries are 3, viz., Data verification by administrator, modification in fee status, selection of fee structure by students. ? User inputs are three student, fee-officer and administrator. ? Number of external interface is 3, viz, student, feeofficer/institute administration, system administrator. Total unadjusted functional points, UFP = 75 For Complexity multiplier: We have 12 points of average complexity1) Data communication 2) Distributed data processing 3) Performance criteria 4) End-user efficiency 5) Online data entry 6) Online data modification 7) Online efficiency 8) Reusability 9) Ease of installation 10) Ease of operation
Weightages (W)* 4 5 4 10 7
VxW
11) Portability 12) Maintainability So, Complexity Factor = 0.65 + 0.01 x 12 = 0.77 Hence, No. Of function points = 75 x .77 = 57.75 The project is implemented in JAVA language and technologies, and hence we assume 1 Function Point = 500 lines of code, So, Total No. of Lines of Code = 57.75 x 500 = 28875. Assuming 75 lines of code is coded daily, Then, No. of days = 28875 / 75 = 385. Assuming an additional of 15 days taken, Hence total days to complete project = 400.
Cost Estimation Assuming average daily cost of Rs. 5000 So, Total cost of the project = 5000 x 400 = 20,00,000 PROJECT COSTS Rs. 20,00,000.
References and Bibliography 1. Joseph Phillips, “IT Project Management”, Tata McGraw Hill. 2. Pankaj Jalote, “Software Project Management in Practice “,Addison Wesley, 2002.
doc_163207075.docx