Software Engineering for the Virgo Project at EGO

1

• Software Engineering for the Virgo Project at
  EGO

F. Carbognani for The Virgo Collaboration iCALEP
CS - Geneva 10-14 October, 2005

2
Virgo Project

• Suspended Michelson Interferometer with two 3 Km
  arms aimed at the detection of gravitational wave
  signals from cosmic sources

2
3
Project Numbers

• 700933 Lines of Code (LOC) of C/C and Assembler
  
• Supported external packages amount of 371339 LOC
  of C/C
• 50 Workstation 60 Local Control Units (RIOs)
  for the Interferometer operation
• 4 operating systems (OS9, alpha/OSF1, Linux,
  LynxOs
• 2 countries, 6 laboratories, 18 teams, almost 100
  developers over the current lifespan of the
  project.

3
4
Size
4
5
Main Ideas

• Scientific software projects like VIRGO are
  becoming too large and complex to be managed
  without proper SE procedures
• Heavy-weight procesess and standards, like CMM,
  IEEE or ISO 9000 somethime limit their existence
  to office cupboards.
• Standards need to be simple and implemented by
  embedding them as a set of consistent tools

5
6
Key Areas

• Configuration Management
• Problem Report
• Development Environment
• Documentation
• (Automatic) Testing
• Releases
• Performance Monitoring

6
7
Configuration Management

• The supporting tool (SCVS) is a very thin layer
  on top of CVS aimed to simplify its use and
  tailor it on the Virgo Software development
  specificity.
• The basic rules behind SCVS are
• All files belonging to a package are handled at
  the same time
• Only one person at time can modify a package
• Branches are supported
• In archiving a package, the developer tells the
  others that a new CONSISTENT set of files is
  ready for use.

7
8
Software Archive Access and Size
8
9
Software Problem Report (SPR)

• Provides an easy standard avenue for users and
  testers to report bugs and for developers and
  maintainers to fix them and track them in an
  orderly fashion.
• Very simple interface and SPRs lifecycle to avoid
  that developers end up in spending more time on
  the bug tracking system than on the bugs or the
  projects themselves.
• A central database with Web and email interface
  to submit, query, modify SPRs (implemented using
  WREQ)

9
10
SPR Statistics
VCS-3.0
10
11
Development Environment

• A standardized development essential requirement
  to manage different people in different sites.
• Such standardized environment has been obtained
  using the tool CMT
• CMT provides all key elements of a development
  environment
• structured make usage
• easy encapsulation of third party tools and
  libraries
• standardization of the UNIX environment set-up of
  every Virgo user.

11
12
Documentation

• Document Templates
• Whenever possible extract documentation from the
  code itself for maintainability
• Doxygen support
• CMT fragments for the generation of the Doxygen
  documents via make
• Doxyfile template.

12
13
Testing

• Has to be automatic
• Tool for Automated Testing(tat) has been adopted
  and slightly modified for the Virgo software
• Key feature of tat are
• The test execution has a standard and very simple
  interface (just a single command)
• The test command prepares the environment set-up,
  executes the test(s), filters out variant data
  (dates, time, host names), compares results
  against reference and provides FAILED or PASSED
  result.

13
14
Testing (cont.)

• Virgo Test Facility (VTF)
• Model of control system and control room
• Validation of Software Releases
• Validation of Operating Systems baselines
• Integration tests for subsystems
• Implements a full Suspension Crate replica and
  minimal DAQ chain.
• Being continuously upgraded and expanded

14
15
Releases

• Slow upgrade cycle (3-6 months) for Major
  (External) Releases, on demand for Minor
  (Internal) Releases
• Tested for non-regression
• Uniquely identify all components (O.S., tools,
  external packages, Common Software) needed as
  development or operational platform of an
  application.
• Provide the explicit Integration Plan
• Heavily relying on the Virgo Test Facility (VTF)
  for the build and test phase
• Latest releases represent a true fully aligned
  baseline

15
16
VCS-1.0 Use Dependency
16
17
VCS-3.0 Use Dependency
17
18
System Monitoring

• The Software Release cycle must be completed by
  collecting field data to be carefully analyzed
  for succeeding releases.
• The normal scope of the Big Brother tool
  (monitoring System and Network-delivered
  services) has been extended by proposing and
  customizing it as a common framework for all
  Virgo Subsystems performances monitoring
• BB graphs very effective in spotting specific
  software problems.

18
19
System Monitoring (cont.)
19
20
Future Steps

• Support for the Object Oriented development
  approach
• New templates for Analysis and Design Documents
• UML and Use Cases Evaluation of the umbrello
  graphical tool
• C Class templates (hpp and cpp files)
  containing the Doxygen tags
• Web based documentation and teamwork support
• Automatic generation of User Manuals in HTML
  format via Doxygen
• Use of the Wiki tool as the main project
  development space, document management system and
  knowledge base.
• Integrated Development Environment (IDE)
• KDevelop being customized for fully automated
  Doxygen documentation generation and for CMT
  integration

20
21
Conclusion

• SE does not come for free, but can be brought
  into a project at a reasonable cost.
• SE can be implemented in gradual steps, providing
  first the most urgent tools and procedures, and
  then letting focused pilot projects lead the way
  for the full SE approach
• Even on a more code-and-fix oriented
  environment, with some effort, SE can be accepted
  and shared.

21