Difference between revisions of "User:Carsten.klein"

From Apache OpenOffice Wiki
Jump to: navigation, search
(→‎TODO)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
== Notice ==
 +
 +
Most of the below presented is actually more of a notice to myself than for actual public consumption. Be warned.
 +
 +
== TODO ==
 +
 +
; Releaseplanning and Iterationplanning
 +
: In accordance with the APM we should definitely go the route of ahead release planning and iteration planning
 +
: what basically means that, that after we have captured all of the requirements in the requirements analysis document,
 +
: we define the Release 1.0.0 stable stable features. From these features we will then derive the features to be implemented
 +
: during the multiple iterations, the so-called iteration features. From these features then we will create the actual
 +
: tasks that then will be managed in the central project plan.
 +
: This requires that the currently defined [[Template:OOPM:Templates:Documentation:Development:ReleaseIterationStatement:1.0]]
 +
: needs to be revised and extended see [[User_talk:Carsten.klein]] Launchpad for more information.
 +
; Project Teams
 +
: As of now, the overall number of persons attending to the project is rather low (approx 1/10th of a person right now;).
 +
: However, as the OOPM will gain momentum, more people will want to join the project, so we must plan ahead in that
 +
: we define multiple project teams forefront.
 +
: Due to team dynamics, successful teams should not be changed. However, and especially in that phase of the
 +
: project, where we actually attract more people, we might want to split existing teams in order to get new people
 +
: up to speed faster.
 +
: Each team features a team lead and a person that is responsible for managing the team schedule and also
 +
: the team's iterations feature plans. The latter one may change often, team leads should no be exchanged.
 +
:; Project Management Team
 +
:: Responsible for setting up the release plan. Should recruit itself from the individual team leads or rather the person
 +
:: from the team that is currently responsible for maintaining the team's personal schedule.
 +
:: For now the project management team will also take over marketing concerns etc.
 +
:; Development Teams
 +
:: Responsible for actual (test-driven) software development. Also responsible for build and integration.
 +
:: Multiple such development teams can exist in the future, with teams working on individual components
 +
:: of the software.
 +
:: Besides that, the development teams will also be responsible for the requirements analysis document and
 +
:: the architecture and design document.
 +
:; Testing and Reviewing Team
 +
:: Responsible for both testing and reviewing of both generated (documentation) content an the software itself.
 +
:: Multiple such testing and reviewing teams can exist in the future, with teams working on individual
 +
:: parts of the software system, for example documentation, the project, and of course the software itself.
 +
:: In the future we might even split up the testing and reviewing teams into two separate entities.
 +
 +
== Offline Notices ==
 +
 +
<pre>
 +
Since I currently do not have any direct internet access at my home office,
 +
I will provide here a schedule of when I am not able to continue my work
 +
on the OOPM project on a more regular basis
 +
 +
* 2009-04-11 - 2009-04-19
 +
* 2009-05-22 - 2009-06-?? (2G/GPRS connection only, it definitely sucks)
 +
</pre>
  
 
== Current Work ==
 
== Current Work ==
Line 9: Line 58:
 
: based on processes/workflows, utilizing a processing engine in the backend, like for example the JBPM
 
: based on processes/workflows, utilizing a processing engine in the backend, like for example the JBPM
 
* defining a basis for getting the real requirements analysis, based on a domain based analysis, up and running
 
* defining a basis for getting the real requirements analysis, based on a domain based analysis, up and running
−
 
−
== TODO ==
 
−
 
−
* add missing templates for
 
−
** release categories
 
−
** arbitrary documents
 
−
*** e.g. requirements analysis document, architecture and design documents, specifications, end user documentation etc.
 
−
*** header: meta
 
−
*** sections: chapter, paragraph
 
−
* add missing documentation/howtos on how to establish a working per release documentation basis
 
−
* add missing documentation/howtos on how to establish a working document management system using the wiki
 
−
** incl. versioned documentation regardless of wiki defined versioning (i.e. page revisions)
 
−
* continue with the initial requirements analysis based on the available wish list
 
−
* continue with the initial architecture proposal
 
−
* continue defining the initial iteration for starting the whole shebang of actual software development
 

Latest revision as of 13:53, 12 June 2009

Notice

Most of the below presented is actually more of a notice to myself than for actual public consumption. Be warned.

TODO

Releaseplanning and Iterationplanning
In accordance with the APM we should definitely go the route of ahead release planning and iteration planning
what basically means that, that after we have captured all of the requirements in the requirements analysis document,
we define the Release 1.0.0 stable stable features. From these features we will then derive the features to be implemented
during the multiple iterations, the so-called iteration features. From these features then we will create the actual
tasks that then will be managed in the central project plan.
This requires that the currently defined Template:OOPM:Templates:Documentation:Development:ReleaseIterationStatement:1.0
needs to be revised and extended see User_talk:Carsten.klein Launchpad for more information.
Project Teams
As of now, the overall number of persons attending to the project is rather low (approx 1/10th of a person right now;).
However, as the OOPM will gain momentum, more people will want to join the project, so we must plan ahead in that
we define multiple project teams forefront.
Due to team dynamics, successful teams should not be changed. However, and especially in that phase of the
project, where we actually attract more people, we might want to split existing teams in order to get new people
up to speed faster.
Each team features a team lead and a person that is responsible for managing the team schedule and also
the team's iterations feature plans. The latter one may change often, team leads should no be exchanged.
Project Management Team
Responsible for setting up the release plan. Should recruit itself from the individual team leads or rather the person
from the team that is currently responsible for maintaining the team's personal schedule.
For now the project management team will also take over marketing concerns etc.
Development Teams
Responsible for actual (test-driven) software development. Also responsible for build and integration.
Multiple such development teams can exist in the future, with teams working on individual components
of the software.
Besides that, the development teams will also be responsible for the requirements analysis document and
the architecture and design document.
Testing and Reviewing Team
Responsible for both testing and reviewing of both generated (documentation) content an the software itself.
Multiple such testing and reviewing teams can exist in the future, with teams working on individual
parts of the software system, for example documentation, the project, and of course the software itself.
In the future we might even split up the testing and reviewing teams into two separate entities.

Offline Notices

Since I currently do not have any direct internet access at my home office,
I will provide here a schedule of when I am not able to continue my work
on the OOPM project on a more regular basis

* 2009-04-11 - 2009-04-19
* 2009-05-22 - 2009-06-?? (2G/GPRS connection only, it definitely sucks)

Current Work

Currently I am working on getting the OOPM project up to speed by

  • developing an infrastructure incl. templating in the wiki for future documentation purposes
  • making up an initial architecture proposal for the OOPM application, or rather "the solution", based on former research done for a similar project
of mine, called the hpm, a hierarchical, multi project management solution, featuring inter-project dependencies and so on, which is inherently
based on processes/workflows, utilizing a processing engine in the backend, like for example the JBPM
  • defining a basis for getting the real requirements analysis, based on a domain based analysis, up and running
Retrieved from "https://wiki.openoffice.org/w/index.php?title=User:Carsten.klein&oldid=131569"
Personal tools