Discussion Session on various ASP Procedures

Agenda

Feedback from design reviews and ramp-ups (40', Steve Fisher)
Accepting external software - what do we need to think about? (15', Julius Hrivnac)
Testing - proposed procedures (20', Rosemary Candlin)
Using the software repository (15', Chris Onions)
Maintenance (15', Helge Meinhard)
Documentation in general (15', Steve Fisher)

Background Information

ASP procedures

Now that more people are being affected by the proposed ASP procedures, it is a good time to look at ways in which the defined procedures can be improved, and to make suggestions for procedures which have not yet been defined, but which are beginning to be needed by developers.

We want the ASP to be as clear and helpful as possible, so we need feedback from everybody who has been involved, or is likely to be involved, in software development.

It is suggested that we have a discussion session in which the following topics are briefly introduced by various speakers, and that we then set up small (2 or 3 people) working groups to make concrete proposals and present them at the end of the week.

1. Reviews and Ramp-ups

These have been grouped together, since some of the same questions arise in both cases.

We should now have a lot more feedback about design reviews and it would be useful to hear the opinions of both the reviewers and the reviewed about how useful they were, and whether they could be improved. In particular we should look at the following:

Are the conditions for entering a review or ramp-up appropriate, and are they being adhered to?
Are the Design Report format and content satisfactory?
Should there be any changes in the way in which a review is conducted (eg time scales, number of participants)?
Are we clear about what happens in the case of (a) satisfactory (b) unsatisfactory review or evalauation?

Areas where ASP procedures have not yet been defined

External Software

The problem may have certain similarities with those of evaluation for ramp-up, Externak software is likely to be increasingly important. We should define the criteria for acceptance of an external package (which might cover such aspects as: compliance with the requirements, stability, cost, maintenance).

Testing

We had a discussion meeting at the last software week. The proposed entry in the ASP is based on suggestions made then. These will be provisional incorporated in the ASP. They will be briefly presented again here..

The Software Repository

We have a technical report on the CVS-based repository but we need to define how it is to be used (eg: when should you check something in, what do you have to provide, what does the software librarian do, how do you get code out...?

There is a strong interaction between the procedures for using the repository, those for code reviews, those for testing and those for maintenence. We need to be sure that all these activities mesh together.

Maintenance

Under this heading come things like:

How is GNATS to be used for reporting?
What is the chain of responsibility for fixing bugs, reporting what has been done, and dealing with any knock-on effects (eg due to a fault at the design stage)
Gathering fault statistics.

Textual Documentation

We haven't formalised the question of whether there are different types of document, with different levels of preparation, lifetimes and presentation. A lot of interesting discussion goes on by email, but looking through an email archive is pretty daunting. Information presented on the Web is held in anumber of different people's directories. Do we want to try and bring some order into this, so that our documentation would be more useful for newcomers to see what is going on?