-----------------------------

ZOOM is an ongoing libraries task force with scope looking past Run II. However, presently ZOOM efforts are dominated by the "ZOOM for Run II" project, which is under the auspices of Run II project management. This is a beakdown of efforts for the ZOOM for Run II project.

This document necessarily discusses effort and not schedule; the missing component for the latter would be concrete allocation of manpower resources.

Development estimates are denominated in units representing one average week of output of one top worker, accounting for missing time from various sources such as vacation days. They do not include administrative and guidance overheads.

Support estimates are denominated in fractions of an FTE. Until a "functional" release of a package is issued, any support needs are subsumed in the development estimates. Support has two components. The first, associated with development and user interaction, should tail substantially some time (say six months) after the user base for the package stops expanding rapidly. The second is proportional to the package development time, times the rate at which new supported platforms are introduced and new compiler versions must be accomodated.

1 - Executive Summary
2 - Sub-projects (Packages)
3 - Defined Deliverables and Milestones
4 - Development effort estimates
5 - Support estimates

---------------------
1 - Executive Summary
---------------------

The ZOOM activities for Run II are grouped into about a dozen packages. Among the intended deliverables, many are fundamental to the workings of the packages; others could conceivably be curtailed if resource allocation forced it.

The estimated required work for the fundamental deliverables is 38 FTE weeks. No single step dominates this, though several CLHEP-related deliverables are of appreciable complexity.

The required work for the remaining deliverables is 80 FTE weeks. The largest single component, at 19 FTE weeks, is preparing a minimal disk-resident Ntuple browser for Histoscope, which is needed to make the histoscope manager a viable resource for HepTuple. Altogether, HepTuple-related deliverables account for 34 of the 80 weeks, and an effort to identify and polish a standard documentaion tool another 22.

The support burden for the fundamentals is at this time at 2.25 FTE and will decrease down to just under 2 FTE over the next 9 months.. The remaining deliverables, if all done, will gradually add .75 FTE to this. These numbers assume the present rate of two new compilers or platforms or major OS changes each year; each additional such change one adds .4 FTE for that year to get all the packages working and continue testing them on the additional platform.

(The support burden has greatly increased in the last six months as several packages were released into serious use, and at the current level we are having difficulty meeting it fully while still doing the needed development.)

---------------------------
2 - Sub-projects (Packages)
---------------------------

It is assumed the reader knows the general nature of each package. Here we list some of the components that will require effort. Components marked + will be split out separately.

CLHEP
* Support on platforms, as CLHEP versions move forward
* Random package enhancement and validation
+ Vavilov distribution in Random package

Documentation Tools
+ Investigation of available products
+ Polishing selected product for general FNAL use

ErrorLogger
* Development: functional and complete releases

Exceptions
In support mode.

HepTuple
* Histoscope manager (completion is imminent)
* Specific minor feature enhancements required by Run II users
* Coordination with BaBar so as to have a jointly functional package
* Proper working on NT with Histo (libraries issue)
+ Minimal Histoscope capabilities for disk-resident Ntuples
+ Third option on file manager: Root as file manager
+ CERNLIB/thread safe libraries issue on NT

LinearAlgebra
* Significant cleanups still needed
* Requested minor enhancements.

PhysicsVectors
* Minor cleanups

Siunits
* NT compatability
* Issues raised by early users

StdHep
+ Development

STLUtility
In (very early) support mode

Zmtools
* Platform-specific issues
* New tool development or coordination

Zmutility
In support mode
* Modifications to accomodate new splitup of DEFECT defines

This list does not include the following activities, which may be done by ZOOM but are either beyond the time scale of immediate Run II applicability, or have not been requested by Run II:

- Development of Histoscope column-wise Ntuple browser
- Integration of PhysicsVectors with analogous CLHEP package
- Insertion of ZOOM modules into ROOT
- Vavilov Distribution improvements beyond basic form

---------------------------------------
3 - Defined Deliverables and Milestones
---------------------------------------

We introduce two terms: A "functional release" is one which may not have all its intended features but allows users to move forward with code depending on the package; a "complete release" is one with full features and available on supported platforms, but it may still be in beta testing to shake out problems.

