Software Development - the ‘wacko’ model and the appropriate one
by adminGreetings 
Good day. I recently stumbled onto the following picture while digging.
Part of it is true.
The customer is indeed vague about what he wants. He usually explains things according to what he has seen online. One example is the need for a portal. He will say “I want a site for my company. Have you ever seen www.servihoo.com? I want it that way.”
The project leader may ask a few questions but he will have to adapt the so-thought look-alike product to the customer’s needs. Hence, the product is no longer the same as depicted by the customer.
The analyst will go through the various processes from interviews to on-site observations to later come up with several solutions. These are usually part of the feasility study itself, though it can be separated in various phases. Do note that in real life, things don’t go by the book – it’s a mess. 
And of course, though the criteria for the so-called perfect solution are met or will be met (depending on the flexibility of decisions made,) the design is very different to what is expected from the customer.
I agree with the first 3 pictures. The others – well, I’ve never encountered such trouble/mess.
As a developer, I have to work hard to avoid giving away a product not matching the needs of the customer.
Here is how things are in real life (’wacko’ model) – the customer calls the managing director of the company, asking him to design a product. The latter does a preliminary Q’nA about the needs and wants. There is a briefing. The underlings of developers (hi hi hi – why underlings? ‘coz I’ve watched too much of Midori No Hibi :P) gather more information. They act as analyst, deal with the customers and workers over the phone, and report back to developers. Having the data, they make sure that all data is present.
The planning begins. So far, the layout of the product is entirely discarded. The needs need to be met. UML are designed on a whiteboard. A checklist of features is made. The choice of technology to be used for different parts of the products is also decided at this point. Security (mostly encryption,) backup and restore, and management of resources are discussed but usually put of hold ‘coz of the moto: “GET THE FRAMEWORK DONE!”
The developers stare at the deadlines *whimper* and ‘parts’ are assigned.
Time goes by, and the application(s) get created. Modular and integration testing are done on a daily basis. The entire work is backed up daily as well. In a way, the development architecture is a tree, although at times, branches are considered as layers, depending on the complexity of the application. Occasional “check-out” calls from the customers are handled by the underlings. Progress reports are given to the manager who forwards those to customers.
After the needs (aka features) have been met, and the system works as planned, resource management begins (extra lines of codes need to be exterminated. Paging, threading, bandwith management, security, backup, restoration, are things to ‘cover’.) The appearance of the product at this stage totally sucks.
After having perfected the system by adding new features, and made sure that it is optimised, the layout is dealt with. This is usually done within a week. If it is a mobile or web applications, various platforms need different styles of coding at the presentation level. But developers bear in mind the look must be the same.
After systems testing, and beta testing (takes 1 week,) the system goes live. The customer is happy and the system is maintained for quite a while. Occasional bugs encountered are dealt with – these usually don’t occur often due to the development architecture being a tree-layer hybrid one.
One should note that the above applies when there are few developers who do most of the work (even the designing part for synthesis is always good when it comes to increasing the productivity level.) Sure, it defies whatever one might have learnt at tertiary level, but it works when the development chooses to be risky.
How should development be?
Ever since I’ve been in the field, I wanted to give a try to the Boehm spiral model.
As shown above, each loop is split into 4 sectors:
- Finding constraints and objectives of system
The objectives of the system are defined. Problems are identified and a plan is drawn up.
- Evaluation and identification of risks
Risks are identified in detail. Ways to reduce risks are devised. Prototypes are developed according to the level of the risks identified.
- Development, verification of next level product
A development model is chosen. If the customer stresses on getting to know the interface, prototyping is opted for. If the system is well known and that there is a possibility for minor iterations, even the waterfall model can be chosen.
- Plan next phase
The system project is reviewed. If things get a go by being well, plans are devised for the next phases.
Boehm’s model stresses on risks identification and analysis. Risks are problems which may occur – like developing an e-commerce site on a new language and later find out that it does not have the features required for such a site. Risks cause delays in schedule.
At the start of the spiral, the objectives as well as the problems are assessed. Alternative to ways of achieving objectives are analysed and sources of risks are located and ways to reduce the impact of risks are devised. Information gathering is done. The development is carried out according to the plan for the next phase. Iteration also helps.
What should be done?
To be honest, I don’t know. On one hand, you’ve a trend which though is faulty, actually works. And on the other, you’ve the good development model. What matters – Get things done and make the customer happy! Also, NEVER screw up.
Have a fun Saturday
Shah