Difference between revisions of "OOPM:Development:Documentation:Development Process"
From Apache OpenOffice Wiki
(6 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
{{Template:OOPM:Templates:Documentation:Shared: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}} | {{Template:OOPM:Templates:Documentation:Shared: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 information | + | Side Notice: part of the below information is based on existing project processes and project management methodologies in the agile PM area. |
;Process | ;Process | ||
Line 12: | Line 12: | ||
* iterative and hopefully "agile" 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, | ** 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 | + | :: 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 | * 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 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 | * 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 | ||
Line 29: | Line 31: | ||
* continuous integration applies | * 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 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 | ;Versioning/Branching |
Latest revision as of 17:05, 8 May 2009
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 ;)