It is not clear how this project planning process accomodates the desirability of contingencies to take advantage of important opportunities. So for example ZMtools will be listed without deliverables for any new tools, but if a good opportunity arises, we will want to extend the project to take advantage.

CLHEP
1.1 Editorship of Random assumed, and ZOOM enhancements fully integrated
(including CLHEP-style documentation)
1.2 Completion of engine validation, including revised N-dimensional minimum
distance test
1.3 Complete set of validations for distributions

CLHEP - Vavilov
1.4 HepSpline functional release
1.5 Vavilov Distribution in CLHEP
1.6 HepSpline complete release

Documentation Tools
2.1 Checklist of availabe products against essential capabilities
2.2 Functional release of selected product for general FNAL use
2.3 All ZOOM code insturmentited for this documentation form
2.4 Complete release

ErrorLogger
3.1 Functional release
3.2 Complete release

HepTuple
4.1 Completion of complete release with histoscope manager incorporated,
jointly accepted by Run II and BaBar

HepTuple Histoscope
4.3 Release of Histoscope capabilities for disk-resident Ntuples

HepTuple Root
4.4 Functional Release with Root as partial file manager (no N-tuple readback)
4.5 Root file manager Ntuple readback

HepTuple NT
4.6 Heptuple with thread safe CERNLIB on NT

LinearAlgebra
5.1 Complete release

PhysicsVectors
6.1 Maintenance-catchup complete release

Siunits
7.1 NT compatability 2

StdHep
8.1 Functional release
8.2 Complete release

STLUtility

-

Zmtools
10.1 Maintenance-catchup complete release

Zmutility
11.1 Modifications to accomodate new splitup of DEFECT defines

--------------------------------
4 - Development effort estimates
--------------------------------

Total -- 38 FTE-weeks for these fundamental deliverables.

--- SPLIT OFF ENDEAVORS: ---

Total -- 80 FTE-weeks for these deliverables.

---------------------
5 - Support estimates
---------------------

As discussed earlier, support has two components. The first, associated with shaking out bugs that new users find, and adding features that users learn are crucial, starts when a funtional release is in the hands of the users. As long as the user base is rapidly expanding, this phase continues, but 6 months to a year later (I will use 9 months) this component tails off substantially (I will cut in to a third).

After this "expansion tail off" date, the support is dominated by the need for making the package work on new platforms. Here, a truly new compiler or operating system is much more work than a change to a new version of one or the other, but I lump these together and will assume the current pace of this kind of work will continue. Currently, we seem to have one truly new platform, one new compiler, and 3 new minor version changes each year. This will not decrease.

THE "Ongoing Maintenance" CATEGORY IN THE TABLE IS PROPORTIONAL TO THE RATE OF INTRODUCTION OF NEW SUPPORTED PLATFORMS AND VERSISONS. Also, this category is present as soon as the functional release of a package is reached.

For some packages, for instance the "PRESENT" sub-packages of CLHEP, the support is dominated by this sort of work that will not tail off.

To get these dates, for packages which are not yet at a functional release, I have to estimate their release dates. This of course depends on the assumptions made about resource allocation. I try to use middle-of-the-road estimates.

To the support burden we add 10% overhead for web-page upkeep, release notices, and documentation evolution. Also, writeups and presentations, and review preparations have occupied about 15% of the technical support burden. I will break this out separately as "general maintenance overhead" (GMO). For this computation, for the fundamental steps we count the support and evolution category at 2/3 strength since it drops to 1/3 after a while. For the other steps we only count the support and evolutions category since ongoing maintenance will not kick in for a while.

--- SPLIT OFF ENDEAVORS: ---

Additional FTE per new platform per year: .45

In determining these numbers, I used actual time accounting where available. However, in some cases I had to fill in time NOT spent on activities which we really needed to do, and which we now need to catch up on. That is, for the recent months we have needed to devote about 2.1 FTE to support, and have only actually devoted about 1.4. This discrepancy shows, in the fact that our general overhead such as keeping up web pages and preparing papers is woeful, in the fact that bug fixes and responsiveness are slow, and in cutting corners on testing each package on each platform.

These effort estimates assume we will provide an adequate support pattern.