|Last modified: 10 February 1997.|
|Page Contents||On-site Links|
|How a project happens||Contracts, Money and all that|
|Project styles||Our resources|
|Choice of tools||Data Protection Act|
|Things we should not tell you||Health and Safety|
|Deliverables including documentation|
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.
You can choose what sort of development you want to take place.
The time left to your deadline and the amount of money available
usually determine which course to take.
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
Often you will have definite ideas about which tools we should use for the job.
It may be that you use these same tools in house,
or that you have a specific requirement, eg work with Foxpro dBase format files.
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
The computer industry changes so often that even we have difficulty keeping up.
We do spend a lot of non-chargeable time keeping abreast of developments,
eg trying out Internet tools, and the latest versions of operating systems.
Quarterly updates to development information and tools come all too often!
We like to appear to be at least one step ahead.
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...)
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.
First, there's the program with all its associated support files.
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.
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.
We make a point of keeping track of what we have released to you.
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.
We like to consider the Health and Safety of your program users.