Home
Welcome to the ContinuousEduProjects wiki!
ContinuousEduProjects are projects in an educational context, that are characterized by the fact that they are developped further by a new group of students in a new semester. These projects don't stop, but evolve over a longer period of time. These type of projects ask for a different guiding and end quality requirements to make them suitable for new groups of students.
Experience shows some problems in these projects, that resemble real world projects like:
- Onboarding new teams, when those with knowledge are not there
- Having the idea it is better to start from scratch again
- Vision of development
- Proper documentation
- Capturing knowledge
From a educational perspective, some other aspects need to be adressed:
- Which work is contributed by whom
- How to make sure that there is sufficient room to learn the necessary skills, while several basic work is already done
- Introducing students into a project, in which concepts are present that still need to be learned
we are looking for ways of working and best practices that makes these long term projects possible in an educational setting. Also we will address the challenges, explore the possibilities, and experiment with different solution directions.
We call the transfer from work and knwoledge from one team to another the handover of work. Succes for handover is expressed in system quality frameworks like e.g. ISO9126 in terms of: maintainability, readibililty, portability.
A term like transferability might be considered as an acceptable alternative term. However this term is not mentioned in quality frameworks and might be confused with transferability in an academic or research context. In that context transferability is seen as if solution is sufficiently generalized to be applied in another domain.
We can distinguish between different type of projects, that could all be considered 'continuous educational projects'
- Pure educational, with the purpose to experience what it is like to work on an existing project.
- Research projects
- Explorative projects
- Company contributions
TRL, technology readiness levels can help to determine in which phase a project is currently in. A higher TRL asks for other quality criteria of delivered products and availability of deployment environments.
Students might work for a semester on a long-term continuous educational project. During this semester, three phases can be recognized
During a semester, we can recognize three phases for a long-term project:
- Explore
- Add Value
- Handover
The diagram also shows how it can be mapped to the pattern of analyze, realize and validation.
Each of these phases have some specific proceedings that can be recognized.
When starting with a brown field project take your time to get familiar with what is already there. In practice, we have seen that it is quite common to stay upto two sprints in this phase. A good start is half the work. Discover the code. Look critical to what is received, where are possible improvements that are beneficial for future teams. But also, who has already knowledge, what is expected from your stakeholders? What are their major attention points?
Guidelines 'Exploration' Phase
The following paragraph is describes the theory of how handover succes can be linked to quality attributes of your software system, as background information. You can directly go to the summary or guidelines without a problem.
It is not a one recipe for all, to answer this question. Many factors can be taken into account to create a project that is of sufficient quality, to make a handover a succes.
One thing is for sure: Making a project suitable for handover, cannot be done at the last moment!
It is just like with many other non-functionals like security, testability, performance, etcetera. These quality attributes have to be taken into account from the start of a project, and attention should be given to it during the whole development.
The word quality has been mentioned a few times by now. This leads to the question: Which quality attributes can contribute to a succesful handover? Frameworks like ISO25010 give us some suggestions: Maintainability and Portability seem to be good candidates, to start with. These categories have quality properties (specifically: Modularity, Analysability, Modifiability, Testability, Installability) that can be used to define activities which lay a foundation of software that has sufficient quality for handover.
Activities to assure a certain level of quality for handover, is not limited to only maintainability and portability. They lay a good foundation, but also look at the project context. For which environment (proto or production) are you building, what is the maturity of the project? The Technology Readyness Level (TRL) of your project might help to determine if more quality attributes should be taken into account, for a succesful handover. Think for example of two projects. One TRL4 and the other on TRL6. Assuring high quality standards for maintainability and portability on TRL4 seems sufficient for a succesful handover. However on TRL6, quality attributes like security and performance might also be of major importance for a acceptable handover to the client.
- Making a project suitable for handover, is not done at the end of a project
- Succesful handovers can be linked to quality attributes like maintainability and portability. Properties of these attributes are: Modularity, Analysability, Modifiability and Testability
- Based on the projects TRL, more quality properties might be on a satisfactory level. For example, TRL 6 project might need also more focus on security or performance
At this moment several projects run, that are continuously developped over multiple semesters and different student groups. Below is a list to their public archives:
-
https://github.com/DigitalExcellence
One of the first projects on which is developped for a longer time, and is actively used. It served as a basis for many other projects, like for example ACI-Rental and FIPost - https://github.com/ACI-Rental
- https://github.com/FIPost
_ The below list gives the possibility to assess existing or new projects set-ups to determin how well they could be used as an continuous educational project _
Based on the research and best practices of student projects, a list is described below that can be used to determine if necessary activities are taken to increase the succes for transfer of a running project.
This list is dynamic and open for change. Feel free to improve the list, by Contributingyour insights.
- Version management is present and can be taken over by a new team
- Issue management is present and can be taken over by a new team
- Management of future development (for example userstories in backlog) is present and can be taken over by a new team
- Together with the relevant stakeholders it is determined which new contributions are ready for intake
- For new contributions, tests are in place that validate functionality and ensure regression testing.
- Each known _bug _ is described as an issues, and has been discussed with the knowledge owner.
- An 'room for improvement' session has been scheduled with the team, in which future improvements of the product are identified. These future improvements have been recorded as an issue and are discussed with the knowledge owner.
- The team identifies issues, which are suitable for a new team when starting with the exploration phase
- Documentation: Documents are up-to-date. (architecture, project definition, future work).
- Documentation: Important decisions has been document. For example, by using Architecture Documentation Records. This provides a new team with a histroy trail of important decisions and development directions.
- Security: Static Security analysis has been performed. For example, no hard-code passwords in code
- Readibility: Static analysers are used to ensure a coding style and readibility.
- Dependency Management: External tools and libraries are described and use explicit versioning. For example, do not use :latest tags.
- Dependency Management: All tooling can be handed over. There is no accounts linked to old developers, or trial versions that can expire.
- Environment: Documentation is present that describes step for step a local set-up for a developper, resulting in a working version of the project.
- Environment: Datasets are available for development purpose (including description how to use them in the project)
- Environment: Documentation is set-up to install a production environment from scratch. Preferably: configuration-as-code
- Delivery: Forked repository, has a seperate delivery branch for intake
- Delivery: Pull requests to delivery branch are created, and are reviewed together with the knowledge owner
- Delivery: A final transfer meeting is planned with the product owner
- Delivery: Project is published or updated on the DEX-platform http://dex.software/home .