Small businesses frequently need applications to be developed for internal use or even sale to external customers. This article helps understand and control the process.
Software Engineering as a discipline can be credited with many great paradigms for the creation of a complex software application development, and managing what can be a very complex process. However, for the smaller businesses, such attention to detail is often overkill, and there is the risk that the developer offers to take all this on themselves, and proceed to blind the customer with science.
Whilst this might not be intentional, it is obvious to anyone in business that it is impossible to control something that is not understood. This article will help those who:
- develop applications for internal use;
- have a great idea to turn into an app;
- want to outsource the development of their business systems.
It is aimed at aiding those in the above groups to understand how to define their requirements, interpret the design, and then test the finished product, as well as understanding some of the key issues they might encounter along the way.
The Software Development Life Cycle (Process)
What follows here is a much-reduced process model. In a typical process model for software development, there are many other sub-processes and steps in the processes that are designed to make sure that large applications, with complex interfaces, are well designed and developed. Developers will often use these internally to ensure correct delivery.
Whatever processes the developer uses internally, the aim here is to reduce the development process to a simple, yet complete and comprehensible, number of discrete steps:
- Functional Definition – what does the software do?
- Design – how does it do it?
- Testing – does it do it properly?
- Maintenance – is there anything we missed?
A contract from a third-party developer, or bid should allow for all of the above. The Functional Definition will be a joint document, primarily delivered by the client to the developer, who will then create the Design.
The client will then ascertain how Testing will take place, and what will be tested. Once the application has been accepted (after a Beta Testing period), it will enter into maintenance, where the developer undertakes to fix further defects, and possibly develop new features (this latter at a cost).
The biggest issue in the Definition, Design and Development will be a function (feature) creep. This happens when the client decides that they want ‘just another little feature’. It is to be avoided at all costs and is often the result of a poor initial design.
It is better to define and design a complete system, even if it does not cover all of the eventual functionality, and create a robust system that can be extended during maintenance, rather than pressurize the developer to add features that were not part of the original Definition, for the same price.
Definition & Design
It is the responsibility of the client to make sure that the Definition covers all the Use Cases. These are the things that users will want to do with the software. It is important to think about what the user needs to achieve, and how easily it should be achieved, for each of the functional areas of the product.
The Design should provide an implementation solution for each of the definitions, one by one, in a separate document, delivered by the third-party developer. This Design might include things not in the Definition, such as data storage, network communication, and GUI designs.
For visual applications, it is important to make the GUI design part of the bid package, and this should include mock-ups of any interface parts that need to be delivered.
Testing & Maintenance
Testing is often the hardest part of any project. The client needs to make sure that they validate all the Use Cases from the Requirements, in all combinations. This can be as simple as creating a series of steps that echo the Use Cases, in their various combinations.
It can be as complex as creating large data sets designed to validate the performance and scalability of the application. Often, the ideal set of test cases will be a balance between the two.
Since testing can never be 100% rigorous, it is usual to allow a period of Beta testing. This is where real users are allowed to take the application through its paces.
It is important to make sure that the programmer will cover defects found during that period. This is to be fair to both parties – the maintenance period should only start after the Beta Testing, but the Beta Testing should not extend into a long period.
Any functionality that is added as a result of Beta Testing should become part of work delivered under a Maintenance Agreement, which covers payable services that the developer undertakes to perform during the period of the agreement.
Following these simple guidelines should ensure that both parties start on the right path and that the deliverable is as close to the original intent as possible.
Those contracting out application development should not be afraid to extend the bid process to make sure that all questions are answered and that they get guarantees for fitness for use that are their right, as the customer, to demand.