Industrial Office Park
Be Part of CassBeth
The dilemma, how do you build software intensive systems that satisfy customer requirements and needs (these are not the same things) in a predictable cost and schedule effective manor. Coupled with this was/is the realization that if you actually develop something that really works, historically, the time and money spent was/is significant. So, how can you increase the productivity of the software development area primarily, and still deliver good solid software intensive systems.
The problem was actually noticed very early on in the computer era, dating back to the 50's. The approaches back in those days were not only viewed as a technical problem within the realm of computers and the yet to be defined computer science arena, but also a human problem. Many people and organizations proposed and tried using people with widely differing skill sets to develop software in the hope to find the right match between the person and the "software" tasks to be completed. The types of individuals considered were mathematicians, engineers, artists, linguists, and people familiar with the application. A good example is the US Air Traffic Control System, where IBM and the FAA concluded that it was more effective to train air traffic controllers in software development and maintenance, than to train technical types in the air traffic control application. The implementation of software was viewed as a relatively low skill production activity with tight controls and monitoring, as opposed to design. The common thought was that you could train someone to program in 6 months, but it would take someone 5 years to work through all the ATC controller jobs in the system. The work through was the key issue. It was believed that classroom instruction could never substitute for on the job experience ATC controller experience. There is a contrary view-1 and contrary view-2 .
The ATC example is at the heart of this dilemma. In the early stages of the development of the current computer based Air Traffic Control System, there were significant problems with the system. The attempt was to introduce the digital computer into the system and add information management capabilities which were not present in the broad band system. For example, generate a computer symbol for the aircraft position instead of an analog smudge on the CRT. Tag the aircraft symbol with alpha numeric information, instead of using a grease pencil or plastic "shrimp boat" on the CRT surface. The goals however did not meet expectations when the system was initially delivered.
A classic example of the problems in the system were associated with flight plan processing and paper flight strips. A paper flight strip contains all the information associated with an airplane in flight. This includes departing and destination airports and the various legs of the flight. When the system was initially delivered, paper flight strips were printed at each position in the facility, regardless of whether or not that position would ever come in contact with that flight. Further, if there was a change in flight plan due to a controllers clearance, the flight strips would be re-printed with the undated information. Sounded good to the techie's and management types responsible for cost and schedule. The problem was that paper was being generated everywhere. Imagine receiving information from 50 other positions, and you had to determine which ones to throw away. The system met the requirements, but failed miserably in the needs area. Bring in the domain experts, ATC controllers, and train them in software. It took 2 years to get the little flight strips to print to the proper location in a predictable manor. The tradeoff, 2 years work versus printing flight strips everywhere... Hummmm.
Fast forward to Yourden. Perhaps a process, that everyone understood, coupled with automated tools could be used against the software crisis. Fast forward from Structured Systems Analysis to language. The languages are all wrong. A strongly typed language that would enforce good programming techniques would address the crisis, Ada, that's the answer. Oops, our process is still not right. We need to track requirements. A relational database is what is needed, because after all its the system that is not meeting requirements, and we just missed it in the paper mountain of specifications. Fast forward again, you know that SSA stuff ,it really should be Objects, and we need tools for OOA/OOD, that is the answer...
You don't need to be a rocket scientist to see a trend here. Even an air traffic controller can detect this pattern. Obviously developing software intensive systems is hard, but, you know what, there are many of them out there, they work, we are becoming more dependent upon them, because they work, and it is obviously possible to do this stuff and still survive. So what is really going on?
In my humble opinion, the successful systems, are the ones that applied basic engineering principles that have been around for a very long time, at least since the Romans were building roads.
Now for the big question. Should you use software and system engineering tools. The second big question is, which software and system engineering tools should you use in your activity. The early dream of the tool pioneers, the large aerospace companies, was to develop an end to end software factory based on tools. Press a button anywhere in the tool and see the associated code, requirements, data flows / objects, test plans, test results, analysis, models, information products, and anything else that makes up the job. The goal being to see the ripple effects as the system is modified over the years of operation. Does anyone have such a capability, no. The closest vendors appear to be associated with the software tool products. Its possible that the Internet may achieve the original goals of the large aerospace companies. For further information:
v 1.2 7/23/2000 19:30:48
Copyright © 2000 All Rights Reserved.