# Presentation: 549863

## caArray 2.0

***Inception Assessment***
***Thursday June 28, 2007 ***

## Before we begin

**In Case Anyone Feels Intimidated...**
- The caArray Development team uses Iteration Assessments and Reviews as a means to improve – Our Process, Our Delivery, and Ourselves
- “Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, and the situation at hand.”
- Norman Kerth, from *Project Retrospectives, a Handbook for Team Reviews*

## Agenda

**Goals of the Meeting**
- What are assessments for
- Who’s the team
- High level characteristics
- Iteration Goals
**What Happened and What is Scheduled to Happen**
- Product Manager’s View
- Project Manager’s View
- Architect’s View

## Goals of Any Assessment

**Reveal and Share the Gold:**
- What worked well that we don’t want to forget
- What we learned
- What we should do differently next time
- What still puzzles us
- What we need to discuss in greater detail

**Notes:**
Note: Kerth recommends tracking each of these on a flipchart/whiteboard as the assessment progresses.

## Iteration Characteristics

| Project Name | caArray 2.0 |
| --- | --- |
| Customer | NCICB |
| Iteration Name | Inception 1 |
| Started | 04/02/2007 |
| Finished | 05/18/2007 |
| Binary Result | Complete |
| Development Team Size | 4 |

## Initially Articulated Project Risks

**Identified**
- caArray perception in the community and internally is laced with failure to meet expectations
- Procedural and organizational change
- Lack of detailed awareness of who and what is using caArray as a data source
- Balance current user needs and requests for 1.x against the desire to release a new version
- Timing of the 2.0 release and pressure to get it
- Working with updated technologies (EJB 3, Hibernate 3.2, Java Server Faces)
- Integrating with EVS, Analysis Services, caBIO
**Process for managing Risk items and resolution strategy to come**

## Players

**Development Team – Brent, Eric, John, Rashmi**
**Product Management – Juli, **
**Community Relations - Mervi **
**Engineering Management – Anand**
**External Stakeholders – see Vision Section Stakeholders**
**Internal Stakeholders to be involved more going forward**
- Independent Quality Assurance, Systems, Application Support, Documentation

## Goals of Inception Iteration 1

