Об одном проекте "клиент-сервер"
Марк Уоллес (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:
- 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..
- 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.
|