“You don’t have to know what is in the code to write the test. The test is the collection of specifications” – Ken Bauer, 2019
Here’s my first post. It will be the start of the journey called Analysis and Modelling of Software Systems, hopefully enabling you and me to plan writing code in the end. Let’s begin.
The approach of planning a software system is vastly superior when embarking on a medium to large scale project. Superior to the approach of just typing away and hoping your mind works the same as a computer.
But how do you plan writing code? And what do you plan? You could just plan the life of the software, from start to the software being given to the end user. But no software is perfect at the first, second or third try. Let’s make the it a life cycle, so you can make changes based on the feedback given by the end users.
Software development life cycles (SDLC) exist in many different forms, but they generally have 6 or 7 steps, something like:
1: Requirement gathering and analysis
4: Implementation or coding
There’s more information on each step here
Now let’s look at different life cycles.
Agile Model: This method revolves around the goal of delivering software as quickly as possible and adapt to change. This is encouraged if the end users and project stakeholders should or want to provide much feedback and are willing to accept flexible software requirements.
Waterfall model: This is a popular method in which every step is finished before continuing to the next step. This is ideal for projects with fixed requirements and scarce resources. The downside is that steps don’t overlap, which possibly reduces efficiency.
Other models are the V-Shaped, Big Bang, Spiral and Iterative Model. Read more about them here https://www.roberthalf.com.au/blog/employers/6-basic-sdlc-methodologies-which-one-best
Personally, I do not think the extremes of waterfall or iterative model are the solution. In every project, you have to come back after a few tries and change the original design based on the input you got from trying the product out in the real world. No one can know beforehand how all the variables will behave and when dealing with end users, meaning humans, the chances are they change their mind after seeing the first product. ‘No actually, it was fine the way it was’, is an often heard expression.
On the other hand, the iterative model can ramp up the costs of a project by a mindless continuation of the cycles, without thinking ahead. Programmer time is expensive, as governments have experienced multiple times.
The solution in my eyes is thoroughly planning, while trying to execute the most feasible parts of the design on the way, thus providing feedback for further planning and improvement. So in short, the perfect solution is somewhere in the middle. It depends on the type of project where in the middle, though.