Budget Planner
- Title of the project: Budget Planner
- Domain: Open Industry
- Sub Domain: Finance and Account Division
- Project Architecture: N-Tire Architecture
- SDLC methodologies: Waterfall model
- Abstract of the project:
This project is aimed at developing a system by which the employees in the organization submit the bills to their managers. The bills could of various types and also of various amounts. The employee after submitting the bill will automatically provide the manager’s name to which the bill will be submitted. The bill will pass through a workflow process and the owner of the bill can view the status of the bill at any time. An email will be sent to the concerned people to let them know about the status of the bill.
The software is fully integrated with CRM (Customer Relationship Management) as well as CMS (Content Management System) solution and developed in a manner that is easily manageable, time saving and relieving one from manual works.
Functional components of the project: Following is the list of functionalities which is expected to be provided by the system:
- User will log on to the application and the login will be based on the role of the user. The user will directly take into ‘My open requests’, where the user can view the details of the request and can also view the status at which the request is.
- The access to the system will be based on the roles. The roles will be based on the type of department the user belongs to.
Details are:
(1) Any user can create a request by login to the system, the parameters for creating the request will be
- Name of the user (should be defaulted from the login)
- Dept of the user (should be defaulted from the login)
- Type of the bill being submitted (e.g., telephone bill, electricity bill etc)
- Amount of the bill
- Date of expense incurred
- Whether the request is supported by the bills
- Whether the bill amount should be credited to the user account in the bank
- Bank name, address and account number
- Any other mode by which the user will want to get the payment
(2) The manager of the user should be able to view the details of the request but cannot modify the details entered; he can either approve the request or reject it. Every time he performs and operation the approver has to write the comments for the same.
(3) Finance Manager – there will be number of finance managers and each finance manager will be responsible for 1 or 2 departments. Users in this role can only close the application, they can only view the requests and after crediting the amount to the request creator the request will be closed by the finance manager
- The workflow process would be
- User creates the request
- Request is send to his manager, this should be done automatically. An email should be sent to the manager and also the request creator with the details of the request.
- Request creator should be able to recall the request from manager, if the request has not been acted on else it cannot
- User if not sent to requestor can cancel the request altogether as well
- User can save the request in draft mode without sending to the approver
- Manager of the concerned request creator can view the details of the request but cannot modify.
- Request once approved by the manager is sent to the concerned finance dept manager
- If rejected the request is sent back to the request creator.
- In all the above scenarios an email should be sent to the concerned parties for necessary action
- Finance manager after receiving the request has to credit the user account and has to send the request to the creator with proper comments as appropriate.
- Now the creator will close the request after the amount has been credited to the creator.
- After sending the email, the system will keep checking on the daily basis on the status of the request, if no actions is performed in 24 hrs a reminder email is generated which is sent to the user email address as stored in the database.
Screens should also be provided to the administrator of the system to create the employee as well as their manager.
- Keywords:
- Generic Technology Keywords: Databases, User Interface, Programming
- Specific Technology Keywords: ASP.Net, C#.Net, MS SQL Server
- Project Type Keywords: Analysis, Design, Implementation, Testing
- SDLC Keywords: Presentation, Business, Data Access Layers
- Environment:
- Servers:
- Operating System Server: - Microsoft Windows 2000 or Higher
- Data Base Server: Microsoft SQL Server 2000/2005
- Clients: Microsoft Internet Explorer,
- Tools: Microsoft Visual Studio .Net
- User Interface: ASP.NET with AJAX
- Code Behind: VC#.NET
- Requirements:
- Hardware requirements:
Number | Description |
1 | PC with 2 GB hard-disk |
- Software requirements:
Number | Description |
1 | Windows 2000/ XP/ or Higher with MS-office |
2. | MS-SQL server2000/2005 |
3. | Ms-Visual Studio .Net 2005 |
4. | Ms-Internet Explorer |
- Manpower requirements:
3 to 4 Developers can complete this in 3-4 months.
- Milestones:
No. | Milestone Name | Milestone Description
| Remarks
|
1 | Requirements Specification | Complete specification of the system including defining hierarchies constitutes this milestone. A document detailing the same should be written and a presentation on that be made. | Attempt should be made to add some more relevant functionality other than those that are listed in this document. |
2 | Technology familiarization | Understanding of the technology needed to implement the project. | 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 at least 10 entries of users with at least 1 should application admin. | 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 and then coming up with flow-charts or pseudo code to handle the scenario. | The scenarios should map to the requirement specification |
5 | Development of front end functionalities. | Implementation of the main screen giving the login, screen that follows the login giving various options, screens for each of the options | During this milestone period, it would be a good idea for 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 database. Other features should be functional at this stage. In short, the system should be ready for integration testing. |
|
7 | Integration Testing | The system should be thoroughly tested by running all the test cases written for the system (from milestone 5). | 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. | During the final review of the project, it should be checked that all the requirements specified during milestone number 1 are fulfilled |
- The following steps will be helpful to start off the project:
- Study and be comfortable with technologies such as: ASP.Net with C#, and SQL Server.
- Gather some knowledge of product hierarchies and maintenance before starting the design.
- Create a user database with different access levels.
- Start with creating the login screen.
- Create menus for navigation and group the functionalities as sub menus.
- Create the help-pages of the application in the form of FAQ. This will helps user.
Budget Planner - Screenshots by finalyearprojects
0 comments:
Post a Comment