This page describes the development strategy that is part of the culture here at Abbydale Systems. Whilst
we do not say that this is the ultimate development strategy, it is one that we use. It can easily be adapted or modified to suit your own needs.
Despite the fact that this page is a serialized list of steps, the whole process is really cyclical. Communication between
the customer and developer should be regular and frequent so that all parties know the status and progress of the project.
- Obtain Customer Requirements This step may seem an obvious first step, but it is a critical step. Experience shows that a correctly specified project results in greater satisfaction and a faster development. Variance is a killer to a project both for the customer and for the supplier(developer). Never deliver a Rolls-Royce if the customer only wants (and will pay for) a VW Beetle. If a customer is tied into a written and agreed upon requirement specification then the developer has a clear understanding of what needs to be done. A successful project/program is usually the result of clear, well defined and adhered to specifications. Consideration for transaction volumes and response times will also play into the development process.
- Define the Scope Once you have agreed upon the requirements, the next step is to document the scope to include the sometimes forgotten aspects such as backup requirements, source code version vaulting, support requirements and market potential. By market potential we mean, can we, as developers, market the work to other companies? The output from this step will be a agreement on the deliverables. This step is usually going to form the basis of a legal contract. This contract should be drawn up by a qualified attorney for your own protection and that of your company.
- Document the Requirements The documents here are really the output from the previous step but it should include a list of the deliverables, cost, time frame etc. Basically it will form the contract for the work. It should be signed and agreed upon by both parties. Until this step is performed you really don't have any agreement and any work performed on coding before this contract is signed is a risky strategy, the customer may not agree on your understanding of the requirements/scope or even platform.
- Obtain Customer Buy In Once you have all the requirements defined and agreed upon it is vital to get the customer buy-in for the project. Admittedly if they have signed the contract then they are financially committed but that is not the same as getting them to 'buy-in'. By 'buy-in' we are talking about getting customer-end resources assigned to the project. Resources include any agreed upon prerequisite hardware and software, access to any required software and databases (or at least working samples of them). You should also have an assigned customer representative (a contact) and details of how to contact them.
- Design the Logic Flow of the Project/Program(s) Now the fun starts. Ideally you should draft an overall flow logic for the project/program(s). Determine if the project/program can be broken down into individual modules or if the scope is such that one module will be sufficient. Determine if there are any interface requirements and how best to integrate the program into existing systems.
- Develop the Program(s) (Top down) Time for the nitty-gritty.
- Test the Prototype Program(s) This may seem a very obvious step but it is an important step to ensure that what has been designed and coded actually does what the customer requires of it. They should be tested for both function and connectivity (if required). This testing doesn't need to be extensive (that comes later). It is more about ensuring that the program(s) work correctly with valid data. At this point we just need to test that the program functions. We actually use a lot of tracing in these prototype programs and we use only good data. Error checking code comes later after we are sure that the functionality is correct and that the data flows correctly.
- Compare Results Against the Requirements This step is a logical follow-on to the previous step. We need to ensure that what we are producing matches the clients expectations and that any calculations are producing the correct and expected results. We also ensure that any and all communication links are functioning as expected.
- Refine the Program(s) to the Requirements This is where we take the prototype program(s) and refine it. In our case we never change the working prototype. We copy the code and modify that. This gives us the capability of rolling back and starting again should things go horribly wrong. Usually the last thing we do is remove any tracing statements or code. We remove this code as this can have a detrimental effect on program performance. This step is where you should add error checking, recovery code and pretty up any output. This step is really where you add the 'bells and whistles' but remember that you really only need to concentrate on meeting the client requirements. Going above and beyond those requirements is potentially costly. Not only are you providing something that wasn't asked for but maybe there is a good reason why it wasn't asked for! If in doubt, check the requirements in the documentation.
- Test the Program(s) Results Against the Requirements Once you have amended the program(s) into the 'final' versions you should test them, not just with valid data, but with how it handles incorrect data. Files can be very easily corrupted by program(s) updating them with invalid data. You should also stress test the program(s). Basically this step is a QA (Quality Assurance) step. Test, test and retest. The results from these tests should feedback into the development steps to correct any errors (bug fix). The testing should produce consistent, accurate results. It is a good idea to include the client in checking the test result and getting their sign-off on the test results.
- Document the Program(s) Documentation! Most developers hate doing it, but it is vital. The documentation should include instructions on how to use the program, what the program does, messages that the program issues (if any). It is also essential to indicate the version of the program that the documents refers to. All of this may seem obvious but documentation is useful for both the client and the developer. The documentation should also include any copyright and trademark information.
As a reasonable rule for development there are three options, GOOD, CHEAP or FAST. Generally the customer can pick two.
Now here is the thing:
.png)
If it is CHEAP and FAST it won't be GOOD
If it is CHEAP and GOOD it won't be FAST
If it is FAST and GOOD it won't be CHEAP.
Remember : Never assume that something 'goes without saying', define it!
Generally speaking we tend to develop code that can be used in many other systems by making the code as flexible and stand-alone as possible. You should also consider the mapping the data flow as well as the program flow. Remember that data flow will also play into the logic flow as will the number of concurrent users, response time requirements and volume of data.
Developing the program(s) is now really just a matter of following the flowchart/diagrams that were drawn up in the previous step. Programming style is usually not a consideration. What is important is that the programs function as intended and especially as the customer wants; nothing more, nothing less. Giving the customer 'value added' is all well and good provided that you understand that you will carry the cost of this. The customer will usually only pay for what they asked for, at the price they agreed upon. We are not saying that quality doesn't matter, it does. What we are saying is if the client hasn't requested it, don't waste time developing it!
Using a structured programming approach will assist in speeding up the development cycle. A top-down approach is one that we find works best. Structure programs with subroutines that they can be reused within the program or, ideally, within or by other programs.
Standards! Have your own set of standards and adhere to them as much as possible. We understand that there are hundreds of standards out there but the only one you need worry about is your own! By following standards you eliminate as much confusion as possible. Standards should not be inflexible, if a standard doesn't apply, don't use it but in most cases the standard WILL apply if correctly defined and thought out.
Just as important as the standards is the broadcasting of them to the developers! Document and publish your standards to your staff!
Standards do not (or rather SHOULD not) need to be too rigorous that they stifle creativity.
This step shouldn't be the final program, more of a proof of concept/prototype program(s).
Make sure that the documentation references what the program ACTUALLY does, not what it is supposed to do! We usually include a list of any called or calling programs, prerequisite hardware and software and installation instructions. Don't forget the installation instructions!
Remember to include any support information, as well as any disclaimers that may apply. Ensure that the client expectations for support match what your understanding of their support requirements are.
That is it!
At this point you should have a well developed, well understood and well documented solution...and most importantly a happy client.
If you would like us to develop a quality solution for you please click here.
