PHD Computer Consultants Ltd ... Custom Software Development

Last modified: 10 February 1997.

Usually you first give us an outline of the project. Then we prepare our proposal which details the broad brush functionality as we understand it. It indicates roughly how we will develop the software, etc., and how long it will take. Once agreed, we can simply add on a price, and there's your quotation.

If you are well prepared, then you will have your own specification ready. Even in this case we usually like to take over or rewrite the specification. This confirms to you that we know what is going on, and later we can update the specification as it evolves.

At this stage, it is worth noting that for completely new projects, it is often best to do a quick prototype first just to try out the idea, or to see what functionality is required. Assuming that this is successful, either the original can be built upon, or - often recommended - a complete solid rewrite is undertaken.

Sometimes people come to us with software that does not work, or software that needs enhanced. Although this may sound unnecessary, a complete rewrite is often recommended. Mainly it avoids us having to get into the mind-set of the previous developer. It may also allow us to do the same job using more recent tools or techniques. The down side is that an alternative set of problems may be introduced.

Project Styles

So there's the whole hog, standard or a quickie.

For a quickie prototype project, you just give us sketchy details of what you want. You will trust us to come with something sensible. Changes can be made later. This type of project is often best as time and materials job, and can be a precursor to a "proper rewrite".

For a standard project we get together with you to write the functional specification. This is agreed before we commence the bulk of the work. We go off and do the work, usually with regular milestone reports. After in-house testing, you get the software and documentation for beta testing.

If going the whole hog then we additionally produce a Program or System Specification which details how the software has been put together, how it works and what the individual modules or objects do. We also put together a separate Test Specification, with your help; this forms the basis of acceptance testing.

In all cases, we still want the software signed off at the end. That means you giving the software a beating for a week, say, or running the acceptance tests.

Each project has one or more of the standard set of deliverables.

In all cases we make any code self-documenting by using suitable variable names and comments. Even where there is a Program Specification, the code is always the ultimate reference, showing how the program actually works.

For custom projects you will usually want to have all the source code, and have copyright to the lot. This is usually built into our pricing. If the project reuses some existing code, then we will make sure that you have the right licences from us or the suppliers.

In some cases, your custom software might be resellable to others. Talk to us about how to make this happen. Perhaps give us the software in return for a royalty.

Choice of Tools

There's usually more than one way to skin a cat (is shell a pea pod more friendly?) and we will usually go through the various possibilities that we can think up.

As well as the various project styles, nowadays a bit lateral thinking is required. Perhaps, rather than writing a standard Windows application, we could do it as an Internet application. Or perhaps the software is not needed at all!

Most developers have a set way of working, and will direct you toward those tools or that methodology. Assuming the methodology is appropriate, then this is a good thing as you will know that the developer is using a familiar technique.

At PHD, we almost have a problem in that we can think up too many ways to solve a problem. For example, most of the Windows development tools that we have are suitable for programming common-or-garden projects. Our experience will help us to recommend the best method.

Things we should not tell you

Small jobs take a lot less time than you would imagine. On the other hand, bigger jobs can overrun, but if they are fixed price then we will definitely complete them for you at no extra charge. On the whole these processes average out to keep us and you happy.

A lot of projects simply are never used. Usually you have found that you did not really need or want the software, or that users were not prepared to use it. We are especially proud of the projects that are in regular use; it makes us feel wanted (and you will inevitably want updates...)

Internet Applications

Let's think about using the Internet. This could mean several things.
A Web based project is a good way of displaying text and information. And you can now display data from databases, and get information back from the user.
Using standard Internet protocols many other custom Internet applications can be put together. For example, use Remote Procedure Calls to get load information onto a server. Use Networked File System calls to access the data directly.

There are some advantages to the Internet approach. First, your users can be running computers other than PC Windows. Second, the software can be run from anywhere in the world, or just on your network. Eventually cheap network computer terminals could be used instead of full blown PCs.
The main disadvantages are first that you have to be more careful with security, and second that the development uses very new technology, which may not be proven.

Deliverables

Then there may be an installation program. For a single system we can install on site for you.

You will almost certainly want support. This is either simply help on using the software or bug-fixing. For fixed price projects, you normally have three months free support. There may be extra charges if you want support in outlandish places.

For most working systems, you will want context-sensitive help. This could be standard Windows help. Or be avant-garde and have it as Web pages.

Documentation

First there is our tender proposal, a short outline of the functionality.

Usually there will be a full Functional Specification detailing precisely what functionality you want, with some detail about how it is implemented.

You will usually want Installation Instructions and a User Manual. There can come in skimpy or laboriously full versions.

Big projects will inevitably have a Program Specification or System Specification detailing how the program was put together, how it works and what the individual modules or objects do. We ensure that this follows the actual code.

Finally, you may want a Test Specification. Ideally written by someone not in the development team, this will describe the procedures to test the software. People with both software development experience and with experience of the application areas should be involved.

Release Tracking

We keep copies of the source and executables for all versions released.

We give you release notes, detailing the changes in each version, and the versions of each component module.

Other Points

We like to consider the Health and Safety of your program users.