From original Etherpad session http://etherpad.com/9HwuUgNjia

Date: 2010.01.04  (yyyy.mm.dd)
Description: CI Dev Team Meeting
Attendees: John G, Michael M, Claudiu, Emilia, David S, Arjuna, Tim F, Tom I, Paul, Dorian, Roger U, Kevin G, and possibly others...

Action Items:

Notes:

LCO Artifacts

First draft from Alan Chave, additional thoughts in italics.

Using the division of artifacts into five sets as described in  Confluence and the SLCP, here is a strawman list:

Management set: Risk Register and Integration and Test Strategy presented, ECRs available for review as needed

Requirements set: Use cases, ConOps and requirements, with emphasis on  L4. The use cases need to be gathered together and captured into a document, and the ConOps needs to be expanded and updated. For example, we have no ConOps that describes cloud computing. A presentation/story board of user-facing operations (sensor interactions on the one hand, user interfaces to access sensors or products on the other) will be important at LCO to make this sysystem more concrete.

Design set: For each subsystem, OV-2 (block diagram, dependencies/needlines) and OV-7 (data models and similar) should be mature, assume that OV-4 (organizational hierarchy) and OV-5 (operational activities -- workflows, activity diagrams) are not substantially changed, OV-6 (detailed behavior diagrams -- sequence, rules, state) as needed to illustrate specific points, the SVs are expected to be incomplete, TV for critical technologies only, prototype reports and demonstrations.  May want to emphasize the most concrete and accessible representations, in order to keep connected to the reviewers. For example, a walk-through/animation of what happens in the system when a sensor is attached may be very helpful.

Implementation set: for critical risk prototypes only, may be satisfied by prototype demos.  

Deployment set: none

Jira Reporting

Same process as before. Tasks are in Jira, leads allocate them to team members, team members report comments or general progress as desired, but any progress on a task should be reported at least once biweekly (for the biweekly report).

Monthly Reporting

If you haven't gotten your monthly to Rita/John for December, it's late, please do so.

Next month, we will be converting to a leads-driven monthly process, so you won't need to submit individual reports for Rita/John. You may be asked to provide information to your lead.

Schedules

Michael out next week. John G, David S in San Diego next week. 

Bill Bergen (OL) and Alan Chave (WHOI, CI System Engineer) in San Diego Monday and Tuesday morning.

Some interviewing to take place at UCSD next week.

Architecture Training/Discussion with Matt A.

Next week we think Matt will be talking to a few of us about data/interface/protocol specification frameworks and languages (e.g., ASN.1, Fudge, UML, OWL, ...), and their possible/proposed applications to OOI CI work.

We have to go through a sorting process for many of these broad system concepts, to determine when are they needed, if at all. For example, do we need a description language/framework for the metadata that defines our messages:
- in this Iteration?
- in this Release?
- by some future release of this project?
- not at all?

We'll probably have to answer that kind of question in a number of different areas during the iteration.


DODAF:
OV-1 High Level Graphical/textual description of operational concept (Michael)
OV-2 Operational nodes, connectivity and information excahange dependencies between nodes (Block Diagrams)
OV-4 Organizations, Roles and relationaships between organizations (nascent)
OV5 Capabilities, Operational Activities, relationships among activities, input and outputs. Overlays can show cost, performing nodes, or other pertinent information.(Format?)

OV-6a Operational Rules Model (Format?)
OV-6b Operational State Transition Description (Format?)
OV-6c Operational Event-Trace Description (Sequence Diagrams)