From OpenBrainstem

One of the most important things that good Software Engineers can do is to establish common practices and guidelines for everyone on the team to follow. This includes such items as CM commit schedules & comment guidelines, a house style for code formatting, code acceptance procedures, bug assignment & tracking, regression testing control and release management.

Contents 1 Software Engineering Process & Methodology 2 Operating Procedures 2.1 House Style 2.2 Configuration Management (a.k.a. CM) 2.3 Regression Testing & Release Management

[edit] Software Engineering Process & Methodology

At OpenBrainstem, we always design first, document second and code third. The proper series of events is:

• Design
  • Stated feature set
  • DB schema
  • Business logic flowcharts
  • System architecture
• Document
  • Use cases
  • User documentation
  • Administrator Documentation
• Design (again)
  • API Documentation
  • Refine other elements
  • Update all documentation
• Write unit tests
• Write code which passes the unit tests
• Rinse & repeat

It is absolutely vital to never allow "feature creep" after the first design cycle. New/additional features should be placed on the next-version list. The only exception to this rule is when a flaw in the design is discovered during later stages of the document-design-document cycle, that must be fixed for the current feature list to be viable, then either the affected feature(s) should be pushed off to the next version or the new feature(s) should be included. In the later case, we must then go back to the beginning and start over to ensure that nothing is missing.

[edit] Operating Procedures

These sub-sections cover more fine-grained details of how to write code with/for OpenBrainstem projects.

[edit] House Style

For most programming languages, there are many ways in which the source code can be formatted. If each person writing code for a project were to do things his/her own way, then you would quickly find that there are N < X < N², where N is the number of programmers and X is the number of different formatting and/or coding styles. In other words, it gets way out of hand at a speed that will peel your eyelids.

[edit] Configuration Management (a.k.a. CM)

bzr is the main CM system for OpenBrainstem.

We considered several other Version Control Systems when we decided on bzr.

[edit] Regression Testing & Release Management

These two categories go hand in hand. At OpenBrainstem, the Release Manager is ultimately responsible for signing off on all Regression and other testing of code prior to release. The Release Manager has the authority to block the release of a new version of their project.