OOPM:Development:Documentation:Development Process

TBD make this use the single page, unversioned document template

Development Process

TBD this is currently a stub, we will continue improving this article in the near future as soon as the issues have been settled and the general direction of development was given

Side Notice: part of the below information is based on existing project processes and project management methodologies in the agile PM area.

Process

• iterative and hopefully "agile" process
  • however, we will not be using an adhoc process whilst developing in the alpha alpha or subsequent, more stable phases of our product,

adhoc only applies to the prototype phases, for example the proto proto phase to up until the proto beta phase, or the alpha proto/beta proto/stable proto phases, where new features will be added from scratch.

• we will use assigned roles and assigned tasks

every change to our software system, except during the initial prototyping and learning phase will be based on assigned tasks, also given a fore-front specification of what must be done

members of the project will be assigned one to multiple roles, the roles we will still have to define and document in this wiki

• we will be using change package oriented development, i.e. goals set forth in the individual iteration statements in this wiki and we will integrate the issue tracker
• we will use the bug/issue tracker for capturing our advancement during development and we will check-in so that we can track down individual changes made to

the individual change packages set forth by the issues in the issue tracker

• source release oriented

we will do source releases until we reach the public beta phase

until then we will not fuss around with build numbers and the likes

and, when we reach the public beta phase, we will use the revision number part of our binary release version for the actual build number instead

of introducing yet another versioning scheme

TBD move above information to OOPM:Development:Documentation:Versioning

• test driven development -- since we set out to create a headless backend we can test the backend incl also the datamodel using automated tests, for the user interface we will have to yet define the testing suites that we will use
• we will be using multiple subprojects for our software system, and by that also multiple locations in the cvs

at least one per component or bundle of associated components, e.g. type libraries and so on

for integration we will be using a second component that will feature the toolings required to fully integrate the existing components into either backend or frontend

• continuous integration applies

we will be using the ci facilities provided by the OOo project, requires more research into available toolings/tool chains though

• we will do architecture and design incl. also specification prior to actual development to assure that we will always deliver a (rather) stable product once it has been released and future feature development takes place
• we will be doing feature development and maintenance development, for this we will use so-called (feature) development branches and maintenance branches with the individual components of our software system
• in accordance to the VModell-XT, we will establish multiple review boards (change review boards etc.)

one for the evolving requirements analysis document

one for the evolving architecture and design document(s)

one for the evolving specification document(s)

multiple for the evolving software (backend/frontend)

one for the process that we are currently running and that will evolve over time

one for the available developer documentation

one for the available end-user documentation

for documentation of the above reviews and for the review boards in general we will be using both the wiki and also the issue tracker

for more information see the initial iteration statement for OOPM:Development:Releases:1.0.0 proto proto:Iterations:1

• we should definitely consider using subversion (svn) instead of cvs

Versioning/Branching

See existing document on versioning OOPM:Development:Documentation:Versioning

• release state denotes overall development state, e.g. proto for a prototype, alpha, beta, stable and so on
• version state denotes overall state of the release version, e.g. proto for a prototype, alpha, beta, stable and so on
• upon stabilization for a (final) stable release, we will be using release candidates before we will ship the then hopefully stable version to the public

Q/A

• we will use closed (internal) prototype testing
• we will use closed (internal) alpha testing
• we will use public beta testing
• we will use public release candidate testing
• stable banana releases we provide will also use a public testing process ;)