NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > SddManual
   Changes | Index | Contents | Search | Statistics | Go

GB Software Development Division Manual

General Information

General information for the Software Development Division can be found on the Software web. Information specifically pertinent to members of the SDD can be found on the DashBoard.

Development Cycle

A development cycle is a six-week period of time within which selected Modification Requests are designed, implemented, tested, and released with a software product. The selected Modification Requests are agreed upon prior to the beginning of a development cycle; new requests must wait for the beginning of the next cycle unless they correct critical failures of a software product. The requests for each development cycle are contained in the Plan of Record (POR).

The creation of a Plan of Record is the first step in initiating a development cycle, which is the heartbeat of M&C maintenance. The Software Development Division determines its workload via a quarterly planning meeting attended by all project managers and division heads; the outcome of the quarterly planning meeting forms the basis for two development cycles. The quarterly planning meeting is part of the Green Bank planning process, which encompasses resource allocation, WBS management, and project management for all Green Bank projects (internal and external). The quarterly planning meeting negotiation process consists of the project managers and division heads determining which activities are most important and most aligned with NRAO's strategic goals; then the attendees divide the staff effort available through the Software Development Division (as well as all the other divisions) amongst these activities. The projects are the primary drivers for software development, so the Software Development Division merely participates in the discussions in order to give work effort estimates and manage expectations. The most current Plan of Record is always available on the Software web.

Activities under consideration for a given Plan of Record should be completed prior to the quarterly planning meeting and a finalized Plan of Record appears immediately after the quarterly planning meeting.

Once the Plan of Record is finalized, the Software Development Division meets internally to discuss the upcoming development cycle and to review the leaders to each Modification Request. Please note that leaders do not necessary implement the request alone; they are merely responsible for ensuring that the request is completed on schedule with the resources available. Occasionally, a request cannot be completed as scheduled (e.g. due to extensive operational support). The fate of this request depends on the priority of the request and the situation. It is important to notify the head of the Software Development Division (AmyShelton) and sponsor as early as possible when problems arise so any possible impacts can be minimized and expectations altered. Unless the request is extremely critical, it will probably be included in the Plan of Record for the next development cycle. Leaders need to be in contact with the sponsor of the request throughout the duration of the development cycle in order to ensure the work performed satisfies the sponsor's needs.

The Software Development Division meets each morning at 9am (10am in the basement conference room on Mondays) in the Library for a short, informal discussion of the observing issues discovered in the last 24 hours as well as issues with the current Plan of Record. Additionally, the Software Development Division meets biweekly to formally discuss the current Plan of Record in its entirety and upcoming end of cycle software system testing as well as any other items of interest to the group. The agenda for the biweekly meeting is located at: SDDIssuesAgenda.

Project Charters

At the GBT, we tackle large to medium scale efforts by organizing a project. The ProjectPlanningProcessDetails outlines how we organize projects and our project planning schedule. ProjectInitiationAndDefinition is the first step. Periodically, projects may be subject to ProjectReviews. A small project may be executed on the basis of the ProjectCharter, without additional review. Medium and Large projects will be expected to go though a sequence of reviews, although this may be more or less informal for medium-sized projects.

Generally, a number of ModificationRequests will be generated as part of a ProjectCharter. The intention is to break down the larger problem into smaller, more easily-handled chunks of work.

Modification Requests (or MRs)

What is a Modification Request (MR)?

See ModificationRequest.

What is a sponsor?

See ModificationRequest.

What is a checker?

See ModificationRequest

Is there a template?

Yup! A Modification Request template is available at MrTemplate.

Routine Responsibilities (a.k.a. Being a Good Citizen)

Responding to Observing Reports

The leader of the 9am morning meetings should bring a copy of the latest observing reports (and Astrid reports) to the meeting for discussion. The leader is then responsible for translating SDD comments into a response to the requestor, or delegating the responsibility to another member.

Typical responses should look something like the following:

Issues which should be addressed, but cannot be addressed immediately should be entered into the bug tracking system.

Updating Your Status Via the Plan of Record

You should update your status at least once a week and ensure that the status reflected on the current Plan of Record is accurate as of noon each Thursday so that the Commissioning Meeting report may be written.

Cross Fertilization

We have weekly software lunches. The list of topics covered can be found at LunchTopics.

We have participated in NRAO-wide software conferences. The first was back in 1999 and covered real-time programming. The most recent was in 2006 and covered all software topics; an agenda for this conference can be found at https://wiki.nrao.edu/bin/view/Software/Conference2006. We hope to continue cross-fertilization through future interactions like this.

Recently, we conducted a TurboGears Tutorial for both Green Bank and Charlottesville computing and software development staff.

Please add other ideas for cross fertilization here.

Effort Tracking

You must submit a weekly accounting of the number of hours spent on each assigned MR/task from the POR.

For things like SDD Biweekly Meetings, interviews, 9am meetings, etc., group them all under "Administrative Overhead." For items like seminars, colloquia, software lunch, conferences, workshops, group them all under "Continuing Education." For software user support, please report it as "User Support." User support includes answering questions from observers as well as engineers regarding some aspect of the GBT software. For telescope operations support, please report it as "Operations Support." Operations support includes all work done to keep the GBT operating as scheduled. For items which benefit the code base, but aren't part of a scheduled task or operational support per se, group them all under "Preventive Maintenance." Sometimes user support and operations support morphs into preventive maintenance. Please use your best judgment when reporting your time or ask your supervisor when you are not sure. If you find something without a category and your really feel like it needs one, make one up and you and your supervisor can sort it out later. For the most part, administrative overhead is a good catch-all. However (for example) if you have 30 hours of administrative overhead and you aren't attending a conference, there might be a little bit of additional explanation due.

Keep the timekeeping at least at a 30 minute granularity. The main objective is to figure out how good our cycle planning estimates are when compared to reality. In the coming cycles, we will be adding more detail as needed.

Let's take Ray as an example. We'll say that his scheduled tasks are: (1) Attend Zpectrometer Meetings, (2) Test Zpectrometer Manager with UMd Hardware, (3) Write MR for Integration of the Zpectrometer into SDFITS and GBTIDL, (4) Implement Linux Quadrant Detector Manager, (5) Fix Faulty Self-Test in Spectrometer (background), and (6) Attend Software Conference. He'll have six basic tasks plus the two catch-all tasks (Administrative Overhead and Support) to which he can allocate time. Please use the task names from the POR when reporting time. So, his time report might look like:

Attend Zpectrometer Meetings: 1.75
Test Zpectrometer Manager with UMd Hardware: 0
Write MR for Integration of the Zpectrometer into SDFITS and GBTIDL: 16
Implement Linux Quadrant Detector Manager: 16
Attend Software Conference: 0
Administrative Overhead: 7.25 (interviewing)
Support: 0

In the example above, a parenthetical comment was added to Administrative Overhead just to give a rough pointer as to why the number seems large.

If you work on a task off of the POR, record the time spent on it even if it is not your assigned task. E.g. Bob talks to Paul about autoflagging in GBTIDL. Paul needs to log the time spent helping Bob to that MR. Please, please, please use the name of the item off of the POR when reporting your time. It makes the job of sorting through and consolidating times much easier when everyone uses the same terminology.

Items such as vacation, sick leave, voting time, etc. (as listed on your orange timecards) should also be separately reported in their own respective categories.

Finally, e-mail your weekly time report to the SDD Division Head on Fridays (or by Noon the next Monday).

Time Cards

Your time card is due on the last day shown on the time card. Please keep an accurate accounting of your time. Turn the signed time card into the SDD Division Head on the due date (preferably without being asked).

Reporting Leave

When you need to take leave (e.g. doctor's visit, vacation), please record your plans on the SddCalendar as soon as you know the date.

Vacation Policy

Note the dates of planned vacation time on the SddCalendar as soon as you know them. If two (or more) people have already signed up for the same date(s), please see AmyShelton to discuss your travel plans and obtain approval.

Products

M&C (Ygor)

The telescope control system used for the Robert C. Byrd Green Bank Telescope (GBT) consists of two pieces. The first piece is called Ygor, and is a generic control system. The second piece is specifically tailored to the GBT. Both pieces utilize object-oriented design and are implemented in C++ and together form the GBT M&C system.

The basic design of Ygor is simple. A radio telescope is defined as a laboratory rather than an instrument, i.e., it is a set of devices (of which the antenna is only one) which needs to be configured in novel ways to accomplish observations (or scans). Each device is an autonomous subsystem which can be fully configured prior to a scan through a finite set of control parameters in order to run the scan in coordination with other devices. For purposes of configuration and observing, each device requires no more than four interfaces (control, monitor, message/alarm, and data) which are identical for all devices. The same control interface for user-programs is also used to recursively build a tree of control modules whose root is a generic "scan coordinator." Any control module of the tree may be used to initiate a scan for the sub-tree under its control because each control module is derived from the same base class (called a Manager) and therefore inherits all of the control protocols required to coordinate and initiate a scan.

The piece of the GBT M&C system that is specific to the GBT takes the general objects made available by Ygor and specializes them for GBT devices (e.g. the Prime Focus Receiver, the Spectrometer, the IF Rack, etc.).

Because the goal of the NRAO is to provide observers with the maximum amount of observing time possible, it is important that all aspects of the telescope are working properly; this includes the GBT M&C system. Also it is expected that the GBT will be a state of the art instrument for years to come. Therefore, maintenance requirements for the GBT M&C system include the ability to correct problems and enact enhancement requests.

The Software Development Division is responsible for the maintenance of the GBT M&C system.

Product Manager

A Product Manager is responsible for the following aspects of managing ONE group of software applications which are released together:

Quality Assurance

Because the software development staff levels are low for the maintenance of the M&C system, quality assurance activities are performed by the maintainers in conjunction with the users. Therefore it is ultimately the responsibility of the Software Development Division to ensure that its practices and products are of high quality. The Software Development Division works closely with the users in a sponsor-developer relationship, each with its own responsibilities.

The Software Development Division assumes the developer role for the M&C system. They receive modification requests from users. Each modification request that is implemented is done in cooperation with a sponsor who champions the effort. Under almost all circumstances, the sponsor must be a member of the user community and not a developer. While implementing a modification request, the developer utilizes a variety of tools to develop a quality solution. These tools include pair programming, unit testing, integration testing, regression testing, and occasionally code walkthroughs.

Unit Testing

Unit testing consists of two components. The first component is automated tests that run nightly. The second component requires that a software engineer (other than the engineer(s) who implemented the modification request) test the affected system component in the operational environment. Generally, this operational environment makes use of real hardware, but could be performed in simulation. It is the responsibility of the software engineer assigned to a modification request to create the test plan for the second component of unit testing; ideally, this test plan is created before the modification request is designed and refined as more information becomes available or as requirements are modified. The sponsor of the modification request should also perform testing according to his or her own test plan, which may indeed be identical to the test plan utilized by the Software Development Division. After a modification request has passed unit testing, it is ready for integration testing.

Integration Testing

Integration testing involves testing all modification requests for a given release. It consists of one or more members of the Software Development Division running a new version of the M&C system as a whole in the operational environment and ensuring that the changes to individual components have not broken the operation of the overall system. Generally, this environment makes use of real hardware; one possible exception is the antenna, for which a good simulator is available. Integration testing is performed using observing scripts designed to exercise the majority of the M&C system. The same scripts are used each time integration testing is performed, with perhaps minor modifications to accomodate new or changed features. After a modification request has passed integration testing, it is ready for regression testing.

Integration testing notes can be found at the SoftwareReportCentral.

Regression Testing

Regression testing also involves testing all modification requests for a given release. It consists of a member of the Scientific Services Division (currently this is JimBraatz) conducting astronomical observations using a new release. This type of testing uses real hardware including the antenna. Regression testing is performed using observing scripts designed to exercise the majority of the M&C system. The same scripts are used each time regression testing is performed, with perhaps minor modifications to accomodate new or changed features. The data collected as a result of regression tests are reduced and compared to reference data in order to determine the quality of the new release. Once a new release has passed regression testing, it is released as the new production version of M&C.

Regression testing notes can be found at the SoftwareReportCentral.

Software Configuration Management

Currently, only the code for the M&C system is under revision control. However, as more items (such as procedures and other important documents) are placed on the Green Bank Wiki, its built-in revision control system can be used for this purpose. CVS is the revision control system used for the M&C system.

A new version of M&C is released at the end of most development cycles. Release notes can be found at the SoftwareReportCentral.

Performance Evaluation aPpraisal (PEPs)

The official policy on PEPs can be found at http://www.nrao.edu/administration/personnel_office/employeeappraisal.shtml.

In summary, the PEP process involves setting goals for the upcoming year and then evaulating yourself on how you did. The supervisor also evaluates the employee's performance. Officially, they do not tie in to salary review. The supervisor may choose to use the PEP as one of many tools in the salary review process if they so choose. If goals change during the year, we can modify the set goals as needed as often as needed.

Everyone's PEP goals are available online at IndividualGoals2007. Please read over this periodically to make sure that you are pursuing (and being given an opportunity to persue) your goals. If needed, the employee and the supervisor can adjust goals as needed throughout the year.

In the SDD, each person has three types of goals: personal, group, and project. Personal goals should be aimed at bettering yourself as a software engineer. Group goals should be aimed at bettering our group in some way, e.g. teaching everyone a new skill, making our software development process better, improving our documentation. Project goals are work items tied to one of the GBT projects to which you are assigned throughout the year.

Topic SddManual . { Edit | Attach | Ref-By | Printable | Diffs | r1.26 | > | r1.25 | > | r1.24 | More }
Revision r1.26 - 21 Apr 2008 - 15:33 GMT - AmyShelton Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.