DEVELOPMENT AND TEST FACTORS

Development Considerations

• The ATCS will be developed based on the UT TCS and as much as possible of the analysis, design and implementation will be reused.
• Prototypes for the most critical components will be developed. In particular a prototype for the Coudé Sensor LCU is foreseen. A workstation and a rack with the most important AT LCUs will be installed in the VLT Control Model. It will be used as a prototype for the whole AT Control System and for integration testing of the AT Control Software and of the Combined Operation Software.
• The processes of analysis, designed and implementation of the ATCS will follow an object oriented approach based on the Unified Modeling Language (UML).
• The Rational Rose Object Oriented Analysis and Design tool will be used to support the analysis and design phases, but the usage of a CASE tool is not a requirement.
• ESO is open to consider and discuss proposals regarding other non standard software platforms, which might show attractive features and be suitable for specific tasks. In particular the usage of Java as a programming language and of CORBA as a distribution platform can be investigated for the higher level software and for future interfaces with external software.

The provisions in the VLT Software Programming Standards [AD02 ] and the CCS Functional specification are applied in the design and development of the software of the TCS package. In particular: The naming of modules, functions and data, and the directory structure follow what is defined in the VLT Software Programming Standards [ AD02 ]. The Central Control Software is used wherever applicable and possible, both at workstation and LCU level Exceptions are explained and listed. The code must conform as much as possible to POSIX standards. Exceptions are explained and listed. A highly modular approach is made, in order to provide the flexibility for changes and extensions which are very likely to be requested.

For the development of the various stages described in the Planning section, are needed: Hardware. HP or SUN WS PC + X11 terminals to be used for design, development, documentation and running interactive test programs. ATCS HW prototype VLT TCS Control Model Software: VLT development environment VLT Common Software (CCS[Lite] and LCC). INS common software.

Risk Assessment

The following paragraphs assess the risks of the project.

Requirement Risks

The purpose of this section is to draw attention on the question if we are building the right system. That means if the requirements capture the system as the user wants it to be.

Since we capture the requirements through Use Cases we have to discover all the potential ones for the system. Of course we are not going to get all of them. But we should get most, in particular the most important ones.

Having already built the UT Control Software we have a very good understanding of all basic requirements and we do not expect risks in these areas.

Nevertheless some sub-systems are new and certain, well known, concepts (like guiding), are based on different (new) sub-systems.

Areas that bear the risk of missing Use Cases are (in order of importance):

• Field Stabilization and Auto Guiding
• Optical adjustment procedures
• Procedures related to relocation of the telescope
• Chopping

Technological Risks

The purpose of this section is to assess the risks related to new technology we are going to use in the systems. Both, in terms of software and in terms of hardware we have to control with software, have to be taken into account.

In order to address these risks, prototypes should be built to try out the new pieces and then to estimate the impact.

We are aware that risks appear in particular in combining technologies, even if we know them individually very well.

Areas that bear technological risks (in order of importance):

• Control and interfacing with APD (completely new system)
• Field stabilization system with the APD (new way of doing Field Stabilization)
• Java as graphical user interface (Completely new development approach to GUI design, to be evaluated). If Java turns out to be unsuitable for our requirements, the current technology (Tcl/Tk) will be used.
• CORBA as middleware between Java GUIs and telescope control (new interprocess communication platform, to be evaluated). If CORBA turns out to be unsuitable for our requirements, the current technology (CCS) will used only. A feasibility study has to be carried out.
• Integration and reuse of existing TCS software modules (Good experience with other projects, e.g. ASM and NTT)
• Using Object Oriented concepts to build the system (Good experience with UT Control Software)

Skill Risks

This section assesses the risks related to the skills that are required by the team that is building the system. We list the skills that are essential for successful completion of the project.

• Building software on LCU level
• Building software on WS level
• Telescope Control Software
• Object Oriented Analysis and Design
• Object Oriented Programming
• Java as GUI implementation language
• CORBA integration and implementation

Architectural Risks

To each use case an architectural risk is associated, i.e. the risk that a misunderstanding in the requirements mapped in the Use Case has deep impact in the whole architecture of the system.

Use cases shall be categorized in: high risk, risk possible but not likely, and little chance of risk.

The uses cases should be assigned in this order to the individual iterations, i.e. high risk uses cases first.

This aspect will be assessed together with the development of the detailed planning.

Note: The risk of a Use Case should not be confused with the priority given in each Use Case. The priority of the use case describes how critical the Use Case is w.r.t. the usage or operability of the system, i.e. how big the need of the user is to have that use case. Whereas the risk describes the technical point of view, w.r.t. design or implementational problems or difficulties.

Schedule Risks

This risk is related to the estimated effort required for each use case.

For each use case an estimate for the length of development time needed shall be done, to the nearest man-week. This estimate includes analysis, design, coding, unit testing, integration and documentation.

