software development methodology for the dkist

DRAFT DOCUMENT - STILL IN FORMAL REVIEW PROCESSProject Documentation

Document TN-0131 Draft 1

Daniel K. Inouye Solar Telescope 3665 Discovery Dr Boulder, CO 80303 Phone 303-735-7356 [email protected] http://dkist.nso.edu

Software Development Methodology for the

DKIST Instrumentation Team

A. Ferayorni DKIST Instrumentation Group

April 2016

DRAFT DOCUMENT - STILL IN FORMAL REVIEW PROCESSSoftware Development Methodology

TN-0131 Rev A Page ii

REVISION SUMMARY: 1. Date: July 2010

Revision: Draft 1 Changes: Original version

2. Date: April 2016 Revision: Rev A Changes: Updated for DKIST

3.


TN-0131 Rev A 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 DKIST .......................................................................................................... 4 3.3 SPIRAL................................................................................................................... 4 3.3.1 Overview .......................................................................................................................... 4 3.3.2 Features ........................................................................................................................... 4 3.3.3 Analysis for DKIST .......................................................................................................... 5 3.4 CLEANROOM .......................................................................................................... 5 3.4.1 Overview .......................................................................................................................... 5 3.4.2 Features ........................................................................................................................... 5 3.4.3 Analysis for DKIST .......................................................................................................... 6 3.5 SCRUM................................................................................................................... 6 3.5.1 Overview .......................................................................................................................... 6 3.5.2 Features ........................................................................................................................... 6 3.5.3 Analysis for DKIST .......................................................................................................... 8 3.6 EXTREME PROGRAMMING (XP) ................................................................................ 9 3.6.1 Overview .......................................................................................................................... 9 3.6.2 Features ........................................................................................................................... 9 3.6.3 Analysis for DKIST ........................................................................................................ 10 4. RECOMMENDATION ......................................................................................... 11 4.1 PROJECT LEVEL PRACTICES .................................................................................. 11 4.1.1 Overview ........................................................................................................................ 11 4.1.2 DKIST Implementation .................................................................................................. 11 4.2 ENGINEERING PRACTICES ..................................................................................... 13 5. REFERENCES .................................................................................................... 15


TN-0131 Rev A 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 DKIST 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 DKIST 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 DKIST 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 DKIST effort. Finally, in Section 4 we will document our recommendation of practices to be used by the DKIST instrumentation team as well as provide an explanation of how they will be implemented. The DKIST instrumentation team is responsible for delivering the following:

Visual Broadband Imager (VBI) VBI will record images from the DKIST 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 DKIST 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

DKIST Daniel K Inouye 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 DKIST

The DKIST 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 DKIST 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 DKIST 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 DKIST 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 DKIST 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 DKIST 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 DKIST 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 DKIST. The user of peer code reviews will be vital to the success of the DKIST 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 DKIST 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 DKIST 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 DKIST 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 DKIST 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, DKIST camera systems software team, or members of the DKIST 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 DKIST project. The DKIST 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 DKIST.

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 DKIST 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 DKIST team. Coding Standards and Simple Design will be important as the DKIST 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

Each of the methodologies surveyed showed strengths and weaknesses with regard to how it can be used by the DKIST 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 DKIST instrumentation team. The Scrum methodology is the most attractive of the iterative models due to the following strengths: Frequent Releases - The DKIST 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 DKIST 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 DKIST 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 DKIST staff can know when to expect certain functionality to be released.

4.1.2 DKIST Implementation

The DKIST instrumentation team will use a modified version of Scrum that is adapted to the high level DKIST project milestones (PDR, CDR, etc). The diagram below shows how the Scrum process will be used in conjunction with the DKIST 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.



The DKIST 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 DKIST 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, DKIST-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 DKIST 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 DKIST 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 DKIST 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 DKIST instrument team will follow the coding standards established for DKIST. 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 DKIST software team and published along with existing standards.

Continuous Integration

The use of Continuous Integration (CI) will help the DKIST 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 DKIST software team.

Test Driven Development

The approach of test driven development (TDD) supports many of the goals set forth by the DKIST 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 DKIST 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 DKIST-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 DKIST 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 DKIST 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 DKIST instrumentation team will work cross-functionally with the DST and DKIST-Tucson teams during the project. Leveraging the experience of the DST software team will prove extremely valuable in our instrument development effort. Similarly, the DKIST-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/

software development methodology for the dkist

Documents