Changing project requirements is a key software development issue
Steps to develop a large computer program for delivery to the customer
Illustration above – from an article by Dr. Winston Royce “Management of the development of large software systems” 1970 year. It is believed that this is the first description of a waterfall model in software engineering. Dr. Royce’s diagrams have spread across hundreds of textbooks and articles. But they often forget the fact that the inventor of the waterfall immediately wrote: “This particular implementation is risky and entails failure.”
We develop software to meet the needs of any client, user or market. The task of software engineering as a field of computer science is to make this development predictable and cost-effective.
More than 50 years have passed since the first IFIP Software Engineering Conference, and during this time many different methods, processes and models have been proposed to help developers achieve this predictable and cost-effective process. But even after half a century, we have the same problems as always: lateness, unsatisfactory results and complete failure of projects.
Take the government contract that I worked on many years ago. This is undoubtedly the most successful project that I have ever worked on, at least from the point of view of usual project management indicators: it was completed ahead of schedule, on budget, and passed the monthly acceptance test in just three days.
There were some unusual restrictions for this project. The contract was nominated and paid in foreign currency with an absolutely fixed fixed price. The contract did not provide for any change management process at all. The acceptance test was actually laid out as part of the contract in the form of a series of observable tests “do this and that” – passing tests (yes / no) was checked with very little space for disputes. Due to the terms of the contract, the entire risk of any changes in requirements or exchange rates lay with my company.
The process was absolutely solid classic waterfall, and we confidently moved through the stages until the final system was completed, installed, and the acceptance test was passed and accepted.
After which I worked with the system for another 18 months, modifying it until it really satisfies the needs of customers. The fact is that during the year between the signing of the contract and the delivery of software the reporting forms changed, some components of the hardware platform were replaced with new and more advanced products, and amendments were made to the regulations to which the system should respond.
Requirements are changing. Every software development project will at some point encounter this difficult problem.
Therefore, all software development processes can be considered as various solutions to this fundamental problem. The initial (and naive) process of the waterfall simply assumed that you could start by firmly approving the requirements that must be met.
It is believed that the first description of the waterfall was given by Dr. Winston Royce in his work “Management of the development of large software systems”. The illustrations in hundreds of software engineering jobs, textbooks, and articles are recognizable diagrams he created. But it is often forgotten that in the original article, Royce also says: “[Такая] implementation [на диаграмме] risky and entails failure. ”
Process alignment with the environment
Royce’s observation — that each development goes through certain stages, from defining requirements and the proposed solution, to creating software and then testing it for compliance with these requirements — was good. In fact, every programmer is familiar with this, even from the first school assignments in computer science. But if your requirements change throughout the project, then you are guaranteed to not be able to satisfy the client, even if you fully satisfy the initial requirements.
In fact, there is only one answer: you need to find a way to ensure that the requirements-development-delivery cycle matches the speed at which requirements change. In the case of my government project, we did it artificially: in the absence of significant changes, it was easy to build a product according to the specification and pass acceptance tests.
Royce’s original article actually recognized the problem of changes in the development process. His article describes an iterative model in which unexpected changes and inoperative design decisions return the process to the development stage.
This process is not limited to successive steps. Illustration of articles Winston royce
Realism in software development
Once we accept that software development is always inherent in the uncertainty that requirements never remain unchanged for a long time, we can begin to develop ways to cope with the inevitable changes.
Start by accepting what change is inevitable.
Any project, no matter how well planned, will ultimately be at least slightly different from what was originally envisaged. The development process must accept this and be ready for action.
As a consequence of this, the software never terminates, but only throws.
We like to celebrate a special, well-defined moment when the development project is “completed”. However, the reality is that any fixed point in time when we say “everything is done” is simply an artificial dividing line. New features, revised features, and bug fixes will begin to arrive from the moment the “finished” product is delivered (in fact, at the very moment the software is released, changes will still be necessary, representing technical debt and deferred requirements). These changes will continue as long as the software product is used.
It means that no software product is ever absolutely satisfactory. Real software development is like shooting at a moving target – all the various random variations of the target, target movement, wind and vibration guarantee: although you may be close to hitting the bullseye, you will never achieve perfection.
Process change to suit the environment
With this view, software development may seem rather depressing, even gloomy. Everything sounds as if the concepts of predictable and cost-effective development are a pipe dream.
No, this is not about that. Our thesis is that we can become very effective developers if we take into account the realities.
The first reality: although perfection itself is unattainable, but pragmatic success is entirely possible. The LEAN startup movement has made it a common goal for MVP startups, a “minimum viable product.” We must extend this idea to all developments and recognize that each product is in fact MVP – our best approximate solution for a current understanding of the problem.
The second reality is that we cannot really stop changes in requirements, so we need to work in such conditions. This has long been understood in real development: Parnassus rule provides for partitioning the system into modules to increase system flexibility in the event of changes. At the same time, attempts have repeatedly been made to describe software development processes with sequential approximations, i.e., incremental development processes (I called it “Once and for all” methodology, Once and Future).
As soon as we recognize? If we need gradual development, as soon as we free ourselves from the concept of an ideal solution, we can accept the changes with some calm confidence.
The third and final reality is that any schedules are just schedules. We enter the development project, not being able to say exactly what the final product will be. Because of this, no early prediction of completion time can be accurate, and all final versions will be temporary.
Agile development comes to the rescue
Out of recognition of these facts, the Agile Manifesto emerged. The regular release of working software is part of this recognition: a truly flexible project regularly releases working, but non-final implementations. A close relationship with the end user ensures that when changes to requirements become apparent, they can be integrated into the work plan.
Ideally, in a flexible project at a very early stage there is already a working implementation, and systematic noticeable progress gradually leads to the release of a satisfactory product. Remember the metaphor of target shooting: as we progress, we are getting closer and closer to the apple itself. Therefore, we can be sure that after time the product will be at least close to the goal.
