Next: GNOMES: A Case History
Previous: Object-Oriented Modeling and Design for Sloan Digital Sky Survey Retained Data
Table of Contents --- Search ---
PS reprint
Richard J. McGonegal
The Gemini 8-m Telescopes Project,1 950 N. Cherry Ave., Tucson AZ 85726
1The Gemini 8-m Telescopes Project is managed by the Association of Universities for Research in Astronomy, for the National Science Foundation, under an international partnership agreement
The Gemini Project is an international partnership to build two 8-meter telescopes, one on Mauna Kea, Hawaii, and one on Cerro Pachon, Chile. The telescopes will be high performance, 8-meter aperture optical/infrared telescopes and have a planned completion date of 1998--2000.
The goal of the telescopes is to exploit the best natural observing conditions and to undertake a broad range of astronomical research programs within the national communities of the partner countries. In order to reach this goal Gemini has set demanding requirements in terms of image quality, tracking, pointing, and availability. In addition Gemini has requirements to support a number of different observing modes.
These different modes create a requirement for a programmable upper layer to the software---which Gemini calls the Observatory Control System. This system acts to synchronize and sequence the actions of the different subsystems which make up the observatory system.
The Gemini system is being produced as a combination of internationally bid contracts and allocated work packages. In general the allocated work packages represent work in which the partners possess intellectual interest and existing skills. In the area of software/controls, the work is being done currently at five sites; Tucson, Arizona; Victoria, Canada; Edinburgh, Scotland; Chilton, England; and Cambridge, England. In addition the software/controls for the Scientific Instruments will be done at other, yet to be determined sites.
A valid question is, ``Why not just form a central project team and do the software in a conventional fashion at a single site?''. At first look this would seem to be sensible way to proceed and follows conventional wisdom.
Just as the telescopes are designed to exploit the best that the sites can offer the project structure is designed to exploit the best skills that the individual partners can bring to bear on the challenges represented by Gemini. The Astronomy community has a number of individuals with unique skills, expertise, and experience. The project benefits immensely from being able to tap these resources---indeed, access to these resources is required in order to build a telescope which satisfies the specifications, budget, and schedule requirements of Gemini. The Gemini solution to this in the area of software/controls was to form a distributed group. In order to make this successful it was necessary for Gemini to evolve a methodology for how to do this.
Gemini has followed two guiding principles, not always rigorously, in how the system was broken done into its component subsystems: try and partition the system to minimize the subsystem interfaces, and try to locate the software/controls at the same site which is building the mechanism. The partitioning of the subsystems is complicated by the fact that it is a tightly coupled system.
Gemini has adopted parts of the IEEE and ESA standards covering software development. There are used as guidelines for software developers following the Gemini Software Development model.
The development of the Overall System Design was carried out by the Gemini Project Office using engineers drawn from the partner countries. This design went through a formal review process consisting of system design, preliminary design, and critical design where the review committee was made up of members of the partner countries and other large telescope projects.
A Work Package is defined by a formal Work Scope document which is signed by all parties concerned. This Work Scope describes the details of each phase of the development process, the deliverables from each phase, and the details of budget, schedule, and payment. Each of the major phases of the Work Package have an associated review.
Gemini has followed a policy of adopting or adapting to commercial and community standards wherever possible. The philosophy behind this is to spend the time building the application, not the infrastructure for the application.
Gemini's position is that it is only by adopting standards that Gemini can stay ahead of the user driven application demand---after all, users want applications. Users also want applications that work the way their other applications work, and that have the same bells and whistles. By leveraging our applications off of widely used infrastructure standards Gemini can take advantage of the ongoing development efforts as well as the large programming pool available.
The management of a work package is via a matrix management approach. The individual at the site who is responsible for the work remains an employee of his/her existing organization and reports to and takes direction from his/her normal supervisor. However, in all areas to do with the work package, the individual is responsible to the Gemini Controls manager. This means in practice that no changes to the work package which affect specification, budget, or schedule can be taken without prior agreement of Gemini.
A number of lessons have been learned over the preceding three years and there will certainly be new ones. Some of the more important ones are:
It is extremely important that the groups responsible for the work have a real sense of ownership of the work they are doing. This can only be developed by involving the groups in as much of the process as is possible. In the Gemini case this required starting a System Design phase with members of the partner countries involved, having members of the partner countries sit on the review committees, and having the work package responsibles develop the work breakdown structure, schedule and costing on their own.
It is very much easier to do productive work with people whom you know well on a personal as well as professional level. It is imperative, especially during the startup of the project, to have regular face to face meetings. Gemini had someone from the controls group at the remote sites for one week per month for the initial year.
You have to let go---once you involve outside groups you have to be willing to give them the freedom to make design decisions and choices. This means that the system you are building will not be done the way you would have done it. If you manage carefully enough though, it will probably be done better than you were capable of on your own.
The requirements have to change---although it would be easy to insist on having all the requirements iron clad at the start this is unrealistic. To be successful the project must meet the user's expectations, of which the requirements are only an attempt at expressing. The waterfall model of software/control development is not appropriate in this environment.
The most important aspect of keeping a distributed group on schedule would appear to be good communications. Gemini uses a mix of e-mail, e-mail exploders, site visits, FTP mirrors, teleconferences, video conferences, Fax, and postal mail to accomplish this---each of these has its pros and cons.
The Gemini Project's Software Development Methodology effectively meets the challenges posed by Gemini's distributed nature. Although this methodology is more challenging and more expensive than centralized management this does not necessarily translate into more difficulty and more expense for the project as a whole. Indeed, it is the author's experience that distributed management allows one to access much more qualified people to work on the project than a hiring process would result in. This is not to say that the project cannot recruit and hire highly skilled staff---just that the pool is much larger if one is willing to do it in a distributed fashion. This results in cost savings, schedule shortening, and improved system performance relative to a centralized staff---however such improvements are difficult to quantify up front. Our current metrics show that staff, in general, are meeting their milestones with only 70--80% of the effort they estimated.
A methodology makes it is possible to successfully manage a large, distributed software/controls development effort---although Gemini has a few more years to go before we can lay claim to ultimate success. However the Gemini software/controls task is currently on budget, to schedule, and has yet to miss a specification.
A distributed project is the only way large science projects will be done in the future so we need to find methodologies that work and not be afraid to try new models. The advent of high bandwidth communications at reasonable rates will bring more and more of these types of group interactions into the forefront. The ability to quickly form and disperse inter-organizational project teams in a distributed fashion will be key to keeping costs and schedules in check while at the same time meeting the challenging specifications with low risk solutions.