next up previous
Next: Independent Technology Inc. (ITI) Up: Projects Previous: Digital's Virtual Memory System

Stanford University Infrastructure

The business functions of Stanford University are currently managed by a relatively large group of developers and maintainers. The group numbers about 200. In the early 1970s, this group began building an environment based on SPIRES ( [#!Martin:1974!#], [#!MarPar71!#], [#!Parker67!#] ) a hierarchical text database system originally used to store scientific (high energy physics) documents. On top of SPIRES was built an infrastructure to support email, event messaging, work flow, forms routing, and digital signature. Using this infrastructure, the two major applications, one centered around accounting and the other centered around students information, were written.

The development of this system took about two and a half decades. This is an example of a thousands of person year project.

The software engineering methodology followed was cyclical in nature. The builder's of the system and the customer's of the system were almost one in the same. Small incremental changes were made to meet small requirement changes. Testing was done by the staff at the help desk. If it worked on the examples in the help manual, it was declared to be ready for deployment. Deployment was easy because it was only on one machine. Customers would connect through terminals. Everything was custom built to handle small-detailed changes.

There is no one requirement document. There is no one architecture document. There is no one person who understands the complete system. This is a recipe for pending disaster. Individual members in the development team knew only local information.

The system served the university well until the wake-up call in the mid 1990s. The federal government made charges against the university of major errors in billing. To show otherwise would require a special query across the general ledger. This class of queries was never before attempted and had to be written, in assembly code, from scratch. It took over a year and about 10 person years worth of work to finish this query that showed the university to be in compliance.

See tables 7.7 and 7.8 starting on page [*].

Table 7.7: Survey Part 1: Basic Properties Stanford
Question Response
Analysis? none.. poor..fair..good..great
Design? none..poor..fair.. good..great
Implementation? none..poor..fair.. good..great
Testing? none..poor.. fair..good..great
Cycles of ADIT? one..few..several.. frequent
Priority? no..yes
Versions? no.. yes
Change Order Control? no..yes
Internal Prototype? no..yes
External Prototype? no..yes
Alpha Release? no..yes
Beta Release? no..yes
Duration? 25 years
Effort? greater than 1,000 person years

Table 7.8: Survey Part 2: Change Control Stanford
Question Response
Did a new introduced requirement ever negatively affect accomplished work? never..seldom.. often..frequent
Did an architectural change ever negatively affect accomplished work? never..seldom.. often..frequent
Are new features introduced up to product release? never..seldom..often.. frequent
Is there a dedicated period of quality assurance before the product is released? no..yes

next up previous
Next: Independent Technology Inc. (ITI) Up: Projects Previous: Digital's Virtual Memory System
Ronald LeRoi Burback