aa r X i v : . [ a s t r o - ph ] D ec Astronomical Data Analysis Software and Systems XVI
O10.4
ASP Conference Series, Vol. XXX, 2006R. Shaw, F. Hill and D. Bell, eds.
ECSS in the eXtreme
W. O’Mullane, J. Hoar, U. Lammers
European Space Astronomy Centre, Avda. de los Castillos s/n E-28692,Villanueva de la Canada (Madrid)
Abstract.
The ESAC Gaia team engages in a form of eXtreme pro-gramming while the DPAC will follow a series of six month developmentcycles modeled on this approach. As a project within the European SpaceAgency the European Committee for Space Standardization (ECSS) stan-dards are required. We present the bringing together of these realms.
1. Introduction
ECSS standards may be difficult to understand and without good tailoring arenot well suited to the development of science processing software. Here we tellthe DPAC story so far.
2. The Gaia Satellite and Science
The Gaia payload consists of three distinct instruments for astrometric, pho-tometric and spectroscopic measurements, mounted on a single optical bench.Unlike HST and SIM, which are pointing missions observing a preselected listof objects, Gaia is a scanning satellite that will repeatedly survey in a system-atic way the whole sky. The main performances of Gaia expressed with justa few numbers are just staggering and account for the vast scientific harvestawaited from the mission: a complete survey to 20th magnitude of all pointsources amounting to more than one thousand million objects, with an astro-metric accuracy of 12–25 µ as at 15th magnitude and 7 µ as for the few millionstars brighter than 13th magnitude; radial velocities down to 17th magnitude,with an accuracy ranging from 1 to 15 km s − ; multi-epoch spectrophotometryfor every observed source sampling from the visible to the near IR.Gaia is being constructed by EADS Astrium under contract from ESA andis scheduled for launch at the end of 2012. It is to spend five years at L2 carryingout its survey. The 35 meter antenna in Cebrerros Spain (an occasionally NewNorcia) will be used to downlink about 100 Terabytes of data.
3. The Astrometric Global Iterative Solution (AGIS)
The astrometry of Gaia is calculated from the multiple observations in differentdirections of the five years of the mission. The approach to this data reductionis a block iterative robust least squares fitting of the data as presented at the1 Figure 1. Royce’s waterfall model (left) reproduced from Royce 1970.This is held to be the original waterfall approach but it is a schemewhich Royce’s paper claims is flawed. The right figure appears later inthe same paper.last ADASS (O’Mullane et al. 2007). Briefly objects are matched from thesuccessive scans, attitude (three dimensional orientation of the satellite) andcalibrations are updated. Next the object positions are solved followed by higherorder terms usually referred to as global parameters (such as PPN γ ). Thisreduction provides us with : observed (proper) directions to a subset of well-behaved (primary) sources, attitude of the instrument as function of time andtransformation from field angles to pixel coordinates. This requires selecting10 of the 10 sources as input to the process and treating, iteratively, the 10
4. Is development of Science software different ?
The author conducted a survey over one year of many large science developmentsO’Mullane 2005. This proved to be a most interesting study and concluded thatscience software development is indeed different to traditional software develop-ment due to the funding structure and general approach to leadership. This isin any case quite different to a satellite development project. Yet large organ-isations still wish to see developments like Gaia in a more traditional waterfallmodel. The approach to development within DPAC of using cycles and alwayshaving some working software leans much more toward the
Agile techniques dis-cussed here than traditional project management. Indeed these days there arefew if any software companies remaining who follow the waterfall approach todevelopment. The most lamentable thing of all is perhaps that Royce,attributedwith the waterfall model, showed the waterfall approach in Royce 1970 (see LeftFig.1) as an example of the flawed way to do software development. Later inthe same paper Royce (see Right Fig. 1) he argues one should ”do it twice”.He points out the flaw in that it is a long time before implementation startsand real problems are seen. These real problems may fundamentally changerequirements. All of these ideas are in line with
Agile approaches. Our intentionis to do it far more than twice - about ten times for DPAC. Even the preliminaryAGIS went through several iterations before it was ready.
CSS in the eXtreme
5. eXtreme development approach
No we do not all huddle around a single computer at ESAC but we have takensome useful ideas from the eXtreme programming field such as presented byBeck 1999. Planning is done on a monthly basis, stories are written and costedin points (where 1 point ≈ / day ). The cost is agreed as a team not set by amanager . Team members are also given points with which they buy the storiesthey wish to work on. Some stories of course must be bought first but generallyteam members should be able to have some story they would like to do in additionto the stories they em must do. All stories are entered in the XpTracker, a Twikiplugin designed for eXtreme programming.Code, in general, is owned by the group - any developer may improve code.Code reviews are carried out frequently as a group where developers modifycode and comments as well as raise issues. In this way we try to keep codein adherence with he agreed coding standards as well as keeping documentationvalid and up to date. Such an open system only works with excellent test harnessin place. We use JUnit to write tests and place emphasis on good test coverage(looking for 80 to 100%). CruiseControl is employed to regually check out code,build it and run all of the JUnit tests. Developers must keep tests passing whenany modification is made to the code. The AGIS system ,for example, contains100K lines of Java, 30K lines of test code and 90K lines of comments.
6. European Cooperation for Space Standardization (ECSS)
The European Space Agency (ESA) generally is more involved with satellite con-struction which follows a waterfall model of development. Indeed for hardwareproduction there is little choice. Springing from this background the ECSS stan-dards tell us how we should do a project, what documents should be producedwhen and, to some degree, what they should contain. The standards come as along list of books for example : ECSS-E-10B Requirements , ECSS-M-30A Phas-ing, ECSS-M-40B Configuration Management, ECSS-Q-20B Quality Assurance,etc. The also come with a set of reviews which should be held which hark backtot he waterfall they are the System Requirements Review, the PreliminaryDesign Review, the Critical Design Review, the Qualification Review and theAcceptance Review. ECSS is considered applicable also to the ground segmentsoftware which includes the science processing software.In reality ECSS is very flexible - perhaps too flexible, it must be tailoredto a particular project. Clearly some of the ECSS is not applicable to softwareproduction so a tailoring must be undertaken. This outlines which parts of ECSS Figure 2. Gaia DPAC document tree matching ECSSwill be used for the project and define to some extent the document tree (seeFigure 2).
7. Conclusion
The usefulness of an eXtreme programming approach has been demonstrated forthe AGIS software at ESAC. In general this sort of approach is very well suitedto scientific software development. If this will work in the scaled up mannerfor DPAC does remain to be seen. Every project needs documentation andwith a little effort the ECSS has been em tailored and a useful set of standard documentation outlined. Templates for these documents have been created.There remains considerable pressure toward more em traditional techniques forDPAC. Daily reading of Dilbert is recommended for sanity.