System development methods that reflect the times
When I joined a banking system company as a fresh graduate in the 1990s, I had no idea why the waterfall system was suitable for the development of banking systems.
The waterfall type is a method of carrying out the phases of requirement definition, basic plan, detailed design, program development, unit test, combined test, and system test in a one-way manner without going backwards, just like water flows from upstream to downstream in a river.
In the 2000s, prototype type, spiral type, and other anti-waterfall development methodologies were proposed, and after many twists and turns, a coalition of opposition parties called the Agile type has been formed.
Currently, our method of developing and implementing manufacturing systems in Indonesia is the closest to the spiral type, which we don't hear so much about now, and rarely does the waterfall type when it is done under the project management of Japanese information systems.
As expected, it's a method of repeating small requirements definition, development, and review, while building up results and gradually aiming for a finished product.
Since the definition of spiral and agile is controversial, I don't feel it is meaningless to explain the difference in methodology, but from the standpoint of working in the field, I think the difference is that if the customer's requirements are solid, the result will be agile, and if they are not, it will be spiral.
It's not a matter of saying that the waterfall method is old, or that it's now an agile method, it's just that there are methods depending on the characteristics of the system and the environment of the project, and it's difficult to let go of the method that you're used to, even though the method that's appropriate for the situation should be chosen.
This can lead to the delivery of a system with low functionality that does not reflect the opinions of the users on the ground, or to an abnormal increase in time and cost when a certain level of completion is achieved.
Why waterfall is a good choice for the banking system
Banking systems are broadly divided into two types of systems: core banking systems that support deposits, lending, and foreign exchange remittances, and information systems that provide the information necessary for core banking operations, such as credit analysis for each customer, based on these transaction data.
The company's organizational structure consisted of a development team responsible for the development and maintenance of core systems, a technical team that maintained the environment around the mainframe and off-the-shelf computer operating systems, introduced new equipment, and maintained the network, a library team that reflected the development programs in production and managed the history of the source code, an overseas system team specializing in overseas business systems in New York and London, an information system team that developed PC and UNIX systems, and an operations team that backed up mainframes and off-the-shelf computers and maintained them at night.
The vast amount of handwritten source code written in PL/1, COBOL, RPG, Visual Basic, etc. was kept in a wardrobe that stretched about 20 meters from one end of the floor to the other, with suffixes (branch numbers) to keep track of it, and like the secret soup in a ramen restaurant, it was enhanced with each addition over the years.
After six months of training, I was assigned to the overseas system team and was in charge of developing a system for overseas branches using an RPG (Report Program Generator) running on an off-controller (AS/400). After that, I was transferred to the technical team and developed a system to control an OTM (Online Tellers Machine) terminal that automatically counted the number of bills, together with a subcontractor who was dispatched to the company.
At that time, the term "downsizing" was gaining popularity, and the focus of system development was shifting to a distributed PC-based system, so I was concerned about the work of the neighboring information system team that was developing the system.
One of the reasons why waterfall type is suitable for the joint development and management of a system that requires huge and strict security is that the responsibility becomes clearer. When a problem occurs, it becomes clear who did what and what was the cause.
In order to maintain absolute reliability, it was necessary to set a target date for the development system to be reflected in production, to set an overall schedule for each process by postponement, to reflect it in production through careful testing, and to have a management system that could analyze the source code quickly in case of failure.
If you can't define requirements, you're forced to spiral
In the waterfall type, the entire requirement is defined as a specification at the initial stage of the project, while in the agile type, the requirement is defined as a specification for each function, but in either case, it is assumed that the customer has already compiled the requirements.
In the Indonesian manufacturing industry, only large companies with in-house information systems are able to summarize requirements on the customer side, and I don't think it's possible for the person in charge of the system development project leader to summarize requirements at the level of the system specifications.
Because we can't summarize the requirements, the SI company like our company makes a prototype and repeats the review while hearing the requirements from the person in charge. However, in the process of the project progressing and the form of the system being materialized, the requirement change "I want to do this after all" usually occurs.
At this time, I listen to the other side's sudden request without becoming emotional, feel unreasonable to be complained about the errors that occur due to repeated specification changes, but patiently squash the bugs, maintain a good relationship, and say "I understand. So, I'll draw the line, "Well, once we've implemented this new requirement, please accept it.
It is predictable that specification changes will occur in advance if the requirements are not set up, and if we don't cut back at a certain level while taking on such a project, the costs that will be incurred will be on our own forever.
For a large client with a large budget, waterfall type or agile type will not be a problem, because it tends to require a lot of man-hours other than coding. However, for a small to medium-sized client with a limited budget, it is important to maintain the overall cost balance by reducing other man-hours such as creating specifications and testing, because the ratio of coding to man-hours is expected to be high.