GOLL-E
Project Planning Document
by The Standard Deviants:
Salvador Abate
Julian Boilen
John O’Brien
Morgan Cabral
Robert Gilmore
Goll-e, the Graphical Object Language and Layout Editor will be an open-source, browser-based tool that allows users to create, view, and modify directed graphs, as well as specify custom layouts and styles.
The product consists of a markup language, a graphical editor, and a visualization tool for the resulting graphs. The language component of this project aims to invent a textual language for describing nodes, edges, and groupings in a graph. This language will allow people and scripts to create graphs from data, and will be consumed by the editor component.
The intended use case for the product is visualising functional programming trees, network flow diagrams, and architecture diagrams. Existing graph visualisation tools do not support a mix of manual and automatic layout and perform poorly when the number of nodes exceeds a few hundred. Our hope is to do better than current solutions in those two capacities.
We will conduct this project according to the Scrum process methodology in a series of two-week sprints, working on the language, the layout algorithms, and the editor in parallel.
Goll-e, the Graphical Object Language and Layout Editor is a combination of Graphing language, an interpreter, and a visualizer. The graphing language will allow users to specify nodes and how they interact with each other. Additionally things such as colors, styles, and “animations” on said nodes. The interpreter will take the graphing language files and create a the backend structures of graph. The visualizer will create a visual interpretation of the graphs and allow users to modify the graph as needed. The user will be able to move the location of nodes and those changes will be saved over the iterations of the graph. This will allow users to create a more readable graph even as they are changing data in it.
The “releases” will be cycled with our two week sprints and will be at the end of each sprint. We want to be able to define specific functional or visible goals for each sprint in order to be able to show the progress to the sponsor. These are subject to change as the project progresses.
Deliverable | Release |
Project Plan Document (this document) | Pre Release 1 |
Website set up | Pre Release 1 |
Major User Stories | Pre Release 1 |
Text Language for Data Model | Release 1 |
Non-functional GUI Prototype | Release 1 |
Automatic Layout of Graph | Release 2 |
Basic Layout Editing | Release 3 |
Saving/ Loading layouts | Release 3 |
Grouping & Hierarchy | Release 4 |
Enhance Language to define Styles | Release 5 |
Enhance Language to attach styles to nodes & edges | Release 5 |
Formatting changes viewable in GUI | Release 6 |
Pop-up element metadata | Release 7 |
Node and Edge Highlighting | Release 7 |
Views | Release 8 |
API to change objects | to be determined |
In-Browser graph language editor | to be determined |
ID | Risk Description | Risk Impact | Risk Mitigation | Probability of Occurring | Status |
1 | Senior Project VM is not delivered before September 9th | Delayed setup of project tools such as user accounts, tools, JIRA, etc. | Look at VPS Providers | 50% | Risk Occurred |
2 | Senior Project VM does not have more than 1GB of RAM | Cannot self-host JIRA on RIT hardware | Ask Kurt to increase the VM memory size. | 75% | Kurt increased VM RAM allocation to 2GB |
3 | We encounter issues setting up JIRA or one of the plugins we intend to install | Instability and/or unavailability of the project’s JIRA | Use one of Atlassian’s hosted JIRA instances. Pay ~$10 for the basic tier of support. | 10% | |
4 | The frontend web framework we choose to implement the project turns out to not be a good fit | May require us to go back and refactor portions of our project, depending upon when/if the risk is realized | Put increased effort into picking a framework that fits our needs Be vigilant about ensuring that our tools fit our needs. Bring up issues during team meetings. | 10% | |
5 | The process model we choose does not fit our needs | Lost productivity from an unworkable/inefficient process model | Get feedback of our choice of process model from the sponsor and from the team coach. Continually evaluate the effectiveness of our process model. Address specific issues as they occur. | 10% | |
6 | Bad at estimating sprints due to lack of past metrics! | 20% |
Our project will follow the agile Scrum process model, which will help dictate our development schedule. Starting in semester 1, week 5, we will begin a series of two-week Sprints. The team will divide work into separate subteams following tracks that can be worked on separately and concurrently. These subteams may vary in size depending on the work, e.g. as the system develops features can be worked on more separately. Each sub-team will determine the items in the Sprint backlog. Scrum is heavily metrics-based, and we will use scrum’s metrics to determine the size of each sprint. First, stories (tasks) will be estimated using the story point system. Our measured velocity, other metrics, and stories left in the backlog will help refine future scheduling. See the Measurements and Metrics section of this document for more details.
We will also set over-all deadlines for major milestones in our project. The only milestone set thus far is to finish Part A of the requirements (The Basic Requirements), which describes the majority of the minimum viable product by the end of the first semester. All stories for Part A will be added to the backlog before the beginning of the first sprint. Future milestones will be in week 13 of the first semester, when they can be more accurately determined.
Through the collection of measurements and metrics, we hope to assess the quality of the product, track progress towards completion and the likeliness of meeting the deadline, and identify sources of estimation inaccuracy. To this end, we are collecting the following:
We chose velocity because it is the main metric around which scrum is based. We chose “Discovered Work” and “Scope Change” because they complement each other in a meaningful way. Together, they are the change in story points remaining, but each type of change comes from a different source. We can respond to problems more appropriately by isolating these two metrics. For example, if discovered work is very high, then we have a problem with estimation; we need to re-estimate the story points assigned to each user story. On the other hand, if the scope change is high, then we must give consideration to whether our user stories accurately reflect the given requirements.
From these, we will plot a running burn-down chart with the help of Jira’s Agile plugin. This will help us and the sponsor to see our projected time to completion.
In keeping with the sponsor’s request for extensive testing, we are keeping track of test coverage as well.
Our team has chosen Scrum as our Process Model. Scrum provides a good middle ground between agile methods that focus on iterative prototyping methods like Extreme Programming and fixed, traditional waterfall methods. We believe the concepts of a backlog and milestones are very compatible with the sections the requirements are presented in. The sponsor has indicated a preference for this process model, as it is what they use. The sponsor has requested a sprint length of two weeks.
Scrum requires many metrics, tracking tools, and tools to maintain the backlog and manage sprints. We will be using Atlassian JIRA for all these. JIRA will allow us to record and manage the internal artifacts including the backlog, sprints, time estimates and time spent. From those, JIRA will calculate metrics such as the critical Burndown Chart and others detailed in the Metrics section of this document.
Scrum will be somewhat modified for the specifics of this project. Because we will only be working about 50-100 man-hours/week, daily meetings would not be useful, so our twice-weekly meeting will be sufficient. We have also decided on a rotating scrum-master. We have created a schedule where a new scrum master will manage each sprint.
This document will be updated throughout the project with details such as the test plan, metric results, and other artifacts as they are created.
/