Splitting the big piece into small pieces

Whenever you get a project, don't be so excited and start writing codes. Below is some guidelines that helps you in managing the project development. Please take note that this article is not covering the entire SDLC (system development life cycle).

Development flow:

1. Ask for the sample reports and forms.
2. Designing the database - add the standard table structures such as security module, session table, etc. Then, follow by the new table structures.
3. Design the screen flow chart - you have to decide how many screens to the develop and the flow from one screen to another.
4. Identify the reusable class that can be shared with other project.
5. Identify the reusable custom control - most of the times, the screen (i.e., WinForm or WebForm can be splitted into multiple controls and then combine all the controls into one screen). This is very useful but requires thorough knowledge on the OOP (object oriented programming).
6. Design the screen layout.
7. Identify the shared functions - for example, the function to read the system settings out from the database or flat file.
8. Designing the report layout - the user might pass you the hard copy of reports. But, sometimes you might have to propose new format (in digital format) that includes the chart/graph to show the summarize data.
9. Start developing the system - now, you may start writing codes. I know you are waiting for this great moment.
10. Fine tuning the screen flow - some users might not understand why you have to design the screen in this or that way. So, you might have to fine tune the screen to reduce the support calls and training time. This is a very important step where most of the projects might failed here.
11. Fine tuning the field flow - this requires the feedback from the user where you might not have the full knowledge of the business.
12. Fine tuning the menu options - some of the menu option can be remove and replace by shortcut button or popup menu.
13. Add shortcuts or popup menu - I know this is not critical to any system but you should always do this. Most of the users will appreciate your effort in this area and this is the surprises when they found out there is an easier and convenient way to do their job. For example, the user may press the Delete key or right click and choose Delete in order to delete the selected files in Windows Explorer.
14. Fine tuning the query response time by add appropriate indexes or using multi-thread - this is especially loading lots of records from the database or generating reports. Do you know how frustrated is that for the user to see "not responding" word appear in the program/task manager?

Assumptions:

1. Always assume that you are not sure about the detail process - so ask for all the details and do not assume what you know is correct.
2. Always assume that the user still have something exceptional procedures to follow - well, you have to prepare yourself before interviewing the users.
3. Always assume that the user will request for changes in the database or system flow - this requires declaring constants or reading the settings from the database, writing modular program, passing the parameter with an object type instead of value type, etc.
4. Always assume that the data will grow faster than the user is expecting - when the system has rolled out, it will grow faster than you are expected. The proper way to handle this is to calculate the number of transactions per week/month that will be entered into the database. Then, estimated the number bytes per transactions. Base on the total bytes that requires, you will be able to come out with an appropriate server/workstation specification.

 Is that all? NO. You have to learn from experience or from other experts and then build your own checklist.