Back to the Basics – Post 1: Software Analysis
There is a saying that history repeats itself. Well, looking at this picture from 1973, it probably does:
Being in the profession and business of software development for more than 25 years, I can genuinely relate to this picture, having been part of projects where this happened, but also many where it did not.
I started working in 1995 as a Junior Developer Intern. In my very first project, I was part of a team with a project budget of +/- ZAR 1 000 000 (South African Rand) to be completed within 1 year.
The project ended up costing over ZAR 5 000 000 (South African Rand) and took over 5 years.
Impossible, you might think, but we hear about these kinds of projects over and over.
From a software perspective, the project ended in victory. Our customer was very satisfied at the end, and the system has run smoothly till this day without requiring vendor support or intervention. However, from a business point of view, it was a failure running at a loss and losing reputation due to the inability to execute within time and budget.
Over the years, I have been part of various project teams across many technologies, software processes and designs. Irrespective of the technology, software development lifecycle, or architecture and design, any software project’s success depends on the principles being adhered to and the ways of work of the team(s).
“Successful projects are achieved by a team of cohesive people that
operates with discipline and out of principle”
One of the top reasons software projects fail is due to weak software analysis.
I believe that statistics will back me up on this. In many ways, this is one of the reasons that led to the agile process revolution, allowing the outcome of the analysis – the software – to be quickly tested and adjusted.
As long as projects are small, analysis is simple and straightforward, and the agile process easily overcomes weak analysis. Enterprise software systems are, however, a different ball game, and proper business and system analysis are critical.
We live in a world with numerous tools, and analysis tools are not shying away from having a mountain of tools to use. Tools should be used, but they will not be of much help if you do not adhere to certain principles. It is therefore that I suggest that one must get back to basics before going advanced. Get the foundation of the house right before hanging up the mirrors.
This is the first blog post in the series: Back to the Basics on Software Analysis.
Follow Jalia on Linked In, or download the whitepaper from https://jalia.co.za/services/
Author: Henk Maritz (jalia.co.za)