Login
1. Planning
2. Requirements
3. Design
4. Development
5. Going live
6. Ongoing maintenance
In the initial stage of a new development, we look at the terms and practicalities. What is the scope of the project,
what problem does it solve, who does it reach, what kind of skills are required and what budget is available.
For the project to pass this stage, we need to be realistic. We need to talk to the people on the ground :
the end-users, the availability of skills and the people putting in the cash. Without the buy-in, its
going to be a hard sell to get this project up and running.
There is also the problem of "mission creep" to consider so the scope and boundraries have to be clearly noted.
Mission creep is very popular with stakeholders who try to push to project one direction or another after agreement
has been reached, which impacts all aspects of the original purpose and especially budget.
Typically, this is where we set out the tools and goals of the project in terms of skills, timeframe and budget, leading to the solution of an existing problem. This could be the cost of expert skills, leading to an e-commerce solution, or the purchase of a machine, leading to the production of a widget.
The design stage of software requires that we look in-depth at the way we put everything together, from user
interfaces, to security. Technically, this involves programming languages and frameworks, to purchasing SSL licenses.
Often, we build up a basic model or prototype of how it all hangs together as a "big picture". This is not exact
replica but more a "hands on" experience of what happens at each step, so that the stakeholders are able to judge
for themselves, if their expectations can be met.
This involves three unique steps : coding, testing and documentation. Coding and testing are actually inter-twined and best practices include using real data that is both correct and flawed. Traditionally, we specify that user-generated input is tested for accuracy and formatting prior to entering the system itself. This keeps the main body of code free of errors and allows us to make assumptions about the resultant input as it flows through the structures. The one exception to this, is where the data is correct but conflicting, eg the user says s/he is in London, but will pick up something in-store in New York.
Testing should include both invidual processes as well as the seamless integration of the entire product. Without
testing carefully and eliminating errors, the user experience would be downgraded. Even after a massive amount of
testing, there are always going to be errors creeping in, and usually these are in the form of user input which is
unique and causes a specific sequence of events to occur. More on this under maintenance.
Documentation is a written description of the software and is used to both help maintain and enhance the system at
later stages and as a guide for users. Depending on the application, it can be online FAQ's, a user manual, a video
explaining each step of a complex user-process, or the description of each field in the database, with expanations
of usage and correct formatting. The purpose of any documentation, is to allow a future developer or current user
to immediately understand what the purpose of a given task is, without having to spent vast amounts of time on it.
So for example, for a tricky bit of coding, the purpose of which is not apparent, the documentation would describe
why the problem exists, who solved it (in case further technical discussion is required) and what the work-around is.
For a user, it could be a series of FAQ's describing the required input for a specific function.
Going live has to be planned well in advance, since once its 'out there', the users will pick up any errors immediately.
Version control might mean overwriting some or all of the existing product, or keeping the old and new completely separated.
Best practice usually dictates that users are prevented from accessing the newer version until its been tested in a live
environment. The obvious 'dumb' errors that creep in at this stage, are typical developer activity that was forgotten about,
such as changing the name of a database from the test to live versions.
A massive system that interacts with other systems would probably require a system-wide lock-out of users with careful
planning of how to test the integration correctly.
The longest, hardest and least desirable section (except for documentation, which goes hand-in-hand with maintenance). Maintainence is a way to keep the process rolling forward. Fixing previously undiscovered bugs, making changes and dropping no-longer-needed features fall into this section and can last many years. This is where documentation becomes a vital cog: little quirks, short-cuts and developer-preferences are often revisited by new staff with no clear idea of the historic perspective.
There are instances of errors that manifest themselves only under specific conditions, which can not be picked up during the testing phase. Typically, these are hard-to-find and hard-to-replicate errors which only happen to users in some specific instance.
It goes without saying, that documentation should be kept up to date, with previous versions archived.
Version control is required for all medium to large systems and contain two vital features: (a) a short note explaining what the purpose of a coding revision is, who did it, why it was needed and what it impacts, and (b) the ability to backtrack and restore a previous version immediately, should something go wrong. Numeric versions are traditionally held, so to make reference to a specific feature or to backtrack to a version that works, i.e. current version of system v4.5 with test version v4.5.1 featuring enhanced functionality.
Copyright © 2026 E-Strategic. All rights reserved.