The requirements may not be the first or the last word
In the most popular models of software development, emphasis is placed on reviews that guarantee that the system meets the specifications of the project. But... Who checks that the specifications meet the objectives of the development?
Recently, the director of NASA, Michael Griffin, said in an interview that in his opinion the program of space shuttles was completely mistaken and that he believed that NASA's strategic plans has 'lost their way' in the 70s when they decided to terminate the Apollo moon missions. According to him, the shuttle program doesn't make any sense because it is based on vehicles that can only orbit the earth and isn't in line with the objectives of colonizing the moon and Mars that were announced by G.W. Bush in his electoral campaign.
This is noteworthy coming from an organization like NASA, a paragon of methodology and technology (not to mention science), but how many times have we seen this in the world of information technology? How many times have we seen strategic decisions go against the 'winds and the tides' and result in systems that don't have any relationship to the objectives of the business for which they were designed?
In some development methodologies we see evolutionary models (Microsoft and its MSF, or the CMMI model of the Software Engineering Institute among others) where systems are reviewed and evolved so that they continue to satisfy the requirements (objectives). But success at conforming with the specifications does not guarantee that the original specifications were appropriate for the real needs of the end users of the system.
There are techniques and tools, like JAD and others, that start in the analysis of users' requirements, and help launch development projects of the appropriate size and cost based on the needs. In my experience, these methods either are not used, or are used 'for show' in such as way that the possible benefits that could have been brought to the project are not realised.
Most methodologies, techniques and tools for system development start with the axiom that the specifications are the foundations of the system. Clearly, as in the case of NASA, this can lead to situations like that in the joke about a surgeon who came out of the operating room and reported to the patient's family, “Everything went splendidly, the operation was a success, but the patient died”.
Here are my principles for the period before starting a development project:
These principles aren't a panacea, but as Napoleon said, “Dress me slowly because I am in a hurry”.
|Return to Translations Index
E-mail comments to: