D R A F T - National Solar Observatory

D R A F T Project Documentation Document TN-0131

Draft 1

Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719 Phone 520-318-8102 [email protected] http://atst.nso.edu Fax 520-318-8500

Software Development Methodology for the

ATST Instrumentation Team

A. Ferayorni Instrumentation Group

July 2010

D R A F T Software Development Methodology

TN-0131 Draft 1 Page ii

REVISION SUMMARY:

1. Date: July 2010 Revision: Draft 1 Changes: Original version

2. Date: Revision: Changes:

3.


TN-0131 Draft 1 Page iii

Table of Contents

1. INTRODUCTION ................................................................................................... 1 2. DEFINITIONS ........................................................................................................ 2 3. SURVEY OF METHODOLOGIES ......................................................................... 3 3.1 WATERFALL ............................................................................................................ 3 3.1.1 Overview ........................................................................................................................ 3 3.2 FEATURES .............................................................................................................. 3 3.2.1 Analysis for ATST ........................................................................................................... 4 3.3 SPIRAL ................................................................................................................... 4 3.3.1 Overview ........................................................................................................................ 4 3.3.2 Features ......................................................................................................................... 4 3.3.3 Analysis for ATST ........................................................................................................... 5 3.4 CLEANROOM ........................................................................................................... 5 3.4.1 Overview ........................................................................................................................ 5 3.4.2 Features ......................................................................................................................... 5 3.4.3 Analysis for ATST ........................................................................................................... 6 3.5 SCRUM................................................................................................................... 6 3.5.1 Overview ........................................................................................................................ 6 3.5.2 Features ......................................................................................................................... 6 3.5.3 Analysis for ATST ........................................................................................................... 8 3.6 EXTREME PROGRAMMING (XP) ................................................................................ 9 3.6.1 Overview ........................................................................................................................ 9 3.6.2 Features ......................................................................................................................... 9 3.6.3 Analysis for ATST ..........................................................................................................10 4. RECOMMENDATION .......................................................................................... 11 4.1 PROJECT LEVEL PRACTICES .................................................................................. 11 4.1.1 Overview .......................................................................................................................11 4.1.2 ATST Implementation ....................................................................................................11 4.2 ENGINEERING PRACTICES ...................................................................................... 13 5. REFERENCES .................................................................................................... 15


TN-0131 Draft 1 Page 1 of 15

1. INTRODUCTION

The purpose of this technical note is to capture the research, discussion, and decisions surrounding the

selection of a software development methodology for the ATST instrumentation team. When reviewing a

methodology we avoid getting caught up in whether we can check off all the rules. The goal is to survey

the methodologies and understand the concepts behind their key elements and determine what benefits we

can gain from implementing them. This approach allows us to select those that work, modifying them if

needed for ATST without losing track of the concept behind it.

This document is divided into many sections. Section 1 will provide an introduction to this document as

well as provide some background information on the projects being undertaken by the ATST

instrumentation team. Section 2 will provide definitions for terms commonly used throughout the

document. Section 3 will present the results of our survey of different software development

methodologies. For each methodology we will provide an overview and description of features so that

the reader can understand the key elements and how they are used. We will also document our analysis as

the positives and negatives of each approach as applied to the ATST effort. Finally, in Section 4 we will

document our recommendation of practices to be used by the ATST instrumentation team as well as

provide an explanation of how they will be implemented.

The ATST instrumentation team is responsible for delivering the following:

Visual Broadband Imager (VBI)

VBI will record images from the ATST telescope at the highest possible spatial and temporal

resolution at a number of specified wavelengths in the range from 390 nm to 860 nm.

Polarimetry Analysis and Calibration (PA&C)

The PA&C is responsible for providing a facility service to operators and instruments for

polarization and calibration activities.

Both of these projects are critical to the success of the ATST as a whole. As such, we are conducting this

survey to ensure that we define and follow a software development approach that will provide project and

engineering tools to help us be successful. In addition we look to set an example for other instrument

developers so that they too may benefit from a similar approach.



2. DEFINITIONS

ATST Advanced Technology Solar Telescope

CDD Critical Design Document

CDR Critical Design Review

CRD Critical Design Requirements

CSF Common Services Framework

DRD Design Requirements Document

GUI Graphical User Interface

ICS Instrument Control System

ISRD Instrument Science Requirements Document

JES Java Engineering Screens

PA&C Polarimetry Analysis and Calibration

PDD Preliminary Design Document

PDR Preliminary Design Review

VBI Visual Broadband Imager

XP Extreme Programming, an Agile software development methodology.



3. SURVEY OF METHODOLOGIES

3.1 WATERFALL

3.1.1 Overview

The waterfall methodology gets its name from the sequential flow of project phases: a phase cannot being

until the previous has been completed. The waterfall methodology has its origins in construction and

manufacturing. In those domains it works relatively well since once something is built (a building, a car)

it is very difficult or costly to change the requirements. In the early days of computing this methodology

was adapted due to familiarity and has continues to see use even today in one form or another.

3.2 FEATURES

The waterfall model consists of sequential project phases. The typical phases are: Requirements, Design,

Implementation, Verification, and Maintenance. These phases may vary as some teams many prefer more

granular phases. For example some teams may break Requirements up into Envisioning, Requirements,

and Planning.

The waterfall model is primarily document driven. That is, each phase of the model produces a document

as a deliverable. The deliverable for each phase is signed off by the team and then the next phase can

begin. For example, at the end of the requirements phase a formal requirements document is delivered

that has been signed off by the team. Similarly, at the end of the design phase the development team

delivers a formal design document that is reviewed and sign off by the team.

Proponents of the waterfall method state that it provides benefits such as:

Comprehensive documentation allowing for impact analysis of potential changes

Better coordination of large geographically distributed teams

More accurate budgeting

Less overall time commitment from subject matter experts (SME)

In the strictest sense, the waterfall model states that there is no going back once a phase has been

completed and signed off on. With this approach great care must be taken at each phase to ensure

completeness and consensus before sign off and transition to the next phase. More recent adaptations are

far more flexible and involve overlap of project phases (Sashimi), feedback loops, and multiple waterfall

iterations.



3.2.1 Analysis for ATST

The ATST instrumentation projects follow a waterfall model to some extent at the higher levels due to the

reviews mandated by our funding agency. For example on the VBI project the flow starts with science

requirements (SPEC-001) to ISRD (SPEC-0054) to DRD (SPEC-0090) to PDD (SPEC-0089) and on to

construction requirements and design (CRD and CDD).

Despite the waterfall-like model being followed at the ATST project level there is a need for the software

development effort to remain flexible to some extent as the project progresses. The main concerns are 1)

the fact that we are developing on new frameworks for both control systems (CSF/ICS) and GUIs (JES)

and 2) changing science and engineering requirements as interest in ATST grows. In order to address

these risks a more adaptable methodology will be needed.

3.3 SPIRAL

3.3.1 Overview

The spiral methodology for software development was introduced in the 1980s and was one of the first to

incorporate the concept of iterative development cycles. The main goal of the spiral model is to allow the

development team to produce releases more frequently than would be possible with a waterfall like

methodology. This is accomplished by conducting multiple iterations of requirements, design, develop,

test, and release. After each iteration the released product can be evaluated by the clients and used to

drive the direction of the next iteration.

3.3.2 Features

The Spiral model builds heavily on the concepts of risk analysis and prototyping. All software projects

are susceptible to many risks such as exceeding budget, changed requirements, loss of resources,

technology change, etc. In the Spiral model risk-analysis is performed at the start of each iteration and

risks are mitigated through use of prototypes and other means.

Planning starts with defining an Objective, any Constraints the team is faced with, and identifying the

solution Alternatives. Risk analysis is then performed to determine what Risks there are for each

alternative and what Risk Resolutions can be done to mitigate them. The team then selects an alternative

and defines the Plans for development in the next iteration and what Commitments are required to meet

those plans.

As shown in the diagram above, early iterations are typically based on conceptual designs and thus

generate prototypical products whereas later iterations produce products that are production ready. One



of the key benefits of this approach is the ability to quickly get a product into the customers hands and

allow for changes to requirements as the product evolves.


An iterative development cycle like the one proposed in the Spiral model is of high interest to the ATST

instrumentation team. It is crucial that prototypes for both the control systems and user interfaces be built

and analyzed quickly since the CSF/ICS framework is new and we are the first team to utilize it. In

addition, excitement over the ATST project as of late has resulted in changing requirements; a process

that is expected to continue over the next year.

On the other hand many requirements of the ATST instrumentation are well understood at this time. In

order to produce prototypes quickly a sub-set of functionality will have to be selected for the early

iterations. Additional functionality can be added as the users and development team become more

comfortable with the resulting products.

3.4 CLEANROOM

3.4.1 Overview

The cleanroom software development methodology arose from the need to deliver software that is defect

free and reliable. This is especially important when defects are detrimental such as in medical and safety

critical systems. One of the core concepts of the cleanroom method is to prevent defects (design-in

quality) rather than remove defects (test-in quality). Defect prevention is accomplished through use of

formal methods that verify the design correctly meets the specification.

3.4.2 Features

With the cleanroom approach the Box Structure Method is used to delineate the system during

requirements and specification. Box structures map inputs and input histories into outputs. First, the

external behavior of a system is mapped out in all possible user observable input/output scenarios using

Black Box diagrams. Next, State Box diagrams are used to map current input/current state into

output/new state. Finally, Clear Box diagrams are derived from State Box diagrams and define the

procedures required to implement the State Box transition.

Another key feature of the cleanroom approach is the use of incremental development. Each increment

delivers a subset of the required functionality which can be evaluated to determine quality. In addition,

user feedback and process improvement opportunities can be identified and incorporated into the next

increment. The cleanroom process also emphasizes the use of peer code reviews instead of (or commonly

implemented as “in addition to”) unit testing. These code reviews are used to verify that code meets the

specifications.



Testing is done by developing usage models, a test plan, and statistical test cases. The usage model

defines a set of possible state traversals (uses) of the system for a particular class of users and

environments. Test cases are generated statistically from the usage models based on the probability that a

particular state traversal will occur.


For the ATST instrumentation team the idea of “defect-free” software is intriguing especially for system

critical components such as the PA&C. However concerns with the cleanroom approach include: lack of

team experience, learning curve, and lack of automated tools.

The Cleanroom methodology does offer some key points that are of interest to ATST. The user of peer

code reviews will be vital to the success of the ATST software effort. The instrumentation team has

already identified a risk due to having a single developer writing software. It is important that members

of all ATST software teams work cross-functionally to help one another in design reviews, code reviews,

and testing.

Another element of the Cleanroom method that may benefit ATST is the development of usage models

and statistical test cases. During testing it will be important to identify all the uses of each system and

ensure that we test as many as possible. Since the set of possible state traversals is quite large,

statistically driven test cases can help ensure we at least test the most probable cases.

3.5 SCRUM

3.5.1 Overview

Scrum is one of the more popular Agile software development methodologies. It provides a disciplined

set of project management processes that are true to the key elements of Agile software development:

iterate, adapt, and communicate. It aims to be applicable to any domain and as such does not specify any

engineering techniques specific to the software.

3.5.2 Features



At the heart of the Scrum methodology is the concept of the Scrum team. The Scrum team consists of the

following roles:

Product Owner: Person who represents the stakeholders

Scrum Master: Person who maintains the Scrum processes

Team: Group of one or more people who design, develop, and test the software

The Scrum team kicks off a project by documenting all requirements and “wish list” items into a Product

Backlog. The Scrum team then prioritizes, sizes, and estimates items in the Product Backlog in order to

define a Release Backlog, which is a list of the items that will go into the next release.

Once a Release Backlog is set the Team starts the process of Sprint Planning. During this process the

team defines a Sprint Backlog which consists of 4-12 items from the Release Backlog that can be

developed in a 1-4 week time span. Once planned, the design, development, and test for a Sprint will

begin. Upon completion of a Sprint the team performs a Sprint Review in order to identify opportunities

to improve the Sprint process.

Other key components of Scrum include the Daily Scrum, which are daily stand up meetings to review

Sprint progress and facilitate discussions. Reporting tools like the Burndown Chart (see figure below)

allow the team to track Sprint and Release progress daily by looking at remaining work. Bugs identified

during Sprint testing or post-Sprint product evaluation are logged in a Defect Backlog. Sprints cannot be

considered complete until all related defects are closed. The Scrum team may opt to create a Sprint for

the sole purpose of resolving items from the Defect Backlog.




The Scrum methodology has many attractive elements that may provide benefits for the ATST

Instrumentation team. The iterative model of planning supported by the Product Backlog, Release

Backlog, and Sprints would allow the team to quickly develop a subset of key features. This approach

would allow our team to more quickly give feedback on the CSF/ICS framework and adjust requirements

and/or design accordingly. The iterative model would also allow us to develop well defined observing

modes up front and push off the more vague modes until requirements are more concrete. Finally, this

model is well suited for GUI development and will allow software for the engineering and quick look

GUIs to evolve based on user feedback.

Communication and team cohesiveness is another attractive feature of Scrum. It is not uncommon for

project teams to spend most of their time apart, coming together every few weeks to provide status

updates. That sort of communication model introduces significant risk since problems and questions may

go un-discussed for weeks. The Scrum model of daily meetings facilitates open and frequent

communication that leads to a more focused and committed team.

The ATST Instrumentation team currently consists of a few scientists, one instrument engineer, and one

software engineer. Some of the concerns with Scrum in this environment is whether it can be adapted for

such a small team. In particular, the software development team consists of one person. As a result

elements such as cross-functional roles in the team may not be applicable. However there may be

opportunities to reach out to other project teams such as software engineers at the Dunn Solar Telescope,

ATST camera systems software team, or members of the ATST software team in Tucson, AZ. One idea

is to have members of these teams perform code reviews together, testing for one another, and co-locate

when struggling with difficult design or coding issues.

In addition, we need to look at how Scrum can be integrated in with the mandated waterfall like phases of

the overall ATST project. The ATST instrumentation projects (VBI and PA&C) follow a waterfall model

outlined by the Instrument Development Plan (SPEC-0087). Other observatories such as Gemini and

ALMA faced similar issues and adapted by starting Sprints/Releases between the PDR and CDR [ref].



3.6 EXTREME PROGRAMMING (XP)

3.6.1 Overview

XP is an Agile methodology that covers a broad scope of activities in the software development lifecycle.

Much like Scrum it provides an iterative project planning model (“Planning Game”) with frequent

releases and the ability to adapt to change. However it also provides software engineering techniques that

can be used during different project phases. This section will review some of those techniques and

discuss how they might be implemented for ATST.

3.6.2 Features

The diagram below shows the key elements of XP at different levels of the project.

The red outer ring depicts the project level activities that involve the clients and the development team.

Whole Team refers to establishing respect and open communication between all project team members.

Planning Game is the approach to selecting features for each release and tracking the progress of the

team. Small Releases ensure that the iterative development cycles remain short and deliver the selected

product features to the customer quickly. Feedback and acceptance of each product release is provided

through Customer Tests.

The green middle ring lists key activities that help the development team remain efficient. Collective

Ownership refers to everyone on the development team being accountable for the software product, as

opposed to a “silo” based approach. Coding Standards ensure that all developers write code using a

consistent style. Continuous Integration enforces automated build and unit/regression testing every time

code changes are checked in. A Metaphor provides a clear vision for the team on what they are building.

To avoid team burnout, emphasis is placed on maintaining a Sustainable Pace.



The innermost blue ring lists the core practices that the development team will use to write code.

Keeping a Simple Design is at the forefront of these practices and aims to avoid complex designs that lead

to increased development time. Pair Programming is used to reduce development time by having two or

more programmers write code together. Test Driven Development involves writing a unit test first and

then writing the code to pass the test. This approach has been shown to produce simple, well thought out

code and saves time versus writing test cases after the fact. In order for the software to adjust to changing

requirements the practice of Refactoring is applied. This involves frequent review of the design to

identify elements that should be modified or removed due to the evolution of the system.


Much like Scrum, XP pushes for an iterative development lifecycle consisting of frequent releases. This

approach is desirable for the ATST instrumentation team since it will allow us to 1) quickly evaluate the

CSF/ICS framework, 2) obtain frequent feedback from users of the released product, and 3) adapt to

changing requirements.

Many of the development practices are also of interest to the ATST team. Coding Standards and Simple

Design will be important as the ATST team sets the standard for how instrument software will be

developed on the CSF/ICS framework. Continuous Integration is desirable since it will ensure code

changes are regression tested and bug fixes are quickly made available to users and other software teams.

Test Driven Development is also of interest in an effort to simplify design, provide good test coverage,

and reduce the number of software defects.



4. RECOMMENDATION

NOTE: As of July 19, 2010 the ATST instrumentation team has not held a group discussion to agree on

the final approach. Therefore the recommended practices below are based solely on the input from the

software developer.

Each of the methodologies surveyed showed strengths and weaknesses with regard to how it can be used

by the ATST instrumentation team. No single methodology was a perfect fit out of the box and thus a

hybrid model is the ideal approach. Defining a hybrid model requires input from the team on what

elements they feel will work best, and what elements need to be modified or left out completely.

There is also a level of separation between the project level practices (planning, tracking, communication,

etc.) and software engineering practices (coding standards, peer reviews, test driven development, etc.).

For the project level practices it is best to select one methodology and modify it as needed to work for our

project. This will ensure we can follow a well-defined model, as opposed to an ad-hoc model made up of

many different project level practices from different methodologies. However for the software

engineering practices it is desirable to pick and choose elements from different methodologies. This

approach is acceptable since these practices are less coupled to one another than project level practices.

The following sections will discuss our recommendations for project and engineering practices.

4.1 PROJECT LEVEL PRACTICES

4.1.1 Overview

An iterative model is well suited for the ATST instrumentation team. The Scrum methodology is the

most attractive of the iterative models due to the following strengths:

Frequent Releases - The ATST instrumentation team will focus on providing early releases quickly in an

effort to provide feedback on the CSF/ICS, JES, and motion controller frameworks. The team also

expects some degree of requirements flux as the ATST project moves forward and based on feedback as

the instrument systems evolve.

Team / Communication - Frequent and open communication is essential for the success of the ATST

project. In addition, some of the team members work remotely and to bridge that gap the team needs to

establish good communication techniques.

Use of an iterative model like Scrum does present some risks. Although Scrum supports adaptability to

changing requirements, we do not want the project to run on indefinitely due to constant change in

requirements. Therefore we are proposing that requirements change will be allowed only up until the

critical design review (CDR). We need to ensure that once we pass the CDR we are not introducing any

new requirements that have a significant impact on design and project timeline. Similarly the release

schedule will be firmed after the CDR to ensure that other ATST staff can know when to expect certain

functionality to be released.

4.1.2 ATST Implementation

The ATST instrumentation team will use a modified version of Scrum that is adapted to the high level

ATST project milestones (PDR, CDR, etc). The diagram below shows how the Scrum process will be

used in conjunction with the ATST project milestones. The DRD will be used to create the initial Product

Backlog. We will then execute a series of Scrum managed early prototype releases leading up to the

creation of the PDD and acceptance at the PDR. After the PDR we conduct another set of Scrum



managed releases producing more production like output. The results of these releases will serve as input

to the CDD. After acceptance of the CDD at the CDR the team will define a final set of releases that will

be carried out for product completion.

PDR CDR

Final Release

Backlog

Final

Release

Planning

Scrum

Prototype

Releases

DRD

Final

Scrum

Releases

Product

Backlog

Release Planning

Release

Backlog

PDD

Release Planning Scrum

Releases

Release

Backlog

CDD

The ATST instrumentation team will utilize several elements of the Scrum process and modify them as

needed to suit the dynamics of our team and the project. The following is a list of those elements with an

explanation of why they were chosen and how they will be implemented for our team.

Scrum Team

Due to the small size of the ATST instrumentation team the Scrum team will need to be modified

slightly. The Product Owner will be the lead scientist for the instrument (i.e. Friedrich for the

VBI, David for the PA&C). The Scrum Master will be the project manager (i.e. Bill McBride for

the VBI and PA&C). The Team will be the instrument software developer (i.e. Andrew

Ferayorni) but also include members of other NSO software teams (i.e. DST, ATST-Tucson).

Members of other NSO software teams will provide support via problem solving, design/code

reviews, and independent testing. These members will be optional participants in the Daily

Scrum meetings, but may be required to join for certain discussions.

Product Backlog

The Product Backlog will consist of all software requirements from the DRD plus any additional

“wish list” items. New items can be added as the project progresses but will be restricted after

the critical design review (CDR).

Release Backlog

The Release Backlog will be defined for each iteration. The frequency of releases can be

determined by the team up until the critical design review (CDR). After the CDR the final release

schedule should be finalized and not changed. The initial Release Backlog should contain a

subset of key features for the control system and engineering interface. This will allow the team

to quickly obtain a working product that can be used to evaluate the CSF/ICS and JES

frameworks. Subsequent releases can add additional observing modes and GUI features as well

as deliverables for the quick look display and pipeline data processing.

Sprint Planning / Sprint Backlog / Sprint Review

The Sprint will be used to break the release up into smaller deliverables on the scale of 2-4

weeks. The first Sprints should be short and aim to provide a prototype that supports one or two

observing modes. This will allow the team to evaluate the CSF/ICS framework and motion

controller solution. Feedback from users and the development team during the Sprint Review

will allow for adjustments before the next Sprint. Subsequent Sprints should add additional GUI

features and observing modes working towards completion of the Release Backlog.



Daily Scrum

One of the key benefits of the Scrum methodology is the emphasis on team cohesiveness and

communication. The use of a Daily Scrum meeting will help facilitate open communication and

build a sense of commitment to the project among team members. It is often difficult for team

members to adjust to this initially and some may see it as unnecessary meetings. Therefore it is

key that we keep the daily meetings short and allow the team to decide if the frequency should be

adjusted based on the state of the project.

Burndown Chart

Accurate and frequent progress tracking is an essential part of a successful project. Using an

intuitive means of progress communication helps simplify that process. The Burndown Chart

provides a daily view of the software development progress in an easy to understand format. Use

of this chart will help the project team react more quickly to issues and make adjustments as

needed.

The diagram below shows the steps of the Scrum process that will be used to manage each release.

Sprints are shown with the engineering practices that have been selected to support the design,

development, and testing effort.

4.2 ENGINEERING PRACTICES

Several methodologies we reviewed presented engineering practices that can provide benefit to the ATST

instrumentation team. The following is a list of those elements with an explanation of how the team will

implement them.

Simple Design

One of the goals of the ATST software team is to provide a framework to instrument developers

that includes common services (CSF), building blocks for motion and detector control (ICS), and

a GUI builder (JES). This helps promote system quality attributes such as re-usability,

maintenance, and integrability. The ATST instrumentation team will be the first to utilize this

framework and other instrument developers will look to follow our example. Use of the

framework coupled with simple design of extensions to the framework will set a good example

for other teams to follow.



Coding Standards

The ATST instrument team will follow the coding standards established for ATST. In addition,

new standards may be proposed as components are build using the CSF/ICS framework. For

example, standards may arise for writing scripts in Jython, defining instrument properties, and

interfacing with approved motion controllers. Any new standards will be reviewed and approved

by the ATST software team and published along with existing standards.

Continuous Integration

The use of Continuous Integration (CI) will help the ATST instrumentation team ensure that code

changes are only committed if they pass all regression tests. It will also promote the quick release

of bug fixes and releases to a test environment where users and other software teams can evaluate

it. Cruise Control is a popular CI product that integrates well with CVS, JUnit, and other tools

already in use by the ATST software team.

Test Driven Development

The approach of test driven development (TDD) supports many of the goals set forth by the

ATST instrumentation team. It will help maintain a simple design, produce thorough unit test

coverage, and reduce the number of software defects. The software developers will take

responsibility for using this approach and provide a post-project report on its effectiveness.

Peer Reviews

One of the risks identified by the ATST instrument team is the fact that only one software

developer is on the team. This exemplifies the need for all instrument software to be peer

reviewed by software engineers outside the team. We will recruit the services of the DST and

ATST-Tucson teams for this purpose. Peer reviews will be done as part of the design and

development phases of any project iteration (i.e. Sprint in Scrum).

Usage Model / Statistical Test Cases

Although most usage models for the ATST instrumentation will follow defined observing modes,

some of the modes are less structured and allow for many possible usage scenarios. In addition

there may be usage models unique to the state of the rest of the ATST systems that need test

coverage. To help promote good test coverage we propose the Cleanroom approach of Usage

Models and Statistical Test Cases.

Cross-Functional Teams

The ATST instrumentation team will work cross-functionally with the DST and ATST-Tucson

teams during the project. Leveraging the experience of the DST software team will prove

extremely valuable in our instrument development effort. Similarly, the ATST-Tucson team has

an intimate knowledge of the CSF, ICS, and JES frameworks and can therefore provide expert

guidance and feedback. Our hope is to involve the other team members in problem solving,

design reviews, code reviews, and independent testing. The expectation is that we would provide

the same services for their projects as well.



5. REFERENCES

Development Methodologies Compared http://www.ncycles.com/e_whi_Methodologies.htm SEI Cleanroom Software Engineering http://www.sei.cmu.edu/reports/96tr022.pdf An Industrial Application of Cleanroom Software Engineering http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.102.1181&rep=rep1&type=pdf Trends in Software for Large Astronomy Projects http://accelconf.web.cern.ch/accelconf/ica07/PAPERS/MOAB03.PDF Software Engineering: The Spiral Model http://courses.cs.vt.edu/csonline/SE/Lessons/Spiral/index.html An Overview of Scrum for Agile Software Development http://www.mountaingoatsoftware.com/scrum/overview A New Approach for Instrument Software at Gemini http://spiedl.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=PSISDG00701900000170190Z000001&idtype=cvips&gifs=yes&ref=no

Extreme Programming: A Gentle Introduction http://www.extremeprogramming.org/

http://www.ncycles.com/e_whi_Methodologies.htm

http://www.sei.cmu.edu/reports/96tr022.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.102.1181&rep=rep1&type=pdf

http://accelconf.web.cern.ch/accelconf/ica07/PAPERS/MOAB03.PDF

http://www.mountaingoatsoftware.com/scrum/overview

http://spiedl.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=PSISDG00701900000170190Z000001&idtype=cvips&gifs=yes&ref=no

http://spiedl.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=PSISDG00701900000170190Z000001&idtype=cvips&gifs=yes&ref=no

http://www.extremeprogramming.org/

Documents

D R A F T - National Solar Observatory