Project poster planning - hamstar/Braincase GitHub Wiki
See also: #305
Assessment details
Content 50%
- Outlined project concept/rationale
- Products (e.g architecture, models, deisgn, software, client deliverables)
- How artefacts were produced
- Areas of greatest challengage
- Areas of greatest technical difficulty
Presentation of Poster 20%
- Clarity of poster presentation
- Effective technology/artefact
- Spelling and grammar
- Audience appeal
Team/ Individual Explanation 30%
- Reflection on lessons learned
- Demonstrated critical thinking
- Fluent handling of questions
Content
Introduction
provide enough background information to enable the reader to understand the context of your project. The introduction can include information such as your project objectives, scope, client organisation, existing state or any limitations.
Braincase is a Personal Knowledge Base (PKB). In common with other such systems it allows the person using it to capture, organise and expand their knowledge. Braincase allows the user to structure their knowledge into a collection of interrelated documents, not limited to any specific media type. The same data can be viewed from different perspectives through hierarchies and categories in order to make knowledge easily retrievable at a later date. This general type of mind-mapping through different media types helps the user to develop ideas by providing a framework for their knowledge.
Braincase actively protects knowledge it contains by automatically backing it up to variety of configurable locations over secure connections. This ensures that knowledge belonging to the user is preserved and remains accessible to them for as long as needed. This means the user can still access their knowledge in multiple scenarios in which a particular deployment of Braincase is rendered unavailable such as hardware or software failures or sudden access restrictions. The user need not worry about changing organisations, schools or hosting providers, but retains freedom and control over their own data.
Braincase users are not reliant on Braincase for continued access to their knowledge. By making it easy to extract knowledge in a variety of open formats this knowledge can then be imported to other software. However backups are encrypted to prevent sensitive data from unauthorised access. Data is protected during transmission to and from the user by the use of secure connections. This provides benefits such as identity, data integrity and confidentiality.
Braincase also protects the user from themselves by providing version control. When the user makes changes to knowledge assets old versions are retained. This allows any mistakes made by changes to the asset to be rectified by reverting to a previous version. The user can also view the changes that led to the current version to "illuminate the creative process".
Braincase deployments provide a centralised point to access knowledge on the Internet via standard protocols. This allows the user to access their knowledge from multiple locations and devices. Users can store and access their files as they would any other knowledge assets and have access to those files from anywhere. The files are also accessible as a version controlled repository.
Braincase provides facilities to expose knowledge on the web. One Braincase deployment can support multiple users and provides access control features allowing users to share their knowledge and collaborate with peers. This promotes the joining of minds, accelerating the expansion of knowledge and ideas.
Process
Describe the methodology you followed, why you used it and how it worked for your team and your projects. This will give the reader some insight in to the processes that you followed to achieve your project outcomes.
Development
To manage the development of the project we used the classic Scrum methodology. There is a product backlog that contains the issues that need to be worked on. We had six sprints of two weeks each and managed the issues for each sprint using milestones in Github. We had meetings with our client at the start of each sprint to prototype the progress from the previous sprint and talk about features and tasks for the next.
Software Evaluation
Opting to go for a combine and configure project, we needed to ensure that chosen components would be suitable for the software we wanted to produce. We searched literary sources for a methodology that would mesh with open source software evaluation but found none. So we borrowed suitable parts from various COTS based methodologies and developed our own. This was our greatest challenge during the project.
How it works
- Create proposed system
- Iterate through architectural layers
- Evaluate candidate software for each layer
- Check the the system is suitable
- Process feedback and repeat
https://cacoo.com/diagrams/Ae8L0FOFnbgGONd0-47DD0.png
We used this methodology to describe a proposed system containing empty architectural layers, iterate through those layers and evaluate a set of criteria against each candidate component. These criteria were:
- Licensing
- Skills Availability
- Application Health
- Requirements Matching
- Component Compatibility
- Dependencies
- Incumbrances
Each sprint saw us update the proposed system with lessons learned and start a new iteration. This process allowed feedback in the methodology to continually improve the proposed system. When our candidate software was selected it would be installed to provide needed functionality.
This methodology was the greatest challenge for us during the project. It was very hard to get our head around the COTS based methodologies we were researching. We were further confused by trying to apply those methodologies to open source software. When we did find a methodology that we thought was viable and that we could understand our supervisor informed us that it was missing key steps. After failing to come up with anything after more research we decided to create our own methodology based on some of the ones we had researched. We added and removed parts to make it more suitable for open source software and we implemented the steps that had been missing.
Github Repository
We chose to keep our project on Github. Github is a very popular website for open source software. It provides many services for a software development project. We used the wiki to store all our different kinds of documentation on the project. The issue tracker is very flexible and managed our many kinds of issues like features, tasks, bugs and use cases. We were able to visualise our commits to the repository and easily match them to files. We planned our sprints by adding issues to Github milestones.
In this way, the product itself is not Braincase - but the entire repository. This repository provides a history of the project so that future developers can see the decisions made by our team through its duration.
Products
Describe and evaluate your final products. You could compare the outcome to your original proposal as well as evaluate the quality or suitability for the intended purpose or use.
The final version of the software provided some of the most important features requested by the client.
http://i.imgur.com/Loyos.png http://i.imgur.com/JztP8.jpg
Braincase backs up user data automatically and, if enabled, saves the backup to Dropbox. No other knowledge base software we could find did this. We would have liked to have added more services to this to support more users but Dropbox is a good starting point. The backup service is currently tested and working including saving to Dropbox.
A web directory is provided for each user. This allows the user to serve any file they want to the world wide web. They can do this by committing files to the public_html directory in their Git repository. We think the ability to serve files just by pushing to a git repository is a great feature.
Each user has a personal repository. This allows the average user to store version controlled files and update their web directory. Most knowledge base software don't come with additional file storage let alone version controlled file storage. The popularity of cloud storage is increasing, however the US Government has stated that users don't own their data on cloud services and it is subject to unwarranted searches. Users need a private place that is their own to keep their data. This service is working fine but could have been better if we had made it include all the users data.
Braincase users are only able to create pages in their own bubble. Each page is private by default however it can be made publicly readable or publicly editable. Per page permissions are not common among knowledge base systems and allow the users of Braincase to share their knowledge and collaborate with others.
Subproducts
- Custom Dokuwiki Plugin Bubble - users can only create in their own bubble (namespace)
- Custom Dokuwiki Plugin Autobackup - links Dropbox to Dokuwiki users, manages restores
- Custom Dokuwiki Plugin Simpleperms - adds per page access permissions
- Ghissues - generates a formatted document from Github issues
- Autodeb - automatically generates a debian package whenever new code is pushed to Github
Progress in Learning
This section outlines the lessons that you learned and the value that your project had for the team members as individuals.
What we learnt
- New way of thinking about development
- How to Develop a methodology
- How to evaluate software
- Integrating software
We learnt how to evaluate software in a iterative and methodical manner to ensure that the resulting software is of high quality. This exposed us to a new way of thinking about the construction of a combine and configuration project. It also taught us a lot about integrating different software products and gave us experience in dealing with the intricacies required.
Robert had the chance to use the ruby programming language on the project. Wanting to get into programming ruby for a while this taught him the standards and conventions for laying out a ruby application and thus made a large improvement to his ruby skills.
Through the project Bhavic was able to make use of the git version control software that has been gaining popularity on the internet recently. This has made him a better programmer by increasing
Conclusions
Include a conclusion for your project, which summarises your successes and failures, how well you met your original objectives and the value that was added to your client by your work.
How value was added
- Existing system has no backups
- Client worried about loosing data
- We added automatic backups
- Ensured Data Surviveability
Where we failed
- Unable to deliver all the high priority features
- Due to too much non-development work
- Due to external responsibilities
- Due to small team
- In future we will plan for this
We used a novel way of thinking about software development by combining existing software. We did this by developing an evaluation process tailored to open source software.
