• FlowJo.com
• The Daily Dongle
• FlowDx Blog
• MyCyte.org

Table of Contents
Introduction
Project Plan
Methods
 Use Cases
 Algorithms
 Metrics
 Infrastructure
Results
Discussion
References

FlowDx is more about process than product. We come in with existing software that services a large portion of research flow cytometry but seek to reinvent the software for a new market with more stringent procedural requirements. 

This translation from lab to hospital requires us to raise the quality assurance requirements and to create a higher level of integrated validation than we have used before now.  The essence of improving software quality is to focus on the process.

The consensus framework for best practices in software engineering is known as the Rational Unified Process (RUP) [61], which provides the fundamental principles and disciplines of iterative development.  Although the RUP is actually one implementation marketed by IBM, it has many variants.  We use it here to refer to the terminology and general family of frameworks that derive from it.  OpenUP, AgileUP, EssentialUP, Oracle Unified Method, etc. are variations on the concepts, downscaled or refocused to match the project scale.  RUP is a big mechanical behemoth, but the concepts and terms are applicable for small, organic projects, too.  For the most part, the top-level documents are quite relevant and are used herein, but AgileUP [65] is the closest to our interpretation, which downgrades the importance of tracking small-grained tasks. 

The biggest risk of an RUP project is being overwhelmed by the administrative requirements of the process. RUP recognizes its own complexity and prescribes that the first step of the project management should be to edit down requirements list within the context of the goals of the project. Nevertheless it is often tempting to include artifacts from its library as the answer to each risk uncovered. The FlowDx project team has determined which RUP requirements apply to our project and has created over 50 documents that compose the project plan, all maintained online and editable by the team.   

The advantage of RUP is in well-designed milestones, processes, and work products.  It provides generalized structure for a host of reports and checklists. It fosters formal review of problem resolution and risk mitigation, and iterative development.

• Integrate suitable RUP practices in project management of FlowDx
• Evaluate the hypothesis that automated gating can be equivalent to manual gating, improve efficiency of analysis, and reduce data analysis cost
• Create/Assemble tools to do algorithmic gating, population evaluation and data management
• If hypothesis is confirmed, apply the validated algorithms to customize automated high-throughput analysis solutions

The aspect of formal project management that has emphatically not worked for us is the task-based planning tools, based on PERT charts and Gantt charts.  The overhead to manage actual time spent vs. projected time required a more-detailed time tracking infrastructure than we have.  Emphasis was placed on how long a task took, not how good it was.  Within a few months the project plan was a dead document that was useless to the elaboration of the project and clogged the critical path of further project management.

This version of the project plan represents a new approach to manage by vision, instead of by tracking details.  This can be interpreted as top-down management, as opposed to bottom-up administration, as encouraged by RUP.

For a project of our size, the value is that RUP supplies the vocabulary, schedule, and milestones.   The biggest lesson learned from this process is that project management software is not only an excessive burden to a small team project but also creates odious roles for those managing the reporting.  

Rather than recursively dissect projects into sub-projects, we are focusing on the work product and building collaborative documents. We have found that e-mail threads and Google Docs are completely sufficient for our requirements of defining software specifications.  The FlowDx project plan is a complex network of interlinking specifications, instead of the top-down tree structure used in traditional project software.  This better models the iterative nature of the project life cycle and handles validation with more parallelism and redundancy.

RUP best practices are applicable to all projects:

Most of these are so well-accepted that they are already built into the development cycle and the programmer’s tool set.  We are developing Java code in Eclipse, the most common open IDE. Source control management (Subversion) provides the infrastructure for iterative development, component management, and change control.  Interactions with Apache and MySQL are very standard.

The design decision to implement a LAMP repository, and Tomcat as a tool service, ensures a component-based architecture widely used for projects of this scope.  The use of XML to link components and intermediate states is a well-understood method of managing requirements and supporting continuous test architectures.

Change Request Management is not tracked, other than in the notes of meetings.  As we enter the transition phase and have external users, CRM becomes necessary.

Adhering to the Engineering Disciplines:

Business Modeling - as discussed in the commercialization plan, a strong business model has been formed, and this project is driven by a recognized and growing market need for faster analysis.

Requirements - FlowDx has been reformulated and restructured as much more extensible tools, able to be combined into pipelines and automated further.  Requirements are elaborated in the workflow document and the infrastructure document.

Analysis and Design - have been emphatically detailed in scope and communication.  The intent to fund the project through grants and to submit it to the FDA for approval in clinical environments has necessitated high levels of documentation and communication throughout the design process.

Implementation - is based on design documents, tracked with e-mail correspondence and weekly meetings, and carefully integrated with FlowJo engineering.  Upcoming versions of FlowJo will provide a classifier bridge, thereby implementing steps in the workflow ahead of FlowDx.

Test  - is facilitated by the stream of intermediate files defined in the workflow.  Transition from one state to the next is easy to validate and amenable to scripted testing that is recognized in the QA plan as an imperative requirement of the construction.

Deployment - is understood to represent a large drain on resources when the project moves outside our office.  Each installation represents a new assay or set of assays, and the consulting requirement increase that will come with customers is not to be underestimated. 

Life Cycle Milestones are an important benefit of this framework. They emphasize the need to specify the scope and schedule of the work.

2.1.5.1 Life Cycle Objective Milestone (LCO) - Stakeholder concurrence on scope definition and agreement on the requirements at the end of Inception Phase.
2.1.5.2 Life Cycle Architecture Milestone (LCA) - Product's architecture is stabilized at the end of Elaboration Phase.
2.1.5.3 Initial Operational Capability Milestone (IOC) - Product Development is completed by the end of Construction Phase.
2.1.5.4 Product Release Milestone - The primary objective is to transition the system from development to production, making it available to, and understood by, the end user.

1. Software Development Plan - The Software Development Plan is a comprehensive, composite artifact that gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and is maintained throughout the project. 
2. Iteration Plan - A time-sequenced set of activities and tasks, with assigned resources that contain task dependencies, for the iteration; the plan is fine-grained.
3. Quality Assurance Plan - The Quality Assurance Plan is an artifact that provides a clear view of how product, artifact, and process quality are to be assured. It contains the Review and Audit Plan, and references a number of other artifacts developed during the Inception phase. It is maintained throughout the project. 
4. Risk & Problem Management - The Risk Management Plan details how to manage the risks associated with a project. The Problem Resolution Plan describes the process used to report, analyze, and resolve problems that occur during the project. These two plans have been combined to avoid overlapping administration.
5. Product Acceptance Plan - The Product Acceptance Plan describes how the customer will evaluate the deliverable artifacts from a project to determine whether they meet a predefined set of acceptance criteria. The plan details these acceptance criteria and identifies the product acceptance tasks (including identification of the test cases that need to be developed) that will be carried out and the assigned responsibilities and required resources. On a smaller scale project, this plan may be embedded within the Software Development Plan
6. Project Requirements Document - Describes the requirements of the project management including RUP, Grant Application & reporting requirments, Grant Invoicing as well as the software development requirements in the software development plan.