Implementation Proposal

From ZenWiki

Jump to: navigation, search

Contents

Purpose

The Implementation Proposal describes the implementation approaches used by Team Zen. The focus of this proposal is to ensure the source code quality with constant verification, and increase productivity with a highly automated development environment.

Point of Contact

Fall 2006

The point of contact for this proposal during the fall semester of 2006 is Lung-San (Allen) Hsu. Allen can be reached with email: [1].

Spring 2007

The point of contact for this proposal during the spring semester of 2007 is Marc Novakouski. Marc can be reached with email: [2].

Summer 2007

The point of contact for this proposal during the summer semester of 2007 is Sajjad Mustehsan.

Approaches

Our main approach towards implementation will be agile. Particularly, we have chosen several practices from Extreme Programming(XP). XP has been criticized as lacking solid architecture. Our architecture-centric process (covered in the Operations Proposal) will be a perfect match to fill in what is lacking in XP. Another characteristic of our approach is that we will build an automated development environment. The initial investment to setup such environment is expected to be high, but in the long run, we foresee it will be helpful for the implementation in terms of productivity and quality.

Coding standards

A set of coding standards will be defined in a separate document.

Test driven

Test cases are created before developing actual production code. Generation of acceptance tests, unit tests, regression tests, and load tests are detailed in the Quality Assurance Plan.

Pair programming

Pair programming will be applied in the following situations:

  1. Developing a new area of code that has not been developed in previous iterations.
  2. As a learning technique, with the goal of spreading knowledge among team members.

Note: further tailoring of how we will perform this task will be likely be done in the summer.

Continuous integration

Process

A automatic build process will be in place. It will comply with the following principles:

  1. The head revision of the SVN repository will be automatically extracted and compiled on the team server. This will be done at least once per day.
  2. Results of the automatic compilation will be automatically sent via email to each team member upon completion of the compilation.
  3. The static analysis tool PMD will be run on the head revision of the SVN repository. The rulesets used are documented in the review of PMD located here.
  4. Results of the automatic PMD evaluation will be automatically sent via email to the chief scientist and the chief architect.
  5. Logs of both execution will be date-stamped and archived on the server.

Note: further additions of test suites to the build process will be added during the summer as they become relevant.

Setup

Components

The automatic build process currently in use makes use of the following components:

  1. Eclipse IDE (used headless); reference
  2. Ant Java compiler; reference
  3. Tortoise SVN repository (located on the team server at c:\team-zen-svn); reference
  4. Blat (command-line email tool); reference
  5. PMD (static analysis tool); reference
  6. Build.xml (build file for the navigation prototype, located on the server @ c:\test)
  7. build_process.bat (batch file for executing the build process, located on the server @ c:\test)
  8. Windows task scheduler
  9. Date-stamped Build logs (results of the compilation, located on the server @ C:\build_logs)
  10. Date-stamped PMD logs (results of the compilation, located on the server @ C:\build_logs)
Execution

The build process is currently set up to execute in the following manner:

  1. Windows task scheduler kicks off build_process.bat every day at 8PM.
  2. build_process.bat deletes the existing c:\build directory (to ensure a fresh compile)
  3. build_process.bat extracts the head revision of the SVN repository to c:\build
  4. build_process.bat copies the build.xml file (generated within the Eclipse IDE) used for the compilation to the correct location (currently c:\build\experiments\zen.prototype.navigation)
  5. build_process.bat performs the ant compilation task on the copied build.xml file and writes the output to a file named build.log
  6. build_process.bat copies build.log to the C:\build_logs archive and date-stamps it
  7. build_process.bat emails build.log to every member of the team using the Blat command line email application
  8. build_process.bat runs PMD on the extracted head revision (c:\build), using the rulesets specified here, and generates the pmd_results.html log file
  9. build_process.bat copies pmd_results.html to the c:\build_logs archive and date-stamps it
  10. build_process.bat emails pmd_results.html to the chief architect and scientist using Blat
Future Work

We plan on doing the following to refine our build process:

  1. Perform two automatic builds, one for the client application and one for the server application
  2. Extract only the necessary files from the SVN repository for each build
  3. Possibly perform more than one automatic build per day (as necessary)
  4. Integrate unit tests and other automate-able tests into the automatic build process


Collective code ownership

Team members are encouraged to add or change any line of code. Collective code ownership will also go hand in hand with strengthened communications between team members.

Refactoring

Make the code more readable, flexible and maintainable.

Version control

Subversion will be used as the version control repository. The guidelines of using the repository will be defined in a separate document.

Bug/issue tracking

A bug/issue tracking system will be installed. The guideline of using the system will be defined in a separate document.

Analysis

Automatic tools are preferred, but we will also conduct manual code inspection/review in a regular basis.

Code analysis

Consistent programming style is maintained through out the project. Every line of code will follow the coding standard we defined. A code analysis tool will be selected to check the conformation. The tool will also be incorporated into the automatic-build process, so the result will be always available and can be used for postmortem.

Code coverage

  • Code coverage will be constantly monitored and result posted, so everyone will have a clear idea of how robust our test suite and production code are. The percentage of coverage should be more then 70%(tentative).
  • A history of coverage percentage will be tracked. The data will then be used for postmortem and planning (estimation) in each iteration

Code inspection/review

  • First code inspection/review session will be hold soon after all the team members have produced the first set of codes. The following sessions are scheduled regularly in each iteration.
  • During code inspection/review session, refactoring opportunities will be identified.
  • Defects (including refactoring) will be recorded and be submitted into the bug tracking system.
  • Practice of pair programming will be reviewed, and necessary changes will be reflected on this document.
  • Practice of collective code ownership will be reviewed, and necessary changes will be reflected on this document.

Continuous integration

The status of the automatic-build process is tracked. The rate of successful build should be more then 90%(tentative).

Automatic Static Analysis

We will include the use of the PMD tool on our automatic builds. An evaluation done on the PMD tool for our MSE class "Analysis of Software Artifacts" can be found here.

Reflection

Reflection is conducted at the end of every iteration. The result is documented separately in the Team Reflection.

Reference

Retrieved from "http://msesrv1d.mse.cs.cmu.edu/wiki/index.php/Implementation_Proposal"
Personal tools