Changes between Version 31 and Version 32 of ProjectManagementIdeas


Ignore:
Timestamp:
Apr 29, 2009, 9:47:09 PM (8 years ago)
Author:
ChrisNelson
Comment:

Start to reorganize design notes

Legend:

Unmodified
Added
Removed
Modified
  • ProjectManagementIdeas

    v31 v32  
    155155 * [http://openproj.org/openproj OpenProj] also appears to be a desktop application.  However, their [http://openproj.org/wiki/index.php/Available_Views views] page may guide development of PM output for Trac.
    156156 * [http://www.ganttproject.biz/ GanttProject]'s website isn't very informative but it appears to be a desktop application.
    157 
    158 = Design =
    159 
    160 A Gantt plugin for Trac should analyze ticket dependencies and produce an interactive, explorable Gantt chart showing task progress and project status.
    161 
    162 By "project", I mean a set of related milestones.  Perhaps a software project has a Design Phase, an Alpha Release, a Beta Release, and a General Release.  Each phase would have a milestone with a target date and tickets to complete the work for that phase.  There must be a way to specify which milestones to include either listing explicitly or by giving a pattern or substring filter.
    163 
    164 == What do we need in the back end ? ==
    165 
    166 The chart should be able to show all tickets (though that may be a very complex chart) or alternately all those tickets matched by a (query | report) or any other ticket group provider. 
    167 
    168 To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin. 
    169 
    170 It is also desirable to have loop detection to error-proof the tool used to create dependencies.
    171 
    172 It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks.
    173 
    174 == What do we need in the user interface ? ==
    175 
    176 A "chart these" button on a report page would be very nice.
    177 
    178 Tasks in the chart should be links to the tickets they represent (preferentially opened in a separate tab or window).
    179 
    180 Milestones should be displayed in the chart as well.
    181 
    182 The chart should support interactively "folding" groups of tasks to hide detail.
    183 
    184 Zooming in order to see the WBS in more detail.
    185 
    186 Panning or scrolling in order to display the schedule at a different time.
    187 
    188 Each task's bar in the chart should show actual hours.
    189 
    190 The chart should have a Today line.
    191 
    192 The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources.
    193 
    194 Visual indications about delays, task completion and other significant events.
    195 
    196 It would be nice to be able to create task dependencies graphically using the Gantt chart as a GUI or to change a milestone date by dragging it along the chart.
    197 
    198 = Design guidelines =
    199 
    200 In order to agree about how to implement this functionality, the very first step should be to describe the possible architectures (i.e., how the different components are going to interact with each other since the moment the request is sent by the client until the Gantt chart is rendered by the browser) that will be considered.
    201 
    202 == Components ==
    203 
    204 In order to add flexibility to the final solution, the '''MVC pattern''' ''should'' be considered during its development.
    205 Hence the following components need to be implemented in order to add Gantt charts to Trac.
    206 
    207 === The Model ===
    208 
    209 It provides the data in the Gantt chart and is not just a single element but a set of components like the following :
    210 
    211     * The ticket models, which provide data about the issues found
    212       in the project environment
    213     * Trac query mechanism which provides a way to select (filter) the
    214       tickets being shown.
    215     * [#RelatedWork Other plugins] used to track ticket dependencies
    216     * [#RelatedWork Other plugins] used to track task/subtask relationships
    217     * [#RelatedWork Other plugins] used to estimate the time needed to finish the given tasks
    218     * Maybe one (a few) component(s) whose role is to provide the functionality specific to Gantt charts, thus acting as a central access point and a mediator so as to put all the other components together.
    219 
    220 === The View ===
    221 
    222 It ''should'' be a JavaScript component (is this possible ?) responsible for rendering the data provided by ''the model''.
    223 Besides it ''might'' support [#Whatdoweneedintheuserinterface other dynamic features]
    224 
    225 === The Controller ===
    226 
    227 {{{
    228 ¿What do we need this for?
    229 }}}
    230 
    231 === Implications ===
    232 
    233 The aforementioned separation ''should'' allow the replacement of any of the components involved. Hence the following modifications ''should'' be made easily (the list being intentionally incomplete) :
    234 
    235   - Replace the JS-based view by another made with Flash.
    236   - Use a custom, or specific estimation strategy.
    237157
    238158= Roadmap =
     
    342262
    343263However, this doesn't seem to be all the data Project records for a task.  If you add a column to the WBS in the Gantt chart, there are many more options.  The most interesting is Work which is the amount of work required to complete a task.  Only when a resource is assigned 100% are Work and Duration the same.  We'd like to be specify the ''work'' required for a task and let the system calculate its ''duration'' based on available resources.
     264----
     265= Old design notes =
     266
     267(I'm reworking these into a better flow for the whole document.)
     268
     269A Gantt plugin for Trac should analyze ticket dependencies and produce an interactive, explorable Gantt chart showing task progress and project status.
     270
     271By "project", I mean a set of related milestones.  Perhaps a software project has a Design Phase, an Alpha Release, a Beta Release, and a General Release.  Each phase would have a milestone with a target date and tickets to complete the work for that phase.  There must be a way to specify which milestones to include either listing explicitly or by giving a pattern or substring filter.
     272
     273== What do we need in the back end ? ==
     274
     275The chart should be able to show all tickets (though that may be a very complex chart) or alternately all those tickets matched by a (query | report) or any other ticket group provider. 
     276
     277To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin. 
     278
     279It is also desirable to have loop detection to error-proof the tool used to create dependencies.
     280
     281It would be nice to be able to choose an As Late As Possible or As Soon As Possible algorithm for laying out tasks.
     282
     283== What do we need in the user interface ? ==
     284
     285A "chart these" button on a report page would be very nice.
     286
     287Tasks in the chart should be links to the tickets they represent (preferentially opened in a separate tab or window).
     288
     289Milestones should be displayed in the chart as well.
     290
     291The chart should support interactively "folding" groups of tasks to hide detail.
     292
     293Zooming in order to see the WBS in more detail.
     294
     295Panning or scrolling in order to display the schedule at a different time.
     296
     297Each task's bar in the chart should show actual hours.
     298
     299The chart should have a Today line.
     300
     301The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources.
     302
     303Visual indications about delays, task completion and other significant events.
     304
     305It would be nice to be able to create task dependencies graphically using the Gantt chart as a GUI or to change a milestone date by dragging it along the chart.
     306
     307= Design guidelines =
     308
     309In order to agree about how to implement this functionality, the very first step should be to describe the possible architectures (i.e., how the different components are going to interact with each other since the moment the request is sent by the client until the Gantt chart is rendered by the browser) that will be considered.
     310
     311== Components ==
     312
     313In order to add flexibility to the final solution, the '''MVC pattern''' ''should'' be considered during its development.
     314Hence the following components need to be implemented in order to add Gantt charts to Trac.
     315
     316=== The Model ===
     317
     318It provides the data in the Gantt chart and is not just a single element but a set of components like the following :
     319
     320    * The ticket models, which provide data about the issues found
     321      in the project environment
     322    * Trac query mechanism which provides a way to select (filter) the
     323      tickets being shown.
     324    * [#RelatedWork Other plugins] used to track ticket dependencies
     325    * [#RelatedWork Other plugins] used to track task/subtask relationships
     326    * [#RelatedWork Other plugins] used to estimate the time needed to finish the given tasks
     327    * Maybe one (a few) component(s) whose role is to provide the functionality specific to Gantt charts, thus acting as a central access point and a mediator so as to put all the other components together.
     328
     329=== The View ===
     330
     331It ''should'' be a JavaScript component (is this possible ?) responsible for rendering the data provided by ''the model''.
     332Besides it ''might'' support [#Whatdoweneedintheuserinterface other dynamic features]
     333
     334=== The Controller ===
     335
     336{{{
     337¿What do we need this for?
     338}}}
     339
     340=== Implications ===
     341
     342The aforementioned separation ''should'' allow the replacement of any of the components involved. Hence the following modifications ''should'' be made easily (the list being intentionally incomplete) :
     343
     344  - Replace the JS-based view by another made with Flash.
     345  - Use a custom, or specific estimation strategy.
     346