| When we specify the function set of a new application, it is not necessary to identify robustness or trustworthiness as qualities explicitly in either quantitative or qualitative terms. These qualities are intrinsic. If the application carries out the intended function set without error (or without compromise by unanticipated exogenous influences, such as noise factors), the software is by definition trustworthy (always does what the user depends on it to do). Therefore, it is robust (its "signal" is never lost in the "noise" of daily use). The major requirement at this stage is clarity in describing the system's intended functions. The required degree of clarity can come only from the ultimate users of the system, not generally the buyers of the system or even the managers. Naturally, the needs of these groups for economy, performance, audit trailing, transaction logging, and so on must be met. However, the system's primary functionality must be declared by the active users. As Sidebar 16.2 illustrates, obtaining this degree of clarity has been a problem from the earliest days of computing. One of the earliest rules of thumb in business application development was that the first time an application was computerized, it was simply automating the paperwork. That is, the computer's intrinsic capability to improve or reengineer the business process was totally ignored. A second rule was essentially a corollary of the first: An information system must be developed three times before it really makes use of the computer in any intrinsic way. Sidebar 16.2: Getting the End User's Input One of the authors used to teach at the University of Minnesota and directed its control data Cyber 74/174 computer center. He was called back to his previous employer, a software firm, as a consultant to write a precise functional specification for a juvenile justice system for Ramsay County, Minnesota, where St. Paul is located. The local control data firm had been the unexpected low bidder with a Cyber 174 computer. This computer normally was sold for technical and scientific applications written in FORTRAN. However, the machine was blessed with one of the best COBOL compliers ever written. It was just beginning to appear in business and government installations. The author had just developed the Hennepin County (where Minneapolis is county seat) justice system before leaving the software firm to go to the university. Thus, he was familiar with the Law Enforcement Assistance Administration (LEAA) guidelines for such local government justice information systems. At the first meeting with the juvenile justice department senior staff and board of governors, the author explained in detail how the design team would interview the juvenile probation officers to learn their needs and expectations for the system that would be serving them. The meeting quickly disintegrated. The management group asserted that they were in charge of this department, they had the budget, and they were buying the system, so there was no need for us to talk to the probation officers, who were just low-level employees anyway. They were obviously inexperienced buyers of this sort of technology, so the author began to ask them a series of "optometrist questions": Would you prefer to see A or B? Which would be better, C or D? What about the choice between E and F? Naturally, they had no idea what he was talking about. They reluctantly agreed that he could interview the junior staff, but they would still have to approve the specification. To this proposition he readily agreed! This anecdote illustrates that the people buying a computer application or system are not necessarily the ones who will be using it, but the software architect must accommodate the needs of both. |
|
