S&I+Framework+RI+Development+Process

toc

Collaborative Open-Source Software Development Process
This process description is intended as a starting point for a work group engaged in collaborative open source code development. It is to be customized by consensus as needed by the participants in the work group.

It is essential to the success of any collaborative team effort that contributing participants adopt a process that they have confidence in, and that they commit to following the process reliably.

Objectives

 * 1) Enable the work group participants to develop high-quality software efficiently and effectively.
 * 2) Maximize the value of the participants’ commitment of time and expertise.

Constraints

 * 1) The work group must be populated by participating companies and individuals who have an interest in achieving the objectives of the work group, and who are able to commit time and expertise to the group sufficient to do so.

Assumptions

 * 1) The workgroup has access to a shared code development platform, providing artifact version control, continuous integration system, a forum or bulletin board for asynchronous discussions, an issue management system, and support for workflow execution and management.
 * 2) The workgroup participants will provide code development to the work group as a contribution, and the participant staff making that contribution are familiar with general software development best practices.

Principles

 * 1) Development follows design; design follows architecture. Detailed designs must harmonize with system design, which must harmonize with the architecture.
 * 2) Plan first, implement after. Document detailed design of planned unit of work before starting the work. Amend the design as necessary as the work progresses.
 * 3) Quality assurance is paramount. Unit tests, smoke tests, and peer review are essential.
 * 4) Developers are independent contributors collaborating to achieve a common objective.
 * 5) The integrity and continuous functionality of the codebase are paramount. All code must be unit tested and smoke tested before being committed to the codebase. This ensures that the build will succeed and the functionality of the product is preserved.

Prerequisites

 * 1) All contributors will be committed participants in the work group.
 * 2) All contributors will be committed to deliver the products or services for which they have signed up.
 * 3) The work of the work group will be divided into discrete tasks in some manner to be determined by the work group participants. Tasks will include code development and defect remediation, design development, documentation development and amendment, peer reviews, and other tasks at the discretion of the participants.
 * 4) Those tasks will be listed in the shared development environment in such a way that participants can sign up to complete them.
 * 5) A project will be established at a hosted open source development facility for use by the contributors.
 * 6) All contributors may be made fully privileged members of that project, or some contributors may be committers. //(Please comment: Need to determine if group will use a flat or hierarchical model)//

Operations
Contributors may commit to deliver source code, design documents, other documentation, peer reviews, or any combination thereof, by attaching their names to tasks listed in the shared environment.

//**Design Development**//
Code development work associated with a task will begin with the development of a detailed design. The detailed design will extend or elaborate the over-arching system design. In the event that the development of the detailed design identifies a need to amend the system design, such changes must be agreed upon by some quorum of the work group participants. The nature of that quorum is to be decided by the participants at the beginning of the work group’s operation.

The detailed design documentation should be only as voluminous as necessary to make clear the intended functionality and its implementation. The design should include prose describing the purpose, assumptions, constraints, and theory of operation of the implementation, and should include Unified Modeling Language (UML) diagrams as necessary.

When a design is ready, the design developer will commit it to the shared version control archive. In the changeset commit comments, the developer will include the keywords necessary to link the design to the issue addressed and to request peer review of it.

//**Code Development**//
Contributors will initially and regularly update their local working copies of the codebase.

Contributors will develop code on their local systems. All new code developed will be accompanied by unit tests that exercise and validate the functionality of the code. Automatically generated code such as JavaBean constructors, accessors, and mutators need not be tested. All hand-written code must be covered by unit test code.

All code will be made stylistically consistent, whether by means of a common style checker or manually.

When new or changed code is ready to be committed to the shared codebase, the committer will use the following procedure.
 * Execute the style checker on the changed items, and remediate any style defects identified.
 * Synchronize the local codebase with the shared codebase. Resolve any synchronization conflicts before proceeding.
 * Perform a full build on the local system, and ensure that it yields no errors in compilation, resource binding, or unit testing. If any errors occur, resolve them and return to the previous step.
 * Commit the new code to the shared codebase in a single changeset. In the changeset commit comments, include the keywords necessary to link the changeset to the issue addressed and to request peer review of it.

//**Peer review**//
Contributors who commit to performing peer review must respond promptly to each submission for review. The required timeframe for such responses should be agreed upon by the work group participants at the beginning of the development process.

Peer reviewers will evaluate each design submission according to the criteria detailed in Appendix A – Design Review Checklist.

Peer reviewers will evaluate each code submission according to the criteria detailed in Appendix B – Code Review Checklist.

If the peer reviewer approves the submission, s/he will add a comment to that effect to the issue commentary.

If the peer reviewer does not approve the submission, s/he will add a comment to that effect to the issue commentary. S/he will also contact the developer to convey the reasons why the submission was rejected.

If a submission is rejected, the developer must immediately remediate the defects identified by the reviewer, commit the necessary changes to the codebase, and request a second peer review.

Details
//Here should be recorded detailed project-specific information concerning the hosting platform and facility, source/design/documentation repo, orientation and help files, and so forth.//

Please follow the links below for additional development process guidance: