[ Russian ] [ English ]

Об одном проекте "клиент-сервер"

Марк Уоллес (Mark Walles),
IBM Corp.,

Much has been written about the Client/Server architecture, as a solution to business computing problems. What are the results of using it on an actual project? This report will discuss one such use of a Client/Server approach on a new development project that began in the Summer of 1993.

The project was rather small (total software cost on the order of \$500,000), and new, in the sense that it did not require the conversion of any software or data from older systems. (Before the project, the customer was managing the data first using a spreadsheet, and after that with a "quick-and-dirty," hard-coded data base in Microsoft Access.)

The objective of the project was to provide automated support for a testing laboratory. The job of the laboratory is to assess compatibility of the add-on components sold by this enterprise, with existing IBM-compatible PC's made by any manufacturer. Automated support was requested for two aspects: 
  1. Management of the testing process, e.g., who sent this PC to us for testing, what is their telephone number, when have we promised to return it to them, and where, etc..
  2. Storage of the actual results of the tests. 

The first test protocol that was automated called for about 750 data points to be gathered for each PC submitted for testing. One key aspect of the problem was that those data points were not all of the same data type.

Software engineering methods used included object-oriented analysis and essential systems design, both as created by John F. Palmer, one of the members of the development team. In March, 1994, designs for the application and data base were delivered to the customer. They were placed into service later that year. Despite an enormous number of changes to the function of the system since that time, the data base design has not had to be modified, at all. The customer has indicated to the design team that to have a data base design survive for more than a month or two is a virtually unknown experience for them, given the volatility of their business.

The key lessons learned during the project fall into two main categories: business and technical. On the business side, one lesson was on the use of phased contracts as a middle ground between an initial fixed-price bid and hourly billing. On the technical side, we validated the selected technology (e.g., Smalltalk and SQL Server), but discovered that user requirements can change too quickly to be serviced by any hand-coded user interface, even given the strongest build technology available today (drag-and-drop GUI with objects).

The presentation will discuss in more detail (1) the business problem that the project was supposed to solve, (2) the software development strategy, (3) the specification methodology that was used (with example documents), (4) the history of the project, and (5) the lessons that were learned from the project.

The presenter was the prime contractor to the customer, and the leader of the effort during the phases: feasibility study, detailed analysis, and detailed design. 

Supported by Synthesis Group