Changes between Version 31 and Version 32 of ProjectManagementIdeas


Ignore:
Timestamp:
Apr 29, 2009 9:47:09 PM (5 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