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.

You can (and should ) comment by selecting some text, wait for a popup and then pressing the comment item.

Vision of the project

The MyAEGEE project at its heart has the aim, as the name implies, to create an Online Membership System (OMS) system for the student organization AEGEE-Europe (including all of its bodies), replacing the current system. A secondary aim of the project is to succeed in this using an open source approach, allowing other (similar) organizations to benefit from the software outcomes from this project as well. A tertiary objective could be considered to be providing a way for contributors, mainly (technical) students from within AEGEE, to work together on an international large-scale project in order to grow their skills in the related areas.

These aims have a set of implications that come out of them:

• The main 'client' stakeholder will be AEGEE-Europe (represented by the Comité Directeur of AEGEE-Europe)

  • As such, things such as the internal organizational structure (hierarchy) of the system will be based on that which is required by AEGEE-Europe

  • Other entities are free to use and work on the project, however, as stated in the license, without any guarantee of future support.

• In order to balance the possible conflicting or diverging needs of the general (open-source) public and AEGEE-Europe, a modular approach will be taken.

  • Features that are needed for one user but not for another should be able to be toggled on or off.

  • While opening the system for other modules, this project will focus on providing the modules that AEGEE-Europe needs.

• The timeline (roadmap) of the project will be influenced by the needs of AEGEE-Europe

  • As it is currently a high priority to replace the currently used system, the focus will lie on delivering a stable low-feature release first (the Minimum Viable Product, or MVP)

    • After this work can continue on adding extra features, adding incremental functionality to an existing production stage system.

• AEGEE-Europe will do its best to provide the project with a constant support of human resources and development goals and support.

• As it is a voluntary open-source project with a low-entry barrier we strive for allowing room for mistakes as long as constructive feedback is given and reacted upon when received.

MVP requirements

The MVP requirements consist mainly of the core microservice. It's (minimum) requirements and responsibilities can be found at here. Additionally some services which are needed from a technical point of view such as the registry are also included in the MVP.

Technical requirements have, for now, been pretty well identified, however, what is somewhat missing are business requirements. (https://myaegee.atlassian.net/browse/GENERAL-99)

Human readable MVP requirements

The MVP of the MyAEGEE project should support at least the following features:

• Members can be added, edited and viewed in the system

• Custom bodies can be created, edited, viewed and a user can join them

• Roles such as CD, commissions and Boards can be assigned

• Information from the system can be exported

Events and financial tools are not part of MVP, however, these services have high priority following the MVP.

Technical MVP requirements

A work in progress overview of technical requirements can be found on the MVP requirements page.

Future aims

The future aims and ideas can best be found on the microservice overview, where some ideas for future microservices have been laid out in combination with a short overview of their funcitonality.

Background information

The entire project, dating back as early as 2006, is in its entirely fully suited to be called a textbook case of a failing IT project. Development on a 'new' OMS started as early as 2006 and had many ups, downs, reboots and pauses with very mixed intermediate results. Many different people have worked on the project, many different analysis have been made. In the end it is almost too much to grasp, yet an attempt at providing all the available information is listed below. However, honestly, knowing that the overall life cycle of the project was a huge mess is sufficient.

Reoccurring problems

Several reoccurring aspects can be identified to have gone wrong over the course of the project in varying magnitudes:

• Lack of human resources

  • Lack of programmers

  • Lack of project managers

  • Lack of consistent working hours

  • Lack of motivation

    • Lack of money

• Lack of knowledge

  • Lack of experienced people

  • Lack of documentation

• Lack of consistency

  • Information is scattered everywhere

  • People involved with the project rotate out fairly regularly

    • The wheel gets reinvented many times

• Lack of discipline

  • Lack of documenting

  • Lack of abiding to standard coding conventions

• Lack of awareness

  • Lack of involvement from the business stakeholders

  • Lack of public understanding of the relevance of the project

• Miscommunication

  • Lack of defining concepts and designs

  • Lack of a single vision or aim

  • Lack of completeness of requirements

History

That being said, a very brief history of the project is as follows:

For more detailed information about the history of the project and earlier designs, consider the following locations:

• A more detailed explanation of the history of the project.

• AEGEE wiki OMS page detailing the history up to and including 2009

• http://oms.aegee.org/ - A hub page linking to several other documents such as an intranet evaluation and CD decisions on the future of the project

  • No longer directly available as of July 2017, stored under historical files (restricted access)

Processes to be used

In short we make use of an incremental Agile approach, with weekly (online) meetings on Monday. We apply an almost-flat non-hierarchical structure within our development team, with a set of equal developers and a project manager. Slack, Confluence, JIRA and GitHub are the main communication channels. Slack is for quick communication, confluence for detailed documentation, JIRA for issue tracking and GitHub for code reviewing. We defined usage guidelines for both Git and JIRA. A quick start on the software development processes can be found at the development page.

Requirements gathering processes

By now there is already a large set of requirements available, focus will be on providing a product that complies with these first, before spending more time on the requirements discovery phase. It did however became clear that the older requirements need verification and sometimes be defined in more detail, this should be done before reusing any older requirements.

Where necessary the project manager is responsible for initiating a requirements identification process which usually can be fulfilled quickly by asking input from the Comité Directeur. Additionally the incremental approach from Agile should make later adaptation and identification of requirements possible. Finally, since we are already receiving multiple (specific) requests from future users of the system we have set up a requirements page where we store and define requirements both for short-term releases and for long-term goals.

The process of identifying new requirements should be specified better when identifying requirements becomes more of a focus, that is when the current basic requirements have been met and plans need to be made for the future.

Design processes

As of now extensive time has already been spend on design and again this is something not currently focused on and instead what already is, is being used (the microservice architecture). It has become apparent that some of the older designs have become outdated and sometimes are not thought out well enough. Similar to the requirements, when reusing an older design it should first be verified and defined in more detail (on Confluence).

Where necessary the design process goes as follows: The initial brainstorm usually takes place between the developers using slack, after which a more detailed, concrete and distilled design is posted on either JIRA or Confluence (depending on the magnitude, confluence being for the larger designs). Then time is given for the other developers to read the concrete proposal provide feedback and discuss. It is vital that these discussions take place with a constructive and critical attitude. Finally once all points of discussion have been resolved the design should be documented (on Confluence) and implementation can start.

An overview of the overall designs (current and past) can be found on the architectural design page. 

If/When the resources are there to have a more fleshed out design process (using more research, input and iterations) this process should be expanded upon, mainly by adding a (better) research phase.

Implementation processes

Implementation process is largely dependent on the microservice itself. On a global level we maintain one or more primary developers for each microservice (as defined in the microservice overview), taking up large responsibilities on that part of the system. Additionally, Git is used as a version control and collaboration tool. The git branching model should be used to provide clear standards and consistency. Branches should be aptly named in accordance to this model and integration with JIRA. Finally, a pull request can be put out to request feedback on the code and to start the merging process. Someone other than the developer doing the pull request reviews it and if it passes review and integration tests it can be merged. It is critical for future integration of components to be standardized, this is to follow the standardization pages and defining new standardization rules whenever identified to be (possibly) needed. More details on this process, help and guidelines can be found on the development workflow page.

As of now, with the (developer) team size consisting of ~5 (voluntary) developers this workflow suffices, if this significantly changes this process might need refinement.

Quality Assurance processes

Quality assurance (QA) is split into two areas: software QA and project QA.

Software QA is achieved due to the implementation process, specifically the git branching model + code reviews through PR's. Additionally extensive testing should take place: Each microservice should have its own set of tests that cover as much of the microservice as possible, these tests should be combined with a continuous integration setup: whenever a push or pull request is made tests should be ran automatically to verify the state of the software at that point in time and to verify nothing broke because of the new additions (currently Travis CI is used for this). In addition to each microservice having tests itself, the system as a whole should have integration tests: whenever a change is made to the provider (oms-docker), integration tests should be run, testing every microservice individually and the combined system as a whole. These automated tests should make sure stable code is available on the master (production) and (to a slightly lesser extend) develop branches on GitHub at any point in time.

Project QA is achieved by having a dedicated project manager assigned to the project (desirably for a longer time period). It is within the project manager's tasks to regularly check and verify the processes being used with the project, as well as checking the overal state of the product, both in terms of software quality and suitability to the actual needs of the client. This includes regular checks (user testing) with the client (and other stakeholders) to verify that the actual needs are as close as possible to the defined needs, and that the overall state of the project is within the constraints as put by the client. In reality it is recommended for the project manager to give weekly updates to the client, where questions can be posed, as well as a strong recommendation to have extended monthly sessions where it is made sure there is as little miscommunication as possible and both sides understands each other. Finally the project manager should regularly report to the steering committee in order to provide an extra level of checks.

If/When the project and team size changes these process might need adjustment, especially project QA. Additionally defining more concrete progress updates, such as a monthly blog, could be a valuable addition to the project QA.

Change management

Change management has, so far, not been really applied to this project, or one could argue has taken place a long time ago. A need for change should be identified by either the steering committee, the Comité Directeur or the project manager. Once a need for chance is established, usually due to troublesome processes or disappointing results, what needs to be changed should be identified. Once a need for change is identified more research should be done on this process.

Even though it is not really being able to be managed due to the voluntary nature of the project, a change in the human resources is a realistic occurrence and should always be taken into consideration. Ideally to alleviate this problem a proper knowledge transfer should be done, which in turn is achieved by properly documenting relevant of the system, essentially storing the knowledge of the person leaving the project. Additionally, newcomers should read the documentation that is relevant to them, as well as a recommendation to get in touch with the previous person responsible for the relevant areas. This implies the desirability for contributors to remain somewhat active after leaving the project, or at least willing to respond to questions. Finally a new contributor should receive guidance by a more experienced contributor in order to be able to get assistance and ask questions and in general provide a smooth entrance to the project. All in all both leaving and entering the project should be a slow process as opposed to instant.

This process is not to be confused with version control (which belongs to the implementation/QA processes).

In reality this, at least up to now, much came down to the project manager welcoming newcomers and telling existing contributors to document their doings.

Risk management

Risk management is currently mainly done by the project manager. Risks in term of data-loss are covered for the code itself by using Git, the documentation (Confluence, JIRA) should have regular backups (https://myaegee.atlassian.net/browse/GENERAL-12). A quality assurance process is in place in order to assert both the software quality, system suitability and project status and functioning. Lastly, this project plan itself helps significantly in identifying and assessing the risks involved in the project, for this see the Risks & Challenges section that identifies past issues and attempts to foresee future issues as well as providing a way to deal with these issues.

So far risk prioritization has not been properly done, this might be useful, especially together with business requirements and overall prioritization within each of the stakeholders doings.

Ongoing project management

Having a dedicated project manager turned out to be extremely valuable, and necessary, for this project, making sure this remains this way is a top priority for the project. For this to be realized it is vital that the priority of having this project manager, and the project as a whole, is very clear to the controlling entities. This means that the current (outgoing) project manager, the Comité Directeur and steering committee need to be aware of the added benefits and prioritize accordingly. Next is the biggest hurdle, finding an actual project manager willing to spend his/her time on the project. Additionally, the project manager should have the required skills such as: requirements analysis, (architectural) software design, programming workflows in addition to soft skills such as management, writing, communication, abstraction, reflection and an assertive stance within the project. Having coding knowledge/experience and passion for the project and organization (and knowledge of it!) is a strong recommendation. The process of finding and keeping such a person is further detailed in the human resources risk section.

The knowledge transfer of the project manager should be similar to that of the other contributors, with this document being the primary knowledge storage and an even stronger recommendation on having a (live) meeting with a previous project manager.

I would say that in the past there were people who called themselves a project manager of the project, however I believe there was not put sufficient prioritization on this, as a document such as this is a first and in my opinion a necessity for a successful (software) project of this scale. Management was not (yet) a full time task, in practice it was very interweaved with actual development of the system (which is a tricky thing to balance). ~ @Derk Snijders

Summarizing

Document summary

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

Note that slack is not on this list, slack is not intended to be archived or to be used as such.

Measurement and tracking summary

Tools and ways to measure the processes of the project and track their progress:

• JIRA - General software progress tracker

  • Issues - Status, activity and people tracking per issue

  • Releases - Provides a way to measure the state of the project compared to the planned state

• Weekly meetings

  • Dev meeting - Allows the project manager to keep up-to-track with the developers

  • CD meeting - Allows the stakeholder to keep track of the state of the project

• GitHub - Branches, PR's, commits and graphs

• Travis CI - Automatic testing (with logs)

• Monthly update report - https://myaegee.atlassian.net/browse/GENERAL-100

Subsystems and planned releases

Mapping subsystems to microservices seems like a logical thing to to and for now sufficient, but an important thing to keep in mind with this is that this requires the microservices to be correctly defined (and split). Using microservices as subsystems gives us the following attempt at a roadmap:

• Project-wide

  1. Stabilize project using common practices and standardization

  2. Solve HR issue

  3. Work on releasing a first possible MVP

  4. Test Microsoft integration options

  5. Implement Microsoft integration

  6. Release real MVP

  7. Slow network-wide system roll-out

  8. Extra microservices / new features

  9. Maintenance

• OMS-core

  1. Permission system

  2. Working frontend

  3. Decouple frontend

  4. Redesign frontend

  5. Codebase refactor/review

  6. Extensive integration with Microsoft

• OMS-events

  1. System integration

  2. Implement feedback from testing

Aside from this, JIRA functions as a very useful tool to keep track of issues, features, bugs and prioritization of all of these.

Setting a planned release date for the project has proven to be a difficult task, previously an attempt was made to use the JIRA roadmap feature, however this turned out to be hard to use efficiently: development speed is highly inconsistent due to the voluntary nature and new issues popped up very frequently, making even a simply collecting features for a release (disregarding time) to be troublesome. Due to having no power over the development speed of individual contributors the project works on a 'It is done when it is done' basis.

In the future, after the project has stabilized/matured further it might be wise to give JIRA releases/roadmaps/plans another go, for now simply ordering issues by priority seems to work well.

Risks and Challenges

To analyze the risks and challenges involved with the project a check has been performed in order to determine to what extend the previously recurring problems are covered by the plan as laid out in this document. This includes identification of both problems and (new) solution techniques, mapping them to each other, filtering and finally covering the remaining risks.

Identification

First of is the identification of the problems which has already been done in the historic analysis. Next is a list of applied techniques that should solve / reduce the recurring problems:

1. The usage of an Agile workflow allows to detect and improve requirements and their implementation on time as well as providing a modern software development workflow up to par with business standards and, frankly, creates hype and therefor better motivation and HR.

2. A focus on documentation, especially when it comes to design, should minimize miscommunication and improve knowledge transfer such as checking why a certain past decision was made.

3. Having a dedicated project manager adds an entity within the project that can enforce discipline, communicate awareness and involvement to the stakeholders, steer the entire project along its vision, promote knowledge transfer (documentation), manage human resources, has the duty to reflect upon the project as a whole and finally provide an all-purpose entry point for questions and responsibilities.

4. Having the project be open source boosts motivation for the project, has the potential to provide additional HR and allows for certain tools for open-source software to be used.

5. The project plan, this document, clearly defines concepts and provides a single vision for the project as well as a guideline for each process along with serving as a checklist as to whether every aspect of the project has been sufficiently covered. Finally the project plan itself should greatly boost continuity of the project, serving as a knowledge transfer document for the project manager and stakeholders.

Mapping

Mapping the applied techniques to the reoccurring problems results in the following mapping:

• Lack of human resources (1, 3, 4) Partly

  • Lack of money (4) Partly

  • Lack of programmers (4) Partly

  • Lack of project managers (3) Covered

  • Lack of consistent working hours (1) Partly

  • Lack of motivation (1, 4) Partly

• Lack of knowledge (2, 5) Covered

  • Lack of experienced people (3, 4) Partly

  • Lack of documentation (2, 5) Covered

• Lack of consistency (2, 3) Partly

  • The wheel gets reinvented many times (2, 3, 4) Covered

  • Information is scattered everywhere (2, 3, 5) Covered

  • People involved with the project rotate out fairly regularly (1, 3) Partly

• Lack of discipline (3, 5) Covered

  • Lack of documenting (2, 3) Covered

  • Lack of abiding to standard coding conventions (3, 5) Covered

• Lack of awareness (1, 3, 5) Covered

  • Lack of involvement from the business stakeholders (1, 3, 5) Covered

  • Lack of public understanding of the relevance of the project (1, 3, 5) Partly

• Miscommunication (2, 3) Partly

  • Lack of defining concepts and designs (2, 5) Covered

  • Lack of a single vision or aim (2, 3, 5) Covered

  • Lack of completeness of requirements (1, 2) Partly

The degree as to which each technique solves the related problem can differ greatly and can be considered subjective. An attempt is made to color code as to which extend each problem is considered covered.

Filtering

This leaves us with the following list of problems that can be considered a risk (at best) and should be carefully monitored:

• Lack of human resources (1, 3, 4) Partly

  • Lack of money (4) Partly

  • Lack of programmers (4) Partly

  • Lack of consistent working hours (1) Partly

  • Lack of motivation (1, 4) Partly

• Lack of experienced people (3, 4) Partly

• Lack of consistency (2, 3) Partly

  • People involved with the project rotate out fairly regularly (1, 3) Partly

• Lack of public understanding of the relevance of the project (1, 3, 5) Partly

• Miscommunication (2, 3) Partly

• Lack of completeness of requirements (1, 2) Partly

Although the human resources has some parts covered, in its entirety the human resources is the least solved recurring issue, this can be seen when grouping them together once more when 7 out of 11 risks appear to be related to human resources. This leaves us with the following major risk topics:

1. Human resources

2. Lack of consistency (in results and in people)

3. Lack of public awareness and understanding

4. Miscommunication

5. Lack of completeness of the requirements

Aside from these historical recurring issues, the following risks and challenges should be considered and monitored as well:

• Outdated information

• Common project pitfalls

• Changing CIA rules

  • Privacy requirements

  • Organisational structure

• Software dependence

  • Vendor lock in

• Monitoring these risks and challenges and how to intervene when necessary

• Over management

Each of these risks and or challenge is further detailed in the next section.

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. https://myaegee.atlassian.net/browse/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 lack of consistency of people (especially in the long term) is something that can hopefully be mitigated by adopting a healthy stream of human resources, allowing for a proper flow of knowledge as people join and leave the project. Additionally having proper documentation of the knowledge of a contributor's contributions should greatly reduce a potential steep and time consuming learning curve for new comers. Finally once the project has stabilized and matured enough there should not be too many changing things anymore and documentation should stay relevant for a longer time as well as having a single envisioned and integrated system instead of every contributor doing their own thing and therefor being harder to replace making it hard to keep every position covered.

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.

The following regular meetings are recommended:

• Weekly project-manager + Comité Directeur quick update

• Monthly publicly accessible progress report https://myaegee.atlassian.net/browse/GENERAL-100

  • Should be send to the steering committee, Comité Directeur and network.

• Monthly extended project-manager + Comité Directeur 

  • Going over the monthly report, asserting each side understands each other

• Agora progress update, summarizing the past monthly reports

• Workshops on Network Meetings and such have been suggested - yet as of now not tried.

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.

Additionally the field of expertise should be kept in mind when communicating with stakeholders: A developer needs to adjust his explanation and wording of technical topics to be understandable by the stakeholders. The project manager should oversee this is properly done although it is everyone's responsibility to indicate non-understanding. The monthly detailed meetings as suggested above are a way and an opportunity to resolve these kind of misunderstandings.

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.