Project Proposal

Module Code: PRJ4M1I

Student No.: 4244-9251

MODULE NAME: PROJECT IV IV:: PRACTICAL

Student Name: JA Chiosa

Project Proposal Project Name

:

Project Time-frame :

Software Tools for a Muslim Life May 10, 2012 to August 23, 2012

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. Africa. It is a supreme

religious body where Muslims look up to for daily advices, guidance and assistance. MUC’s undertakes its services ex gratis .

The work of the council is largely redundant with many queries it serves having been dealt with previously. previously. MUC is i s 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 MUC’s 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. 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; users; Page 1 of 4

Module Code: PRJ4M1I

Student No.: 4244-9251

MODULE NAME: PROJECT IV: PRACTICAL

Student Name: JA Chiosa

2. Certain functionality should be available for privileged users only; 3. Zakaat (purification) Calculator: a.  An automated tool for calculating client’s 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&A’s 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

Student No.: 4244-9251

MODULE NAME: PROJECT IV: PRACTICAL

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 provider’s 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

Student No.: 4244-9251

MODULE NAME: PROJECT IV: PRACTICAL

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. Client’s 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

Activity

Required

May 10,

Project Kickoff: management commitment

Developer, Client

2012

obtained, requirements communication methodology worked out

May 24,

Getting Requirements, Review of First Set

Client, Developer,

2012

of Analysis/Design Documents

Supervisor

May 31,

Analysis / Design Documents finalised.

Client, Developer,

2012

Requirements freeze.

Supervisor

June 8, 2012

Review of Web App Design – look and feel, Client (Optional), etc.

Developer, Supervisor

June 22,

Confirm Web App Design  – look and feel,

2012

etc.

July 6, 2012

Development Started.

Developer, Client

July 20,

Review of Mock development app

Client, Developer,

2012 August 2,

Supervisor Review of Application Developed.

2012 August 17,

Client, Supervisor

Developer, Supervisor

Project Finalisation

Client, Developer,

2012

Supervisor

Page 4 of 4