Planning the Design
Design is one of the most important parts of developing software and one which is too often overlooked. There is a saying that every day skimped on design costs a week in programming. Poorly designed software costs much more to produce, debug and maintain. It is much more prone to bugs.
There is a huge temptation to just start writing a program. This is a serious mistake. You would not undertake building or engineering work without first designing and planning the work. Software should be the same. There will be times when you need to produce something just to see how it will work or what it will look like. This is fine. Treat that like an architect’s sketch pad, or as a prototype. But don’t expect to it this as part of the finished product. Sketch out parts of the program, then continue the design process.
Also, it is much harder to change a finished program than to modify a design document. Late changes consume a lot of time in repeating tests that have already been done. Late features tend to fit badly into the overall structure of the app. The more late features that are introduced, the more the structure is degraded.
List the User Requirements
The first step is to define the broad outline of the app and its major functions. Try to avoid descending into detail at the start – most people do this. It wastes time and, worse, increases the chance of missing important features. It may help to think of the analogy of designing a house. You would start by specifying the number and sizes of rooms and storeys and whether a garage was needed. Only then you would move on to the more detailed design.
Start by building a list of features that are needed. This list should be a core document for the entire project. To begin with, a list is all that is needed. You will no doubt have ideas on the way some of the features will work. If so, record these ideas but do not lose sight of the fact that you need to build a list.
When you have built the list, separate the items into mandatory ones (must have) and desirables. When you come to build the program, make sure the devlopers provide the mandatory features first. If you start to run out of budget (and you will), you can shelve some of the desirability.
You must then design shedules of requirements and functions, objects and data.
Requirements: Sort into Categories
You will now have a list of requirements. From the software viewpoint, it will not be in any sensible order or have any structure. You now must organise the list into a schedule. This is harder than it sounds.
Start by looking for categories. These would cover broad functions and concepts. Example could be messaging, news, people, advertisements or events. In a payroll system, it could be staffing, gross pay, tax, other stoppages and payslip printing. You may find it easier to draw charts and diagrams.
Be prepared to make several attempts at this,. You are unlikely to get it right first time. It is more important to get the design right than finish it quickly, remember that a day saved on design takes a week in programming.
List the operations that need to be carried out within each category. The sort of actions could include:
Define the objects that are needed in the app. Object is just another word for thing. Anything that is described by a noun could be an object. Examples could be person, employee, order, account, stock part, document, picture, appointment or widget. Objects are organised in classes.
One way to identify objects is to look at all the nouns in the list of requirements. From this, you can make a list of candidate classes. Review this and decide what classes to use in the app. Then, for each class, list what processes – methods– are needed. Aim to map all the user requirements to classes.
Make a list of the data needed by each object. Also, for each user operation, record what data is needed. What will the user want to see? In a list of contacts, he may want to see a set of thumbnail pictures., or he may just want to list the contacts. Will the contact’s name be enough in a list? Or will he also need to see the contact’s company?
Check for data the app will need itself, such as logon code, password and email address. You may want to collect statistics, to record how often a user logs on, to record what he views. If this is so, consider what data you will need to collect and record. You may find you need a class for the app itself.
Then design the database tables. Often you will need a table for each class. Look into the relations between the data fields in the various tables. Record which classes need to access data from other tables,. From this, design the key fields for the tables.
Once you have carried out all these steps, you will have a usable design for the project. The overall cost will be much less, delivery will be sooner and the project will run more smoothly.
This is only a brief summary. There are more details in my Kindle book: “How to Write Software for Sale”, available in Kindle format from Amazon for 99p (UK) or $1.43 (rest of the world). See details; Buy: Amazon UK or Amazon.com
Was this helpful? Please like and share the page, or leave a comment.
Have you an idea for an app? See how I could help you.
Do you have any questions? Contact me.