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. |
| 264 | ---- |
| 265 | = Old design notes = |
| 266 | |
| 267 | (I'm reworking these into a better flow for the whole document.) |
| 268 | |
| 269 | A Gantt plugin for Trac should analyze ticket dependencies and produce an interactive, explorable Gantt chart showing task progress and project status. |
| 270 | |
| 271 | 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. |
| 272 | |
| 273 | == What do we need in the back end ? == |
| 274 | |
| 275 | 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. |
| 276 | |
| 277 | To effectively display project progress, tickets must have estimated and actual times as in the TimingAndEstimation plugin. |
| 278 | |
| 279 | It is also desirable to have loop detection to error-proof the tool used to create dependencies. |
| 280 | |
| 281 | It 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 | |
| 285 | A "chart these" button on a report page would be very nice. |
| 286 | |
| 287 | Tasks in the chart should be links to the tickets they represent (preferentially opened in a separate tab or window). |
| 288 | |
| 289 | Milestones should be displayed in the chart as well. |
| 290 | |
| 291 | The chart should support interactively "folding" groups of tasks to hide detail. |
| 292 | |
| 293 | Zooming in order to see the WBS in more detail. |
| 294 | |
| 295 | Panning or scrolling in order to display the schedule at a different time. |
| 296 | |
| 297 | Each task's bar in the chart should show actual hours. |
| 298 | |
| 299 | The chart should have a Today line. |
| 300 | |
| 301 | The chart (or an accompanying report or tool) should aid in resource leveling by (at least) showing overcommitted resources. |
| 302 | |
| 303 | Visual indications about delays, task completion and other significant events. |
| 304 | |
| 305 | 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. |
| 306 | |
| 307 | = Design guidelines = |
| 308 | |
| 309 | 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. |
| 310 | |
| 311 | == Components == |
| 312 | |
| 313 | In order to add flexibility to the final solution, the '''MVC pattern''' ''should'' be considered during its development. |
| 314 | Hence the following components need to be implemented in order to add Gantt charts to Trac. |
| 315 | |
| 316 | === The Model === |
| 317 | |
| 318 | It 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 | |
| 331 | It ''should'' be a JavaScript component (is this possible ?) responsible for rendering the data provided by ''the model''. |
| 332 | Besides 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 | |
| 342 | 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) : |
| 343 | |
| 344 | - Replace the JS-based view by another made with Flash. |
| 345 | - Use a custom, or specific estimation strategy. |
| 346 | |