You are on page 1of 4

Module Code: PRJ4M1I MODULE NAME: PROJECT IV: PRACTICAL

Student No.: 4244-9251 Student Name: JA Chiosa

Project Proposal Project Name : Software Tools for a Muslim Life May 10, 2012 to August 23, 2012

Project Time-frame :

Background and Motivation

Background The project is set to assist the Muslim Ulama Committee (hereinafter referred to as MUC) in its work assisting and advising the Muslim community (hereinafter referred to as Clients). MUC is a Muslim council based in Johannesburg, South Africa. It is a supreme religious body where Muslims look up to for daily advices, guidance and assistance. MUCs undertakes its services ex gratis.

The work of the council is largely redundant with many queries it serves having been dealt with previously. MUC is looking for an IT solution that would help automate much of its work.

Current Situation An example of the current situation at MUC is given as follows: MUC receives requests for guidance and assistance from the clients via various sources (email, fax, personal, telephonic, etc.). The MUC advises the client based on the situation given.

The System It has been found that most of the work undertaken by the MUC can be automated. Over 40% of MUCs cases are repetitive. If these cases can be put into a central repository accessible for clients, it is suggested the load on MUC will decrease dramatically.

The system to be developed is a web application (accessible via web browser). It will serve as a self-service automation tool for the clients. The system should provide for a way to submit the case for further advice at the MUC.

The following is a list of major functionality to be covered by the System: 1. Allow for registration and log-in of users; Page 1 of 4

Module Code: PRJ4M1I MODULE NAME: PROJECT IV: PRACTICAL

Student No.: 4244-9251 Student Name: JA Chiosa

2. Certain functionality should be available for privileged users only; 3. Zakaat (purification) Calculator: a. An automated tool for calculating clients Zakaat amount. Zakat is payable annually for any Muslim with amount of wealth exceeding certain threshold; b. Among the functions this tool should provide: i. Calculate minimum amount of wealth (Nisaab) required for one to pay the Zakaat. The calculation is derived from, among other factors, current amount of gold/silver; ii. Accept entries from clients for the different categories of wealth; iii. To save the calculated amount for future use by the client. The client should be notified of next Zakaat date; 4. Fatwa (general queries) affecting Muslim daily life: a. Q&As dealt by the MUC listed in a searchable index; b. Clients can submit queries via the system; c. Admins can reply to queries via the system they can mark the Q/A as suitable for public view or private only viewable to the sender; d. Should be categorised; e. Should provide for privacy admin can toggle the question not viewable by the public; 5. Halaal product status query: a. Clients should be able to search the app for status of a particular product (whether it is OK to be consumed as per Muslim law); b. Privileged users should be able to enter and modify status of any product; 6. Hijri Date Converter: a. Functionality to convert English dates to Islamic date. This 7. Any other functionality to be provided by the MUC;

Goal

Features and Benefits 1. Less load on MUC due to elimination of redundant work will mean MUC can now provide much better quality service; 2. Less time for clients getting advice from the MUC; 3. Cost savings due to decrease in redundant work load; Page 2 of 4

Module Code: PRJ4M1I MODULE NAME: PROJECT IV: PRACTICAL

Student No.: 4244-9251 Student Name: JA Chiosa

Scope

In Scope 1. A Web Application accessible via major browsers; 2. Maintain confidentiality and privacy of the clients and their cases;

Out of Scope 1. Desktop application to be installed on client computers; 2. Native Mobile app however, design of the app should consider this possibility for future. Mobile apps can access the app via the browser;

Deliverables The Web App will have to be hosted by an ISP chosen by the MUC. The hosting providers requirements (server software, db system, etc.) will be dealt with at design level. These will be given to the MUC to look for a hosting service provider meeting those requirements.

At system completion, the system will be handed over to the MUC for onward transfer to the ISP.

Risks and Rewards Risks 1. The schedule of the project and its timelines are unmovable. The project will have to be ready for demonstration at UNISA by mid-August 2012. 2. Requirements definition: the client could not provide requirements for the app in detail. So, requirements elicitation will be tricky. The system will have to make use of an agile approach to develop the system to cater for this; 3. Client is used to manual way of doing things, hence, change management will have to be considered in all discussions to avoid arousing false expectations;

Project Plan / Major Milestones The project will adopt the modified (customised) XP / Scrum methodology for its development. There will be tight interaction between the development, client and supervisor. Page 3 of 4

Module Code: PRJ4M1I MODULE NAME: PROJECT IV: PRACTICAL

Student No.: 4244-9251 Student Name: JA Chiosa

The following is the modified (customised) methodology: 1. A requirement will constitute a functionality. Before each requirement is tackled, the team will agree on what constitutes full functionality. 2. A central repository (online editable excel document or googledocs) will replaces the CRC cards. Clients need will be recorded and commented on the repository. 3. Based on consensus, the team decides on what requirement to be tackled within a time period of maximum 10 days. If the task is big, the requirement is reduced. Development will have to be done within 7 days, 2 days for comments and a day for further development from the comments. 4. Once finalised, a comment is posted on the repository. The functionality can be tested. 5. Moves to 1 above; End Date May 10, 2012 Activity Project Kickoff: management commitment obtained, requirements communication methodology worked out May 24, 2012 May 31, 2012 June 8, 2012 Getting Requirements, Review of First Set of Analysis/Design Documents Analysis / Design Documents finalised. Requirements freeze. Client, Developer, Supervisor Client, Developer, Supervisor Required Developer, Client

Review of Web App Design look and feel, Client (Optional), etc. Confirm Web App Design look and feel, etc. Development Started. Review of Mock development app Developer, Client Client, Developer, Supervisor Review of Application Developed. Developer, Supervisor Project Finalisation Client, Developer, Supervisor Developer, Supervisor

June 22, 2012 July 6, 2012 July 20, 2012 August 2, 2012 August 17, 2012

Client, Supervisor

Page 4 of 4

You might also like