TAPAS Development Method
Release Information
| Project: |
TAPAS
|
| Internal Release Number: |
$Revision: 1.3 $ $State: Exp $
|
| Related Documents: |
|
The purpose of this document is to specify and communicate the method,
process and tools used for develop software in this project. The method
presented here is based on a combination of several existing process
frameworks, including OPEN (object oriented process, environment, and
notation), extreme programming (XP), the rational unified process (RUP)
and ESCAPE. In order to distinguish our method from these
methods, we will call it "QP" from now on. The main concepts of the QP
method are shown in the following figure: there are workers responsible
for tasks producing work products with the help of tools.
Tasks
not only provide work products, but they may also require work products
as an input. The overall organization of tasks, workers, work
products, and tools is organized by a phased process Model.
Work Products
Work products include every possible software artifact, including but
not limited to source code documents, design documents, requirements
specifications, test plans, user manuals, etc.
all work products have a title, a version number, a responsible author.
These attributes can be provided at managed by our configuration
management system.
Process Phases
Our process will be governed by the RUP phases. In other words, there
will not be a strict waterfall-like sequence of activities, starting
from business modeling and ending in software test and
deployment. Rather, all these activities are involved in all
phases of or process, but with different degrees of intensity. The RUP
diagram shows, that in support of software development we need activity
such as configuration and change management, project management, and
environment infrastructure.
Tasks and Workers
Tasks fall and the general disciplines as described on the vertical
axis of the RUP diagram. The general allocation of the task disciplines
to project members is given in the table below. (see also the project
charter)
| Task Discipline |
Member |
| Business Modelling |
Morgan |
| Requirements |
Morgan, Jens, Joel, Meike |
| A&D |
Jens, Joel, Meike |
| Implementation (includes
unit test) |
Joel, Meike, Brad, Clive |
| Test (QA) |
Joel, Morgan, Jens |
| Deployment |
Joel |
| Configuration &
Change Mgmt |
all (facilitated by Joel) |
| Project Management |
Amanda (Planning), Jens
(Technical) |
| Environment |
(physicians) |
Specific tasks are not documented in this method document but in the
project plan.
Tools
It is important to agree and document the selection of tools, since
they typically determine the physical storage format of work
products. Moreover, tools influence the quality of the work
product. Our selection of tools has to balance the desire to
use
the best possible tool with the desire to accommodate an open source,
community-based development process. Therefore, as much as
possible, we select freely available open source tools. Another
important factor for the quality of a software product is the way how
tools are used. The following table shows the tools that are
associated to particular task disciplines and guidelines on how they
should be used.
| Task Discipline |
Tool |
Version |
Guideline |
| Business Modelling |
Omnigraffle |
|
|
| Requirements |
Qset, VPUML |
1.1 |
* Use nVu to edit Qset
templates |
| A&D |
Qset, VPUML |
1.1 |
(same as above) |
| Implementation |
eclipse, junit, ant |
|
* use assertions
* source code files must show standard header (tbd)
* Follow Java coding
conventions
* Use test-driven
development with Junit
* Use ant build scripts |
| Test (QA) |
bugtracker? |
|
* Use Hannibal as test server
* Use Murdock as beta test / staging server
|
| Deployment |
|
|
* Use BA as
deployment server |
| Configuration &
Change Mgmt. |
CVS |
|
* VPUML models cannot be
merged,
therefore use "reserved checkout" to make changes
(cvs co -l ....)
* Recommended tool for accessing CVS: eclipse
* check-in regularly - but only code that compiles |
| Project Management |
MS Project |
|
* Project members update
status weekly |
| Environment |
|
|
|
Agility - Quarterly Release
Cycle
Agility is important in order to gain fast feedback from stakeholders
and to be able to more effectively engage community-based development
in a open source project. Agility can be achieved trough frequent
evolutionary iterations and staged releases of the software product.
Our process plans for querly iterations and releases. A rapid
proof-of-concept (POC) prototype is part of the deliverable of the
elaboration phase and several subsequent releases will be the result of
separate iterations in the construction phase.
Iteration / Release Plan
-
| Major Iteration /
Release |
Phase |
Date Planned |
| Paperchild
(Proof-of-concept prototype) |
Elaboration |
March 31, 2005 |
| Strawman |
Construction I
|
June 31, 2005 |
| Woodwoman |
Construction II
|
September 31, 2005 |
| Ironcat |
Construction III
|
December 31, 2005 |
Diamonddog
|
Deployment |
March 31, 2006 |
User Review
Frequent feedback from users is important to mitigate the risk of
software development for a complex application domain such as health
care. Subject to user review are work products related to software
requirements specification, user interfaces, and business logic. The
outcome of user reviews is documented in predefined temlates and
archived. We conduct user reviews on three different levels:
Incremental user review (IUR)
IURs
are performed every fortnight during the large group meeting. (IUR is a
standing agenda item for each of these meetings. The time allotted to
IUR depends on the number of items to be reviewed. If possible, team
members are asked to submit items relevant to the IUR to the project
manager two business days prior to the team meeting. This enables
everybody to study the items prior to the actual meeting.) Relevant
items are any changes and additions to work products related to
software requirements specification, user interfaces, user manual, and
business logic. The results of each IUR is documented by filling out
the IUR form. The principal "user in residence" to evaluate IUR items
is Morgan Price, MD.
User Focus Sessions (UFS)
UFS
are preformed at least every quarterly after each iteration cycle (see
incremental release plan above). Outside users and domain experts are
invited as principal evaluators. Prior to the UFS meeting,
evaluators are provided relevant documentation such as a snap shot of
the current requirements specification and user manual. The results of
each UFS is documented by filling out the UFS form.
User Acceptance Study (UAS)
UAS
are typically conducted as part of the deployment or transitioning
phases of the staged software development life cycle. The involve a
population of users evaluating the software product in practice. UAS
are planned and documented using the UAS form.
Elaboration phase
The purpose of the elaboration phase is to
- Analyse the problem domain
and define a technically
feasible architecture.
- Mitigate the highest risks
to the projects.
- Make a detailed project plan with prioritised activities.
The high level steps in our elaboration phase a shown in the following
diagram. The first step produces a quick elaboration phase
plan. Then the requirements are analyzed, specify, reviewed
and
approved before the architecture is designed and the QA plan are
developed in parallel.
Architecture design
In this phase, we are just concerned with the design of a high level
component architecture with a precise interface
specification.
The encapsulated structure of components will not be designed in this
phase.
QA Plan
The focus of the QA plan is to provide a proof of concepts that helps
to mitigate the risks and uncertainties involved in the
project.
The plan should include potentially simplified typical example scenario
for the use of the planned software product.
Implementation of POC prototype
The prototype implementation has to go to validate the architecture and
a component interfaces. It may be simplified in the sense that it only
supports the proof of concepts scenario plant in the QA plan.
Construction phase
TODO:
Define subsequent phases
