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. ( GENERAL-99 - Getting issue details... STATUS )

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 ( GENERAL-12 - Getting issue details... STATUS ). 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 -  GENERAL-100 - Getting issue details... STATUS

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.  GENERAL-101 - Getting issue details... STATUS

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  GENERAL-100 - Getting issue details... STATUS
  • 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.

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:

• What is its impact on the privacy and security of our system?
• How likely is continued support of the third party software?
• How many similar functioning software is there that could fit as a replacement? (vendor lock in)
• Is it open source or proprietary?

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.

Human Resources tasks

An analysis needs to be made of the available and required resources (and the effect of let's say an extra developer), after which an attempt at acquiring these resources should be made ending in keeping people involved for a longer term.

All of this should be defined in the HR plan which needs to be written:  GENERAL-101 - Getting issue details... STATUS

Public Relations tasks

In order to keep awareness of the project there needs to be some effort in establishing and maintaining the public's awareness of the project. This can be done using regular updates on all kinds of platforms and is therefor closely related to reporting and human resources.

Reporting and documenting tasks

Progress of the project should be regularly reported to the stakeholders, as well as properly documenting design decisions and the code itself in order to allow for better knowledge storage and transfer as well as better maintenance in the future.

Documentation is covered within several processes: Requirements gathering, design, implementation and change management.

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.

The trick about managing this project seems to not lie in giving the right answers, but asking the right questions.

Stakeholder involvement

It seems nothing less than logical for the stakeholders to stay up-to-date and involved about the status of the project, however reality has shown that this is not always the case, likely due to lack of understanding of the more technical details and benefits. The regular meetings with mainly the project manager should alleviate this problem.

Achieving Continuity

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:  GENERAL-107 - Getting issue details... STATUS

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.

1. System-wide - 70 hours
   1. Complete stabilization - 5 hours
   2. Complete documentation - 5 hours
   3. Improved full system tests - 20 hours
   4. Complete system tests - 20 hours
   5. Full security check - 20 hours
2. oms-core - 150 hours
   1. Implementing core permissions - 20 hours
   2. Refactoring/cleanup of core - 10 hours
   3. Complete core documentation - 5 hours
   4. Build workable core frontend - 15 hours
   5. Fix bugs - 10 hours
   6. Decouple frontend - 20 hours
   7. Process frontend user feedback - 50 hours
   8. Fix missing features - 20 hours
3. oms-events - 110 hours
   1. Re-coupling with core - 10 hours
   2. Complete first feature set - 40 hours
   3. Additional user testing - 10 hours
   4. Process user feedback - 50 hours
4. Microsoft integration - 90 hours
   1. Microsoft adoption user tests - 50 hours
   2. Solve Microsoft legal concerns - 10 hours
   3. Implement Microsoft integration - 30 hours
5. Logging microservice - 20 hours
6. Notification microservice - 60 hours
7. Financial microservice - 100 hours
8. Management - 200 hours (30% overhead)

Total: ~800 hours

Volunteer modifier: 1.5 → 1200 hours

This estimate is more of a guesstimate, no guarantees are given.

Resources

The following is a list of resources required for the project:

• 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:

1. Contributors decide themselves on the time they spent on the project
   1. This makes for very irregular development pace
2. Nobody really has power over anyone else
   1. Discipline and good practice can be hard to enforce
3. It is an international team, having inherent communication differences
4. There are many people with many different skills, people have been somewhat 'categorized' by placing them in slack channels related to their interests
5. There are many people with soft skills, too many, while there are little and not enough programmers.
   1. This is likely due to the distribution of the interests of people within AEGEE
6. For many people involved this is a learning experience, real task-related experience can be missing
   1. A lot of the people need to be trained or guided before being able to do something useful
7. Contributors live all over Europe, meaning physical meetings are very limited

This section should be updated after the HR plan is made. GENERAL-101 - Getting issue details... STATUS

Communication

The technical flow of communication is defined in the design process, as well as on the development page.

Aside from that, communication takes place through slack, where we have several channels, each with their own purpose:

• #general and #random: Standard channels for everyone, #general for general announcements and discussions, #random for off-topic chat.
• #development: General talk about technical topics within the project
• #oms-core, #oms-events, #operations, etc: Technical talk about a specific area of the project
• #dev-logs: Automated logs of events from tools used within the project
• #human-resources, #public-relations, #testing: General talk about a specific area of the project

To put it in an abstract way: People are categorized by their interests, with an additional split taking place between technical and non-technical people (in order to not scare people away with too much tech talk). Furthermore there are some communication channels dedicated for a single microservice/purpose, this aids the amount of messages (or spam) people have to go through that they are not interested in.

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.

It should be noted that it might very well be beneficial to have a more detailed plan for the future, whether it is realistic to plan and actually stick to such a schedule is up for the project manager to judge. Having a proper HR plan ( GENERAL-101 - Getting issue details... STATUS ) and some business/stakeholder requirements might result in, or even require a schedule.

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 

More detailed Roadmap

See Schedule and Milestones section.