This aspect will be assessed together with the development of the detailed planning.

Planning

The essence of the plan is to set up a series of iterations for the construction of the system and to assign use cases to iterations.
The Plan is finished when each use case is put into an iteration and each iteration's start date has been identified.

An iteration should be long enough to do a handful of use cases.

A detailed plan is part of the Auxiliary Telescope Control Software (ATCS) Project Plan document. It shall define iterations, the assignment of Use Cases to people. The ATCS Project Plan shall comply with the milestones defined in the ATS Global Project Plan [RDV04]. The iterations shall fit within these milestones.

The planning for the development of the ATCS software foresees the following main stages: Preliminary design. T0=0 This stage is closed with the Preliminary Design Review and provides the following deliverables: An updated issue of the AT Control Software Requirements Specification [ AD22 ]. In this revised document all Use Cases have to be assigned to a specific package, Collaboration Cases to capture the interrelations between package are identified and all the Use Case courses are refined based on the preliminary design. Issue 1.0 of this Package Design Description Interface Control Documents (ICD) for all the interfaces between the ATCS and external systems. In particular a revised issue of the ICD with Electro-Mechanical Hardware [ AD25 ]. A detailed planning document, with Gannt diagram of the foreseen activities package by package and dates assigned to the project milestones. Software Design and prototype development. T1=T0+8m This stage is closed with the Final Design Review and includes the development of prototypes for the most critical packages and an extensive test on a hardware prototype. The HW test bench must be built in parallel to the development of the prototype and must include a STRAP system, that is the most critical component. It is expected to have the prototype available for at least one month before FDR. The following deliverables will be provided for FDR: An updated issue of the AT Control Software Requirements Specification [AD22 ]. In this revised document all Use and Collaboration Cases have to be refined based on the detailed package design and assigned to a specific release. Issue 2.0 of this System Design Description Design Description documents for all the new or extensively modified VLT TCS packages. Design notes for the VLT TCS packages not modified. Refined Interface Control Documents (ICD). Updated planning document. System prototype, with templates for all packages and an implementation of the critical packages. The prototype must be able to demonstrate the correctness of the proposed design, based on the execution of the most important Use Cases. In particular the Field Stabilization system must be implemented to prove the concepts on which the interaction with the FSS and the FSS Translation Stage are based. Implementation of Release 1.0. T2 = T1+12m This stage is closed with the release of the first integrated ATCS and provides the following deliverables: ATCS part 1 implementing all Use and Collaboration Cases identified in the planning available at FDR. Modular and integration test reports Updated ATCS online documentation Preliminary software user manual (operator manuals will have to be developed as part of the commissioning phase). Implementation of Release 2.0. T3=T2+6m. This stage is closed with the release of the final integrated ATCS and provides the following deliverables: ATCS part 2 implementing all Use and Collaboration Cases not implemented with Release 1.0. Modular and integration test reports Updated ATCS online documentation Final software user manual. Will contain TCS part 1 with full functionality, and additionally the interface library for star catalogues access, and the TCS interface in simulation mode. Release 3.0. It will consist of the complete TCS software. After FDR, all the official documentation concerning design and coding will be kept up to date in the ATCS online documentation repository. This will reduce the risk information duplication in many paper documents and of information obsolescence. It is assumed that the HW prototype will be integrated with the VLT Control Model and that will be available during the whole development and integration period to be used as development and test platform.

Software Validation and Verification

The VLT Software Management Plan [AD01], $ 4.3.2, describes the verification and validation matters.

Each ATCS software modules that are the constituents of each package will include an automatic modular test procedure to verify the whole functionality of the module itself and of the package. A description of the test SW, as well as test plan, will be provided in a separate document. The test procedures are done according to the Guide for the Preparation of Software Test Documentation [AD01]

The complete ATCS system will include an automated integration test procedure to validate the whole system.

All testing is based on the Use Cases, that are the baseline to certify compliance of the system with the requirements.

At package level there will be at least one automatic test per each Use and Collaboration Case assigned to that package. All other packages are at this level replaced by dummies that emulate the corresponding interfaces. Whenever possible and convenient, there will be also automatic functional tests at the level of the single classes as part of the software modules in the package, testing systematically all methods.

At integration level, the same Use Cases will be used to develop automatic integration test procedures, where the whole system is tested, possibly with the real hardware or with simulated hardware when necessary.

Particular attention will have to be paid in the testing of user interfaces, up to now a critical component due to inherent testability difficulties. Whenever possible automatic tests will be developed. In all other cases, written test procedure to be executed by a human operator will be provided.

Whenever compatible with other activities assigned in the VLT planning to the personnel involved in the development of the ATCS SW, the development of the test SW for a module and the tests themselves will be carried out by somebody else than the developer of the module itself.

Last modified: Mon Jun 18 08:37:40 UTC 2001