Implementation Proposal

From DaVinci

Contents 1 Purpose 2 Context 3 Design & Coding 3.1 Design 3.2 Coding 3.2.1 Conventions 3.3 Internal Change Control Process 4 Quality Assurance 4.1 Design Review 4.2 Code Review 4.3 Unit & Integration Testing 5 Source Control 6 Tools 7 Evaluation Criteria 8 Reflection

Purpose

This proposal describes the guidelines and approaches taken to define team Davinci's baseline implementation process. The baseline process standardizes the tasks for the following:

• Design
• Coding
• Quality Assurance (QA)
• Source Control

This process shall be iterartively applied to develope each requirements as defined in Product Backlog incrementally on customer agreed schedule stated in Statement of Work. These guidelines can be updated if the team agrees that updates are required due to team reflections or changes in the project. We will base future decisions regarding the tailoring of this process upon this definition and capture our decisions in this document. This document also serves as input for reflection on our methods to address implementation. We will capture reflections based on this proposal in combined reflection wiki page.

Context

Team DaVinci defines the implementation phase to include all tasks associated with design, coding, and testing of a feature listed in the Product Backlog. Each feature implementation phase is bounded by the following entry/exit criteria.

Entry criteria:

• Use Cases (see Problem Definition Proposal) - A use case that bounds all alternatives required to satisfy a feature listed in Product Backlog.
• Quality Attribute Scenarios (see Problem Definition Proposal) - All related OSATE application quality attribute operational examples.
• Customer Acceptance Criteria (see Statement of Work) - Customer expectation as specified in acceptance process for the feature delivered.

Exit Criteria:

• Quality Code - Source code that has been verified through planned QA techniques as defined in the Quality Assurance section below.
• Java Doc - Description of source code developed for the feature.

The implementation phase life cycle:

   Entry criteria -> Design -> Coding / QA -> Exit Criteria

Design & Coding

The task to transform a Use Case with associated QA Scenario(s) into source code that satisfies the customer's requirements is executed in two steps: Design and Coding.

Design

Team DaVinci will generate architectural diagrams, to show quality attributes can be met, and UML class and sequence diagrams, per the customer's request. The team will also generate flow diagrams as an internal artifact.

In parallel, a Functional Test Plan (see definition in Software Process Specification) for the relavant development is generated to drive Unit & Integration Testing before coding starts.

Feature relevant Architectural Diagrams including UML class, sequence diagrams, and flow diagrams shall be created on wiki as input for customer reveiw presentation.

Coding

Team DaVinci will develop code using the tool environment as defined in the Tools section below. The team will apply Pair Programming as stated in Software Process Specification.

Conventions

• All deliverable code shall follow standard Sun Java coding conventions unless otherwise specified in Statement of Work.
• All files should start with the OSATE copy right notice.
• The class level javadoc should contain:
  • @author
  • @version $Id:$
    • $id:$ is a variable that will be filled in by CVS
• Java files cannot contain unused imports.
  • Using organize imports feature of eclipse will remove any unused imports.

Internal Change Control Process

TBD - do we need to add process to monitor design change communication during implementation phase (multi-person programming)?

Quality Assurance

Team DaVince shall adopt multiple techniques at various stages of implementation as outlined below to produce a quality product.

  Design -> Design Review -> Coding -> Code Review -> Unit & Integration Testing

All bugs related to development code identified during or after integration phase shall be reported using OSATE bugzilla. Bugzilla of relvant application shall be used for reporting application error identified during development.

TBD: Does customer want to see eclipse error on OSATE bugzilla? Or by other means?

Design Review

The feature owner shall distribute design artifact for designated team member to review. Individual shall provide question or comments against its corresponding requirement(s) using Review Template.

Code Review

Code review is done in real-time by multiple developers working on the same code doing pair programming.

If not practicing pair programming, code review shall be conducted on code checked in to CVS for integration test using either one of the following formats.

• Code inspection (see Software Process Specification) - adopted when expertise is available in development area.
• Code walk through (see Software Process Specification) - adopted when expertise is not available in development area.

Unit & Integration Testing

Integration testing will be conducted as specified by the Functional Test Plan (see Software Process Specification) prior to customer delivery.

Unit tests are conducted voluntarily by developers and after planned builds.

Metrics to be captured:

• Number of bugs identified.

We will try to use JUnit for automated unit testing then reflect the experience after 1st implementation task for further usage.

We will try to use Clover for code test coverage then reflect the experience after 1st implementation task for further usage or targeting coverage %.

Source Control

Team DaVinci will use CVS as its source code repository and the only repository for deliverable source code. At any time, only compilable code is checked into CVS.

A label is applied to "snap shot" delivarable source code expected in Statement of Work for customer acceptance and respecitve java doc.

Tools

• IDE - Eclipse 3.1 integrated with OSATE 3.1
• Integration & Unit test - JUnit (version 3.8.1), Clover (version 1.2.9), and OSATE Bugzilla.
• Source configuration control - OSATE CVS
• Source code line counter - TBD

Evaluation Criteria

Team DaVinci wants to be evaluated based on the following criteria

1. Did the team completed each feature implementation as described in Context?
2. Did the team created design documents as stated in Design section and use it for client review meeting?
3. Did labeled source code delivered to customer for acceptance test passed all test cases specified in Function Test Plan?

Reflection

At the end of each sprint, the development team will reflect on the process to assess the team's success(es) and/or failure(s). We will capture reflections based on this proposal on our combined reflection wiki page.

1. Is pair programming done efficiently? Did it reduce implementation duration? Why? Why not?
2. Is the CVS branch stable (compilable at any time)? Do we need to implement additional infrastructure features (e.g., automatic over night build) to assure stable source base.
3. Is the delivered code always accepted by customer? If not, is it quality related? What is the quality problem?