# Presentation: 140606

## 5AM NCICB Development Process

**An Overview **

**Notes:**
Post mortem title

## Introduction

**Overview of the development process we use at NCICB**
**Very closely based on Unified Process at 5AM (UP@5) with some NCICB specific twists**
**This overview should give the essential information necessary to get stuff done.**
- See the Development Process Quick Start
- For the gory details, see the project artifacts (under construction)

## Outline

**RUP Refresher/Overview**
**Process description categorized by RUP Discipline**
**Phase-based considerations**

## RUP Overview

**Rational Unified Process**
**A process framework documented as a large web site**
**Process is defined/tailored for specific projects or organizations**
**Can be found online at **_**[http://intranet.5amsolutions.com/rup/](http://intranet.5amsolutions.com/rup/)**_
- Version is 2003.06.13

## RUP Project Lifecycle – Phases, Iterations, and Disciplines

## RUP Phases

**Inception, Elaboration, Construction and Transition**
**Each Phase includes all Disciplines, but with different emphases (see previous slide)**
**Each Phase has a different specific objective (milestone)**
**Each Phase (typically) has different staffing and level of effort**

## RUP Iterations

**Planned duration (between 4-8 weeks typically)**
**Culminate in either in internal or external release**
**Have defined objectives**
- e.g. in first Elaboration iteration implement the persistence, authorization, and transaction handling mechanisms and implement the Login and Manage Account use cases
**Culminate in a review**
- Did we meet the objectives?
- What’s working in the process?
- What can we do better?

## RUP Disciplines

**Core Disciplines**
- Business Modeling
- Requirements
- Analysis & Design
- Implementation
- Test
- Deployment
**Supporting Disciplines**
- Configuration & Change Management
- Project Management
- Environment
**Describing how we implement these Disciplines constitues the majority of this overview**

## 5AM Development Philosophy

**“****Just enough” process**
**A smaller team of effective developers is more productive than a large team of inexperienced or non-communicative developers**
**No broken windows**
**Prefer automation to manual tasks**
**No code ownership**
**No death marches**
**Keep learning**
**Collaborate**
**Have fun!**

**Notes:**
- Get feedback / review

## Project Roles

**Roles here are specified in the RUP (mostly)**
**Expected that many roles fulfilled by the same person**
**Roles**
- Project Manager (1)
- System Analyst (1)
- Requirements Specifier (*)
- Software Architect (1)
- Designer (*)
- Implementer (*)
- Process Engineer (1)

**Notes:**
- Should we also have a Tech Lead role?

## Iteration Workflow: Project Management (Before Start of Iteration)

**Project Manager: Develop the Iteration Plan **
- Select targeted use cases and supplementary requirements
- Determine evaluation criteria
- Schedule iteration activities (in MS Project, copy into Iteration Plan)
- Send Iteration Plan to all project members for feedback
- Meet with project members to revise according to feedback
**Scheduling notes**
- Many tasks will initially be high-level and then refined
- E.g. 120 hours for Subsystem Design refined into 20 hours for PermissionsManagement subsystem, 40 hours for FileAccessSubsystem, etc. (refined as subsystems are identified during design process)

## Iteration Workflow: Requirements (Start of Iteration)

**System Analyst: Find Actors and Use Cases**
- Add to Use-Case Model
- Add requirements to GForge
**Requirements Specifier: Detail a Use Case**
- Complete use cases in enough detail to be implemented
- Send use case to entire team for feedback
- Meet with entire team to discuss use case, incorporate feedback
**System Analyst: Develop User-Experience Storyboard**
- Document use-case realizations in terms of UI elements
- Forces explicit decisions on any ambiguous use case requirements
- Send to entire team for feedback
- Meet with entire team to discuss, incorporate feedback
**UI Designer: Create Wireframes (non-RUP)**

## Requirements: Use-Case Model

**Top level view in project Enterprise Architect UML model**
**Use Cases organized in packages of related functionality**
**Shows users and external systems that interact with the system**

## Requirements: Software Requirement

**Classified as either:**
- Need (high level, real world)
- Feature (high level requirements)
- Use-Case Requirement (low level functional requirements)
- Supplementary Requirement (non-functional requirements)

## Requirements: Software Requirement (continued)

**Implemented in GForge as modeled**

## Iteration Workflow: Use-Case Design

**Use-Case Design**
- Create <<use-case realization>> collaboration with sequence diagram per flow to be modeled
- Create Realization class diagram showing realization relationship of collaboration to subsystem
- Demonstrate use case behavior as messages between actor, subsystems and any necessary supporting classes
- Allocate use case flow text to corresponding messages
- Ensure all participants and relationships are shown on Participants class diagram

**Notes:**
Use-Case Design
The design workflow starts with Use-Case Design. In this task, the objective is to define the messages that must pass between subsystems (and other supporting system elements) to provide the functionality described in the use case.
Create a package with the same name as the use case to be designed in the Use-Case Realizations package of the Design Model. The use-case realization packages should be organized in the same way that the corresponding use-case packages are organized in the Use-Case Model.
Create the following elements in the new package:
a class diagram named Realization (default diagram),
a class diagram named participants,
and a <<use-case realization>> stereotyped Collaboration with the same name as the use case to design in the new package.
Add the <<use-case realization>> to the Realization diagram and create a realization relationship to the corresponding use case.
For each flow (Basic Flow and Alternate Flows) create a sequence diagram nested within the <<use-case realization>>. Right-click on the diagram, choose Properties... and check the option “Show Sequence Notes”.
Design the use-case functionality in terms of messages between subsystems (and any other necessary support classes) within the sequence diagram, defining the necessary subsystem interface operations. Add the literal use-case step text as the “Notes” field in the diagram (this will cause the text to show up on the left had side of the diagram as a script).
Add the classes and subsystems referenced in all of the sequence diagrams to the Participants diagram and ensure that sufficient relationships exist between the elements to support the messages defined in the sequence diagrams.

## Use-Case Realization: Realization Diagram

## Use-Case Realization: Sequence Diagrams

## Use-Case Realization: Participants

## Subsystem Design

**Create a class diagram to show the subsystem interfaces and implementation classes**
**Create a composite structure diagram to show the subsystem’s realized and required interfaces (and any other dependencies)**
- Documenting internal parts in this diagram not required (but encouraged if helpful)
**Create <<interface realization>> collaboration with sequence diagram per operation to be modeled**
**Generate or write Java code for subsystem interface**

## Subsystem Composite Structure 

## Subsystem Contents

## Iteration Workflow: Implementation

**Tasks are assigned**

## Implementation: Workflow

**Tasks assigned in GForge Tracker**
**If GForge, mark item as “in process”**
**Implement code and unit tests**
**Check in code**

## Implementation: Code Style and Conventions

**Small classes (about 300 lines max)**
**Short methods (prefer about 4-5 lines, about 20 max)**
**Javadoc for protected and public methods**
**Few, if any inline comments (code should be self-documenting)**
**Refactor mercilessly**
**Automated tools are set up to enforce conventions and good coding practices**
- Checkstyle
- PMD

## Implementation: IDE

**The supported 5AM IDE is Eclipse**
- Configuration steps documented in Development Environment portion of 5AM Wiki
**Problems View (Errors and Warnings) must be clear prior to committing code**
- Most issues here will cause the continuous integration build to fail
- No broken windows

## Implementation: Unit Tests

**Use JUnit 4 for unit testing**
**Unit tests should ideally only test code in a single class**
- Realistically, other classes in the subsystem will be involved
- Subsystem dependencies on required interfaces should be implemented with test stubs

## Implementation: Unit Test Coverage

**Checked with Cobertura in continuous integration build**
- Insufficient coverage will cause build to fail

## Implementation: Continuous Integration

**Uses CruiseControl**
**When code is checked in automatically triggers a build within a minute**
**Builds artifacts, runs code checks, runs unit tests and publishes results**
- For this reason, it’s important that unit tests run quickly (i.e. no dependencies on external resources)
**Run “ant continuous-integration” locally in order to check if build will be successful, if in question**
**If build fails, team must immediately drop current work and work to resolve.**

## Test

**Descriptions here are for development side testing (not independent QA testing)**
- Test Cases
- Test Traceability
- Test Automation
**Delivery to QA**

## Responsibilities

**Project Manager**
- Get approval of scope of iteration from the client at the start of the iteration
- Monitor tasks
- Monitor risks
- Monitor all responsibilities listed here are met
- Revise schedule
**Software Architect**
- Define or approve subsystem interfaces
- Approve use-case realizations and subsystem designs
**Implementer**
- Review partner’s code and unit tests within 24 hours
- Adhere to design in model
**All**
- If any scheduled task will be late, let Project Manager and Software Architect know at least one day before deadline

**Notes:**
What are Software Architects responsiblities for code quality / productivity issues?

## Consequences

**Project Manager monitors**