• Entails visits to the University of Minnesota-Twin Cities.
• We expect to find information encoded:
  • In many different languages
  • On a variety of media
  • For a variety of operating systems
  • With a variety of logical designs
• Following this task will be opportunities to:
  1. Archive the various data in a common medium
  2. Normalize the data into a single repository

• data analysis workstation
• baseline data management workstation

Because both of these toolkits are implemented in Java, this task also entails assessing Java as the implementation language for the data analysis software.

This task is not concerned with the NetBeans and Eclipse integrated development environments (IDEs), but with the platforms on which the IDEs are built.

The device is essentially a data acquisition system (as in "supervisory control and data acquisition" without the supervisory control).

Linux on a chip?

Some prototyping would be instructive.

This task could probably be the first step in, or lead to, a separate subproject. Before doing so, be sure the objectives do not overlap those of the Low Power Microprocessor subproject.

This is a leadership opportunity.

Because our product is a medical device, we need testing that is formal and is independent of development. Some planning now (rather than later) will help assure that our developers build a testable product and produce information needed by our testers.

This task is also an opportunity to influence whether and how a test-driven development methodology be adopted.

Re-organize the Data Analysis Software subproject into multiple subprojects. In particular, create a systems engineering subproject in recognition that:

• Most of the requirements effort thus far is oriented to system-level issues
• We need to specify user requirements at the system level
• Verification and validation is executated at the system level and consequently needs a system level requirements specificaton

This endeavor has somewhat started, with requirements for the blood pressure monitoring device being written separately from the system requirements. See the Embedded Software subproject.

Before more progress can be made here, we really need a good baseline of the Phoenix system requirements, which is the top-most priority of the Systems Architecture and Engineering subproject.

Interesting (i.e., complex) open-source projects live or die by their ability to spin off subprojects, which are the basis for progress from a diverse, virtual community. The Phoenix Project is developing engineering documents that identify valuable opportunities for such endeavors.

The author of the architecture and requirements descriptions (yours truly) is convinced he will write and enhance these more quickly if someone volunteers as an immediate audience. In return, the volunteer will quickly acquire a broad understanding of the Phoenix System and should soon identify a juicy topic for the volunteer's own investigation.