1  # Task management
  2  
  3  Bachelorizer follows kanban principles for task management,
  4  using roadmap (described below) as a form of kanban board.
  5  
  6  Kanban is a japanese management method
  7  of visually placing signs (kam) on a board (ban),
  8  intended to to aid in breaking down a project into smaller tasks
  9  to support team-based self-organization
 10  [@Anderson2016, pp. xi-1].
 11  
 12  Two core principles of kanban
 13  is to visually present an overview of tasks
 14  as a way of identifying them,
 15  and
 16  associating tasks with a progress state
 17  as a way of managing flow of progress.
 18  Commonly a two-dimensional kanban board provides overview,
 19  with individual tasks listed vertically
 20  and divisions of task states horizontally
 21  [@Anderson2016, p. 18].
 22  One of the aims of these principles is
 23  to establish a sense of sustainability
 24  in the pace of working on the tasks involved in a project
 25  [@Anderson2016, pp. 7-8].
 26  
 27  With Bachelorizer,
 28  the tool roadmap is used for visualizing the tasks.
 29  Reason for this choice is an interest in creating an atmosphere
 30  supportive of creative thinking and reflective learning
 31  rather than efficiency,
 32  for which the assembly line metaphor of conventional kanban boards
 33  is considered counterproductive.
 34  
 35  Roadmap is a command-line tool
 36  to generate a somewhat organic looking graph-based tree of tasks
 37  from a plaintext source task list.
 38  Roadmap takes as argument a filename for a YAML-structured list of tasks,
 39  validates that all tasks are related as a directed acyclic graph (DAG)
 40  with only a single end node (a tree structure),
 41  and renders to stdout an SVG format visual diagram of the tasks.
 42  The diagram maps out the tasks and their relationships,
 43  with prioritized actionable tasks as green circles,
 44  other actionable tasks as white circles,
 45  later tasks as red pentagons,
 46  blocked tasks as orange rectangles
 47  and finished tasks as grey hexagons.
 48  Each task is defined with a keyword and a label in the YAML file,
 49  optionally adding an explicit state
 50  of either *finished*, *ready*, *next* (meaning prioritized) or *blocked*,
 51  and listing directly dependending task.
 52  Task state is resolved from dependencies if not stated explicitly;
 53  only one task, the final goal, can and must have no dependencies.
 54  After each YAML file edit the visual diagram can be (re)generated,
 55  which also checks
 56  that the edited YAML contents is structurally and semantically valid.
 57  [@Wirzenius2025].
 58  
 59  For comparison with conventional kanban boards,
 60  roadmap visualizes not as a 2-dimensional matrix
 61  with progress as rigid lines across the x-axis
 62  and sustainability indicated by downwards depth,
 63  but instead visualizes as a somewhat organic looking tree structure,
 64  with progress as neat (non-warning-colored) branches
 65  and sustainability indicated by color saturation.
 66  
 67  The requirements for the first portfolio delivery for Bachelorizer
 68  are summarized as the following tasks:
 69  
 70   1. Make a Kanban board for this assignment.
 71   2. Make a class diagram for the Bachelor programme and its components.
 72   3. Implement classes to represent the Bachelor programme and its components.
 73   4. Implement a method to check whether a programme is valid.
 74   5. Specify and run unit tests for the valid method.
 75  
 76  These larger tasks have been expanded and reorganized
 77  into more smaller and narrower focused ones,
 78  visualized in the roadmap at @fig-kanban.
 79  
 80  ![Early roadmap for Bachelorizer](roadmap_early.svg){#fig-kanban}
 81  
 82  ## Diagram
 83  
 84  We ideally wanted to create activity classes in relation to databases
 85  to integrate parts with each other,
 86  but we ran short on time.
 87  Portfolio 1 might therefore seem less structured than the other parts.
 88  
 89  A simple UML showing an early draft idea for portfolios 1-3 as 1 program is shown on @fig-draft.
 90  
 91  ![UML Class Diagram for Bachelorizer](classes.svg){#fig-draft}
 92  
 93  
 94  A simpler diagram is shown on @fig-final,
 95  trying to account for types and requirements for a correct program.
 96  
 97  ![Minimum diagram for portfolio1](diagram.svg){#fig-final}
 98  
 99  ## Validity of bachelor programmes
100  
101  The isValid() function in the Programme class
102  currently works by checking which type an activity has based on
103  the result of activity.toString().
104  It simply runs through every activity and adds 1 to a counter for each category.
105  It calculates ECTS based on getEcts() for each activity,
106  originally supplied by a long list of object declarations in the Main class.
107  This could very well be integrated with the database to get more and accurate
108  information about each activity,
109  but time pressure has prevented us from this implementation,
110  even though the project structure easily allows it.
111  The expected values for count and total ECTS for validation supplied
112  by the assignment description is then validated in a simple return statement.
113  
114  The unit tests simply create example programmes similar to what is done in main
115  and then calls the isValid() function to compare to expected values.
116  Other unit tests could explore edge cases.
117  For example,
118  the current structure of the classes does not truly differentiate between
119  the subject modules that activities are part of,
120  so it has no way of enforcing that subject module activities
121  are part of exactly 2 subject modules.
122  Another implementation that could pass such a unit test would need
123  each activity to have an attribute describing which subject module it is part of.