This page contains a project plan containing several topics on the project, from vision to techniques to team members. The goal is to let this be a structured overview of the aim and means of the project as well as providing a way for outsiders to quickly get up-to-date with the project managers knowledge. If this is the first page you found about the project, it is recommended to start at the landing page!
Note that this page should be a constant work in progress. If you are reading this and feel like you have valuable feedback or input, please comment, it is crucial for the project that this page is as correct, complete and non-ambiguous as possible.
...
| Time | Used system | In development | Situation / event |
|---|---|---|---|
| 2000 | Lotus Notes | - | AEGEE had an IT system based on Lotus Notes (this is an offline system) |
| 2006 | Lotus Notes | OMS | AEGEE's IT working group tries to develop a new OMS internally. |
| ???? | Lotus Notes | OMS | The internal OMS project is only at around 30% completed due to human resources issues (IT people leave to go and work instead) |
| 2007 | Lotus Notes | Intranet | AEGEE wanted to see some results and paid an external company (Troxo) for a new intranet |
| 2009 | Intranet | Intranet | The delivered product by the external company (Intranet) is a dissapointment with lots of missing features. Nevertheless the Lotus Notes system is replaced by this new intranet. |
| 2010 | Intranet | - | "In the recent history, IT in AEGEE has faced several big problems. For example an investment of 30 000€ in a new AEGEE intranet, which has resulted in an incomplete system, unsuitable for the needs of AEGEE. The Status quo is that the SU project is endangered and people are working hard to rebuild functionalities. In the recent history, IT in AEGEE has faced several big problems. For example an investment of 30 000€ in a new AEGEE intranet, which has resulted in an incomplete system, unsuitable for the needs of AEGEE. The Status quo is that the SU project is endangered and people are working hard to rebuild functionalities. In the In the past, the growing importance of IT has not been reflected in the organizational structure of AEGEE. It is still the same as in the 1990s, when IT was basically a homepage and a mail server." ~ Agora Leiden 2010 |
| 2012 | Intranet | OMS | AEGEE's IT goes back to the effort previously started, collects missing features for a new OMS |
| 2015 (Jan) | Intranet | MyAEGEE | At some point Fabrizio from ITC takes the initiative and starts implementing a new OMS from scratch (MyAEGEE) |
| 2016 | Intranet | MyAEGEE | Efforts are made to keep the development of MyAEGEE going, this includes things such as a hackathon |
| 2017 (May) | Intranet | MyAEGEE | CD decided on having an IT assistant in the head office (Derk Snijders) working as a project manager on the MyAEGEE project, continuing previous work |
| 2017 (Sep) | Intranet | OMS (2.0) | Significant progress has been made on the system, which is now called OMS again embracing the open-sourceness and opening ways for potential collaborations with other organisations (It is, however, not based on the previous OMS). It deploys a full micro-service architecture, stable API, updated frontend, a new logo, automated testing, continious integration and more than 10 microservices, most of them in a stable and working state. Crucially missing is still a permission system for the core, yet a prototype is in place. |
...
Below is a list of all the tools and places used to store 'documents' or more in general, information.
- Confluence - General documentation hub
- Project Plan - Project management level information
- Design - System design overview and argumentation
- Product requirements - Requirements of the system
- Development workflow - Development how-to's, workflows and tutorials
- Installation & aftermath -Installation instructions, troubleshooting
- OMS-CORE - Documentation related to the core microservice
- For now having dedicated core documentation hub is barely useful, for other microservices this is far from needed.
- JIRA - Issue tracker for bugs, features and changes
- Issues - Bugs, new features, changes, suggestions
Releases - Road map and feature timeline- Very hard to set realistic timelines, hard to enforce
- GitHub - Code storage (and version control)
- Code - The source code of the system is stored here
- Pull requests - Code reviews (and comments)
- Drive - Legacy documents and miscellaneous things requiring other file formats.
- Meetings - Agenda's and minutes of the development meetings
- Project manager - Personal project manager notes
...
Mapping the applied techniques to the reoccurring problems results in the following mapping:
Lack of human resources (1, 3, 4)
Status colour Yellow title Partly Lack of money (4)
Status colour Yellow title Partly
Lack of programmers (4)
Status colour Yellow title Partly Lack of project managers (3)
Status colour Green title Covered Lack of consistent working hours (1)
Status colour Yellow title Partly Lack of motivation (1, 4)
Status colour Yellow title Partly Lack of knowledge (2, 5)
Status colour Green title Covered Lack of experienced people (3, 4)
Status colour Yellow title Partly Lack of documentation (2, 5)
Status colour Green title Covered Lack of consistency (2, 3)
Status colour Yellow title Partly The wheel gets reinvented many times (2, 3, 4)
Status colour Green title Covered
Information is scattered everywhere (2, 3, 5)
Status colour Green title Covered People involved with the project rotate out fairly regularly (1, 3)
Status colour Yellow title Partly Lack of discipline (3, 5)
Status colour Green title Covered Lack of documenting (2, 3)
Status colour Green title Covered Lack of abiding to standard coding conventions (3, 5)
Status colour Green title Covered Lack of awareness (1, 3, 5)
Status colour Green title Covered Lack of involvement from the business stakeholders (1, 3, 5)
Status colour Green title Covered Lack of public understanding of the relevance of the project (1, 3, 5)
Status colour Yellow title Partly Miscommunication (2, 3)
Status colour Yellow title Partly Lack of defining concepts and designs (2, 5)
Status colour Green title Covered Lack of a single vision or aim (2, 3, 5)
Status colour Green title Covered Lack of completeness of requirements (1, 2)
Status colour Yellow title Partly
...
Lack of human resources (1, 3, 4)
Status colour Yellow title Partly Lack of money (4)
Status colour Yellow title Partly
Lack of programmers (4)
Status colour Yellow title Partly Lack of consistent working hours (1)
Status colour Yellow title Partly Lack of motivation (1, 4)
Status colour Yellow title Partly Lack of experienced people (3, 4)
Status colour Yellow title Partly Lack of consistency (2, 3)
Status colour Yellow title Partly People involved with the project rotate out fairly regularly (1, 3)
Status colour Yellow title Partly Lack of public understanding of the relevance of the project (1, 3, 5)
Status colour Yellow title Partly Miscommunication (2, 3)
Status colour Yellow title Partly Lack of completeness of requirements (1, 2)
Status colour Yellow title Partly
...
Detailed risks and challenges
Human resources
By far the biggest challenge and issue within the project. A PR-campaign has been done which successfully created awareness, however, involvement is still very much lacking. There are people who say they are interested in helping out yet actual concrete help is rarely given. A preliminary analysis has been done on the process of creating awareness among AEGEEans and converting this to involvement indicating that there were only small issues with the process, no clear and obvious major mistakes. This conclusion led to the next conclusion which is that we should entirely rethink the HR plan. This could involve starting to offer real, concrete, rewards for involvement (for example paying developers), but it should also focus on investigating solving this issue outside of AEGEE. Possible ideas are: Cooperation with other, similar, organization for mutual benefits, hiring a professional company, trying to involve students who are in need of a real-world project for their study.
So once again, there is an urgent and important need to come up with such an HR plan, of which the first task would be to find a person or team willing and having the knowledge to work on this. Jira Legacy showSummary false server JIRA (oms-project.atlassian.net) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId edf3f91b-210c-3cfc-933c-f8d8084c5f2c key GENERAL-101
Lack of consistency (in results and in people)
Consistency in results (software quality) should be achieved by standardization, the challenge herein lies to identify and define standardization rules on time. Additionally code refactoring should be done once in a while in order to achieve such standardization. Achieving consistency in documentation comes down to correctly structuring and linking documentation pages and sections to each other, avoiding duplication and out-dated information. On top of this documentation should consistently be written for the relevant parts of the software. All in all when it comes to results the answer lies in correctly defining and applying the software implementation process in combination with the project manager enforcing documentation rules.
...
The consistency in results seems to be going pretty well and is still becoming better, HR is really an issue.
Lack of public awareness
This boils down to the apparently inherent problem within software engineering of communication between developers and stakeholders. Regular meetings and an Agile workflow should help mitigate this issue.
...
While this should improve public understanding of the project, it should still be verified whether or not the project as a whole is properly prioritized. Therefor the importance should always be emphasized when communicating to the stakeholders.
Miscommunication
Due to this being an international project including people from many different cultures, countries and languages, communication will be an inherent issue. Not only the level of English might differ between people, but also the interpretation of the English can differ between people. This inherent limitation should be known among all members, communication should be open and as concise and non-ambiguous as possible, when noticing a miscommunication it should not be shameful to ask for clarification. And finally, when in doubt whether it is worth it to define, explain or detail: do it.
...
A general tip is to often ask whether there are questions or even check if they understand it, people are often hesitant to express when they do not understand something.
Lack of completeness of the requirements
A common problem among all software projects is defining all the requirements in time to take them into account. While hopefully addressed by using an Agile approach, late requirements can still be a problem later on. Focusing on a stable minimum project with incremental releases should enable incremental identification of requirements (which feels natural). However, with every new design decisions it should be considered whether or not this is compatible with the existing requirements and how it can deal with requirements that could be reasonably expected in the future. Knowledge of the organization hereby is key, therefore all of the discussions on design should always be joined by someone with domain knowledge of the relevant part of the organisation, which in practice translates itself into a (old) member of Comité Directeur. Having the stakeholders aware and understanding of the project as described above should help in identifying new requirements early on.
So far we have not really entered the state where detailed requirements mattered and of such have not run into such problems. It should also be noted that in some cases the organization can or should be adjusted instead.
Outdated information
One of the goals of the MyAEGEE project is to provide a single place to store information, which already implies this currently is not the case. Information within AEGEE is scattered everywhere, designs, diagrams and discussions can be found on multiple places, in fact the above summary even shows we are still doing that. The difference, and the way to overcome this issue, is to be aware of the different data location/tools and to make sure they are correctly utilized. Additionally, when looking at older documents related to the OMS it should be checked how relevant it still is.
This should not be much of an issue anymore since a lot, if not everything, is properly documented and updated on Confluence and the likes by now.
Changing CIA rules
This is a risk that is very hard to predict. What can be done is providing a somewhat flexible structure within the system that can handle some structural changes with minimal effort. This implies a structure that is similar to the real world situation without optimizing this model, abstraction, however, is encouraged as this generally aids flexibility. Additionally, this challenge can also be considered the other way around: When attempting to make changes to the CIA of AEGEE, thoughts should be given to the software repercussions of it.
The split between Bodies and Circles is partly based to accommodate this, the permission system, while not implemented as of now, is designed to be able to cope with almost any organisational structure. With these design decisions being made, this challenge could be considered to be solved.
CIA Privacy requirements
When building parts of the system thoughts should be given to privacy (and security) concerns of that part. It should comply with the CIA and when using external tools this should be investigated. The privacy rules with regards to the CIA should be covered with the 'changing CIA rules' risk, making this risk focused on assessing the privacy implications of using third party software.
For now only the addition of an 'online business environment' such as the Microsoft Enterprise E2 license we have seems to be a real risk regarding this.
Software Dependencies
As the goal of the final software product is to be long term viable, care should be taken into the level of dependence we have on software (libraries) used. Software (libraries) should only be used when its advantages outweigh its disadvantages that come from the dependency, this should be checked for every added dependency. When determining the disadvantage level of third party software special care should be taken to the following:
...
While each dependency should be considered (and given opportunity to be discussed), keeping these rules in mind when adding a dependency should mostly resolve this risk.
Overmanagement
While having a project manager has a great amount of advantages, it should be clear that management alone does not produce results and that having too much of it can reduce development speed without much benefits. Due to this the project manager needs to regularily reflect on his doing and the advantages it has, whether it gives enough of an advantage for the time it takes. Documentation should be done, but not to the point of barely writing actual codes, newcomers should be guided into the project, but not to the extent of it preventing from getting any actual work done.
My experience as project manager was that the management itself, while certainly not insignificant, is not a full time job with the amount of people currently involved in the project (~10 active contributors), therefor I balanced my time between managing and designing/programming on the system, which was quite a tricky thing to combine. ~ Derk Snijders
Common software management problems
There are a lot of software management problems that are a risk or challenge to any project, including ours. Wikipedia has a pretty solid list, as well as the 'Software risk management: principles and practices' paper.
Monitoring the risks and challenges
This is a requires a reflective look at the current state of the project. I recommend going over the project plan every monthly detailed meeting, verifying whether it is being applied and checking if it is useful, adapting or correcting while needed. Special care should be taken for the Risks & Challenges section and the Processes section.
It has been 3 months since this document last received an update following a critical look, this felt as too long, 1 month might be too short, this should be experimented with.
Tasks needed to be done
Programming tasks
For actual programming / development related tasks: See the development page, as well as the JIRA issues page.
...
Progress updates should mainly come in the form of weekly quick updates and the extended monthly meetings, as recommended at the public awareness risk assessment.
Project Management tasks
First and foremost, the project manager should always have an assertive and reflective attitude as he is his own judge and should regularly be verifying the efficiency and effect of his/her own tasks. The project manager should regularly check the project plan, both whether it is applied or not and in order to update it. The project manager is also the person that should detect and resolve any issue that is not covered in this document as well as being the one who should analyze the effectiveness of the proposed solutions. The project manager should make sure task division is done well and can even outsource things such as Human Resources and Public Relations, but should probably keep the Reporting tasks. Once again, the meetings suggested at the public awareness risk assessment are a strong and concrete recommendation to achieve these tasks.
...
With Derk Snijders stepping down as headoffice IT assistant, changes will be happening. In order to achieve ongoing continuity regarding the project a special set of JIRA issues has been made: Jira Legacy server JIRA (oms-project.atlassian.net) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId edf3f91b-210c-3cfc-933c-f8d8084c5f2c key GENERAL-107
Cost estimates
Making actual estimates to the cost is a very tough and complex procedure, already being difficult in normal software projects, being nearly impossible in a voluntary setup such as this. Since volunteers do not have an hourly loan, instead I will estimate the remaining costs in terms of hours of work.
...
- Continuous access to the used tools
- Confluence and JIRA licenses are probably the biggest hurdle here
- System deployment location
- For now the VM located on fraktis/titan is sufficient, when the new zeus is operational the system should move there.
- Human resources
- Programmers
- Use case testers
- Project manager
Team
Properties
The team for this project is (as of now) fully voluntary, which greatly impacts the team dynamic. There is a single project manager, steering the team, yet aside from that a flat hierarchy is maintained. This means that nobody is anyone's boss, nobody really has any power over each other, everyone's opinion should be treated equally. While for a lot of parts this is true, there are a few exceptions: microservices still have 1 or 2 primary developers, having slightly more authority within that area which often comes on having certain admin rights, for example on GitHub. Additionally the project is open source, meaning that in theory more people might contribute to the system. This all is somewhat summarized in the following properties of the team:
- Contributors decide themselves on the time they spent on the project
- This makes for very irregular development pace
- Nobody really has power over anyone else
- Discipline and good practice can be hard to enforce
- It is an international team, having inherent communication differences
- There are many people with many different skills, people have been somewhat 'categorized' by placing them in slack channels related to their interests
- There are many people with soft skills, too many, while there are little and not enough programmers.
- This is likely due to the distribution of the interests of people within AEGEE
- For many people involved this is a learning experience, real task-related experience can be missing
- A lot of the people need to be trained or guided before being able to do something useful
- Contributors live all over Europe, meaning physical meetings are very limited
...
Signing up for the slack goes through our landing page, which also serves as a starting point for newcomers.
Tools used
- Confluence - General documentation hub
- JIRA - Issue tracker for bugs, features and changes
- GitHub - Code storage (and version control)
- Google Drive - Legacy documents and miscellaneous things requiring other file formats.
- Slack - Quick all-purpose chatting tool
- Linux - Open source operating system great for development
- Travis CI - Automatic testing (with logs)
- Docker - Microservice provisioner tool using virtualized containers
Traefik - Load balancer and health checks
- Nginx - Web server
- PHP-fpm - A simple and robust FastCGI Process Manager for PHP
- Laravel (PHP) - Backend web framework
- NodeJS - Backend language
- AngularJS - Frontend language
- Postgresql - Relational SQL database
- MongoDB - NoSQL database
Additionally we make use of many more library / addons, these can best be checked within a microservice itself.
Schedule and Milestones
Once again, due to it being seemingly impossible to estimate development speed there is not a very detailed schedule of what needs to happen when. A simple schedule/roadmap/milestones can be found at the subsystems and planned releases section.
...
Having tried to plan and see it not achieved this is by far the most open part of the project, largely based on the motion that it should be done right instead of rushed. ~ Derk Snijders