**Establish the **_**[Vision](file:///../../requirements/docs/Vision.doc)**__** of the Product**_
**Elicit and Prioritize the Requirements**
**Establish a representative and maintainable Use Case Model**
**Research Architectural Constraints and Approaches**
- Against the current application
- Supporting caBIG-wide elements and tools
**Build out an initial prototype of the “to be” architecture**
- Demonstrate functionality employing all layers of candidate architecture
- Integrate with EVS
- Determine and implement caCORE code-generation approach
- Design and implement MAGE-OM API
- Design and implement authorization logic
**Coordinate with QA a use case oriented approach for traceability and testing **
**Create a maintainable environment**

## Success Criteria

**Clearly articulated requirements that have been prioritized by the user community and the Product Manager that can be validated by independent QA for testability**
**Documented Candidate Architecture that represents the layering of the system and the technologies to be employed**
**A running prototype that demonstrates the candidate architecture**
**A stable development environment that can support the automation of deployment requests and testing**
**A reasonable plan for Elaboration Iteration 1 and version 2.0 as a whole**

**Notes:**
Author:  Put success criteria from Iteration Plan here.

## Product Manager’s View

**We obtained a good sampling of input from external stakeholders and several internal stakeholders**
- F2F and phone interviews drove much of the content of the Vision document – over 20 hrs of interviews
- Feedback on resulting Vision document – still to be analyzed
**Internal communication needs to improve**
- Challenge of running the 1.5 release in parallel with the 2.0 Inception
**Timelines are proposed**
- If the Test Plan to come doesn’t fit into the current proposed schedule, the features will be re-evaluated

## Revisit Overall Phase Goals

**Inception (What are we doing)**
- Where the project is scoped and stakeholder buy-in is sought. Long-range planning is done, environments are established, detail is provided on what is to be built.
**Elaboration (How will we do it)**
- Where the envisioned architecture of the finished system is implemented sufficiently that it can be executed and objectively measured.
**Construction (Do it)**
- The most labor-intensive phase, with the largest staff size and the most code being churned out. A successful construction phase will result in a complete product that is ready to be deployed to the user community.
**Transition (Deliver it) **
- Where the user community will progressively be exposed to and use the system being developed.  Includes testing the product in preparation for release, and making minor, fine-tuning adjustments based on user feedback.

## Project Manager’s View of the Iteration

**Majority of Goals Met**
- The overall plan is established though subject to review, negotiation and finalization
- The requirements are established – negotiation on what’s in and out will occur in E1
- Architectural concepts were crafted, threads proven and major investigation into key elements planned
- Test Environment and Tools established
- Development Environment created
- Configuration and Change management procedures drafted

**Notes:**
Author:  Put Project Manager’s Assessment here.
Feel free to use multiple slides.  
Bear in mind our overall goals of the assessment.  Focus on project management issues and:
What worked well that we don’t want to forget
What we learned
What we should do differently next time
What still puzzles us
What we need to discuss in greater detail
This will conclude the manager’s portion of the presentation.  
They should hand off to the Lead Architect.

## How we organized the Dev Project Plan

**At the highest level: Generation, Phase, Iteration**
**Tasks are broken out by Discipline**
**Each Discipline has distinct Deliverables**
- See Development Case for what is must, should, optional according to Phase
- Use Case Oriented
**Plan is officially updated weekly**

## Parallel caArray Paths

**May****	****	****June****	****        July****	****August ****	****           Sept      Oct-Dec**

**1.5**

**1.6**

**2.0**

**1.5+ support**

**I1**

**E1**

**E2**

**C1**

**C2**

**C3**

**RC**

**1.5.0.1**

## What we did well

**Interaction with External User Community **
**Established Draft Process and Plan Proposals**
**Produced Supporting Documentation**
**Built what we said we we’d build**

## Targets for Improvement

**Clarity of Success Criteria upfront**
- Need to be certain (e.g., documented) of what “complete” means for each iteration
**Coordination between Development, IQA, Systems, Application Support**
**Cross Team Process Mentoring**

## Requirements

**Elicitation went well – needs and features acquired, written and documented**
**GForge Implementation of how we represent requirements is a work in progress**
- Traceability remains a problem
**Use Case Model Organized and Prioritized for E1**
- Prioritization for 2.0 to be done in E1
_**[Requirements Management Plan ](file:///../../requirements/caarray_requirements_management_plan.doc)**__**established**_

## Requirements: Use-Case Organization

**Notes:**
Author:  Put a use-case diagram (hopefully in iteration plan as well)  that is color coded or fill patterned to show use-cases that were:
Previously implemented
Implemented Partially during this iteration
Implemented Fully during this iteration
Leave all TBD and Wish List use-cases in their subtle form

## Targeted Use Cases for E1

## Targeted Use Cases for E1

## Targeted Use Cases for E1

## Targeted Use Cases for E1

## Architect’s View of the Iteration	

**Technical Accomplishments**
- Designed and implemented the candidate architecture
- Designed initial draft of the underlying domain object model
- Investigated and designed approach to MAGE-OM API
**Environmental Accomplishments**
- Documented and implemented software development process
- Defined coding standards and automated quality checks
- Implemented development and continuous integration environments

## Candidate Architecture Implemented

**J2EE 1.4**
**EJB 3.0**
**JSF 1.1**
- MyFaces 1.1.5
**Hibernate 3.2**
**EVS integration**
**For complete details:**
- Software Architecture Document
- UML model

## Domain Object Model

**Drafted initial cut of simplified microarray domain model**
- MAGE-OM overly complex, difficult for implementers and clients alike

## MAGE-OM API Approach

**Explored various alternatives to support legacy MAGE-OM API**
**Settled on translation based approach**
**Determining whether MAGE-OM API support is required at all**

## Use Cases Scheduled for Initial Implementation in E1

## Closing Topics

**Unexpected Topics and Questions**
**Review what needs to be discussed in more detail**
**Any issues/questions resolved today**
**What’s next**

**Notes:**
This one goes back to the project manager to put it all together.