php loan application design help needed

Question

I find one of my weaknesses to be applying the theory I know in actual projects. One such theory is application design. I have never formally designed an application before beggining to code. I am developing a simple microfinance loan application for a client and I for once want to do things properly. Hence I am trying to design the system before coding. One of the many sites I am learing from suggest that one askes the following 3 questions and work from there;

1. What are the Input(s) of the system?
2. What are the Processes of the system?
3. What are the Output(s) of the system?

The 1st and 3rd questions are fairly easy to answer for me. The issue is the 2nd question. Not that I don't know what the system is to do but I think I am not stating them well enough as it should be. The following are my processes as I stated them, have a look if its okay,.

1. Register Groups and Individuals
2. Allocate loans to Groups with individuals or Individuals Only
3. Create loan repayment schedule
4. Calculate daily repayment at the point of loan allocation
5. keep track of daily collections by loan officers
6. provide loan disbursement projection on a weekly basis based on groups who have completed payments and new groups

Will you use wording like that when stating the high level processes for a system? I know I will have to make several passes to break the individual process down.

Answer 1

Looks like you are off to a good start. You want to make a list of everything that your app needs to do. Then you may want to rank those from must-haves to nice-to-have, that way as the deadline comes closer you can drop features that aren't worth doing.

Answer 2

Be very wary of doing something just because it's "good practice" if you don't know why (and personally I often need to "do" something (and fail) before I really grok something).

What are the Processes of the system?

Why should we ask this? What this is trying to do is to start to identify roles and responsibilities in your system - this is the first high-level pass in beginning an Object Orientated Design.

What you're doing is looking for: - Possible (high-level) packages - Possible classes within those packages

Try mapping it out using pseudo code on a white-board. For example - registering users is clearly going to be in a separate package from projecting loan dispersements.

The idea is that when a new requirement comes along (say the business need to add a new set of rules somewhere) it should be fairly clear where this responsibility lies and therefore where to put it, hat impact it'll have on your system, etc.

The other part to this, which goes hand-in-hand with processes is data and structure. Map out a Domain Model of the business domain - this is basically what you'll be implementing in you Business Logic.

Domain Modeling:

• http://en.wikipedia.org/wiki/Domain_model
• http://www.c2.com/cgi/wiki?DomainModel

Answer 3

If you are not particularly restricted to an Object Oriented design approach, then I suggest you look into Data Flow Diagrams.

Firstly, you could replace heavy wording by verbose diagrammatic representation. Secondly, there are just a few symbols to learn. Thirdly, the scheme allows you to "zone into" the details to provide detailed design of that process. Fourthly, the diagrams were designed so that (almost) anyone on the origination can understand their representation (up to level 2 at least).

Here are some starting points for you.

http://en.wikipedia.org/wiki/Data_flow_diagram

http://www.smartdraw.com/resources/tutorials/data-flow-diagrams/

http://www.getahead-direct.com/gwbadfd.htm