Final report

Tampere University: TIEA4 & TIETS19

Students:

• Joni Tuominen: 438598
• Kia Lieke: 421946
• Marianne Sirén: 439555
• Antti Pessa: 431566
• Leevi Tukiainen: 425051
• Markus Hovila: 432169
• Teemu Vuorinen: 428479

Version history

Version	Date	Author	Description
0.1	5.5.2020	Kia Lieke	First draft
0.2	6.5.2020	Marianne Sirén	Updates
0.3	6.5.2020	Kia Lieke	Updates
0.4	11.5.2020	Kia Lieke	Added updates made by Joni (7.5. and 10.5.)
0.5	12.5.2020	Marianne Sirén	Updates
0.6	14.5.2020	Marianne Sirén	Update working hours

1. Introduction

1.1 Purpose of the report

The purpose of this document is to describe the final product made during the course. The aim was to create a peer reviewing system to an already existing TIM-system that university of Jyväskylä uses. Originally, the purpose was to also create a chart drawing system to the TIM-system as well, but the customer had implemented it already between our meetings so that was dropped off from our to do –list. A huge problem of the project was the lack of clearly structured definitions and requirements of what is wanted to be done. In these kinds of projects, where participants have hardly any experience, it is important that the customer provides good instructions and clear definitions instead of just a giddy outline of what could be nice.

The process started with examining a few different peer reviewing systems, which turned out to be quite useless after all. After that, we started to somehow design the peer reviewing system that we needed to develop. The requirements seemed to change on a weekly basis, so in the end we decided to just create an algorithm that does the grouping of the students. Besides the algorithm, we created some filters to the system, so that students can only see the needed assignments to do the reviewing part.

A huge part of our time was spent in trying to understand what the customer wants and then trying to design and plan what we should develop. We designed the algorithm from scratch. The team performed great during this project, taking the complexity of the code and the changes of requirements into account.

The team learned that to succeed in these kinds of variable projects, a somehow working MVP should become the main focus of development. If the focus is mainly on the changes of requirements, there is a possibility that the implementation might not have that much time left when the requirements are finally figured out.

1.2 Definitions, abbreviations and acronyms

TIM, the interactive material Trello for tasks and tickets Slack for communication

2. Project organisation

2.1 Group

Project managers:

• Joni Tuominen: technical manager (coding, planning etc)
• Kia Lieke: design, testing and management (+ grouping algorithm design)
• Marianne Sirén: design, testing and management

Project group:

• Antti Pessa: coding and participating in planning
• Leevi Tukiainen: coding and participating in planning
• Markus Hovila: coding and participating in planning
• Teemu Vuorinen: coding and participating in planning

2.2 Customer

Vesa Lappalainen, University of Jyväskylä, lecturer, vesal@jyu.fi

2.3 Other stakeholders

End-users will be students and professors from University of Jyväskylä or other organizations using TIM system. Tampere University and the ÄlyOppi project.

3. Project implementation

3.1 Communication

Meetings with the customer were held weekly via zoom. Coding workshops with the customer were held when needed. Meetings and workshop with the team were held at least once a week and also when needed. Tools for communication were Slack, Zoom, emails and sometimes WhatsApp. Visual Studio Code’s live share plugin was used for coding workshops.

3.2 Planned vs. implemented sprints

3.3 Tools and technologies

Tools set by the customer are:

• Windows 10,
• Docker Toolbox,
• Docker Desktop,
• PyCharm Professional,
• SmartGit,
• ConEmu,
• Putty,
• GitLab

3.4 Deliverables and outcomes

Main deliverable of the project is peer review feature written Python. Feature is delivered by merging feature to TIM project’s Gitlab repository from forked repository.

Peer review feature is delivered in working state, meaning that peer reviewing can be done by users. Although, the review flow works, it requires further development to improve usability. Users may require additional help to use peer review feature in state of the deliverable version.

Other important deliverables are planning related material, such as user interface prototypes and wireframes, testing plan, flow chart of the peer review feature and MacOS instruction for TIM installation. Planning related material is delivered as TIM documents.

All deliverables are delivered by the end of the project.

List of deliverables:

• Peer review code
• UI prototypes and wireframes
• Testing plan and testing report
• Flow chart
• MacOS instruction for TIM installation

3.5 Changes

The original plan was to first implement a chart drawing system to TIM using a draw.io plugin. Plans and all kinds of solving were made, but the plugin implementing was done between our weekly meetings, so the chart drawing system was left out.

The peer reviewing system had all kinds of changes during the whole project, but there wasn’t anything that severe that it should’ve been listed here as a change. In summary, definitions and requirements changed all the time and almost everything got sorted out just before the last week of the project.

3.6 Third party components, licenses and IPRs

Project outcomes are published under same licenses that TIM has. Source code will use MIT license and other deliverables will use Creative Commons Attribution 4.0 International license. Peer review project does not use any other third-party components than what TIM uses. MIT license gives extensive rights to the source code, including modifying and distributing, if original copyright and license notice is included.

4. Working hours

Table 4.1. Realized working hours in person-hours by person and task.

	Marianne	Kia	Joni	Antti	Markus	Teemu	Leevi	Total
Planning, design and management	118	104	85,5	66,5	62	49	48,5	533,5
Coding and testing	12,5	13,5	33,5	33	38,5	31	20,5	182,5
Studying	5	10	9,5	8	4	0	9,5	46
Documenting	0	7	5	1	0	2	0	15
Other	16,5	20	27,5	12	18,5	35	28,5	158
Total	152	154,5	161	120,5	123	117	107	935

Table 4.2. Realized working hours (weekly totals / project).

	Weekly total
Week 3	32,5
Week 4	46,5
Week 5	50
Week 6	47
Week 7	30
Week 8	31,5
Week 9	52,5
Week 10	30
Week 11	33
Week 12	47
Week 13	40,5
Week 14	95,5
Week 15	80,5
Week 16	88,5
Week 17	49,5
Week 18	75
Week 19	48
Week 20	58
Total	935

5. Quality assurance

5.1 General description of testing

We created a comprehensive testing plan and used exploratory testing to ensure everything works as expected. We tested all the time while developing the new features and we had prototypes where we were able to check the expected flow. Testing was done by the project developers and by the whole project team. With testing we used test students that existed already in the system.

5.2 Bug reporting

Different kind of problems with user flow, features that needed further development and bugs were reported to Jyväskylä personnel.

5.3 Conclusions on product's quality

We made a complete design and working prototype of the peer-review feature. We also spent time thinking the future development areas, like challenging the received peer review.

Code-wise there are some small improvements that s hould still be added to peer-review feature to make it fully suitable. Those improvements can be easily done following our prototype behaviour. After those are done, there should be a complete testing of the whole peer-review feature. We made really comprehensive testing plan and following that plan the quality of the whole feature will be ensured.

The features that we made ready for peer-review are tested well following the testing plan. We used components that already existed in TIM system so peer-review feature doesn't follow some of the basic heuristics of usability. Load testing should be added before releasing the feature.

6. Risks and problems

6.1 Foreseen risks

Risks from 1 to 5 where 5 is the most critical and 1 is the least critical.

• Unclear definitions and requirements, 5
• Changes on requirements, 4
• Complexity of the coding environment, 5
• Case of illness etc changes on the team, 3
• The lack of time, 5
• The lack of knowledge, 4

6.2 Risks not foreseen

Risks that were not foreseen and a short explanation why that risk has an impact.

• Corona virus – When the university shut its doors, all meetings and workshops became virtual. Even when using screen sharing and other technologies, solving issues remotely from the team is slower than when solving the issues face-to-face.
• Changes on requirements – This was a risk that was foreseen, but the number of changes was huge and that could’ve not been foreseen.
• Not gaining mutual understanding – It seemed hard to gain mutual understanding with the customer. In a project as this one, the main goal should be developing an MVP, instead of trying to create a system that has every little detail that could’ve ever been wished for. The development has to start somewhere and starting from an MVP is the way to do it.

7. Not implemented in this project

7.1 Not implemented product backlog items

Backlog contains programming and documenting tasks for the project. Most of them are implemented/done and these are in closed state. Total count of implemented items is 24. 5 items will not be implemented, 4 of them are related to plugin to improve usability and 1 is related to Velp filtering. Items with high priority have been implemented, mostly tasks that were required to implement functional peer review flow.

7.2 Rejected ideas

One of the biggest ideas we rejected was to use PLUS-system’s peer review feature in TIM too. PLUS-system is developed in different way than TIM so TIM and PLUS’s peer review wouldn’t have worked together easily.

Creating a timestamp managing into the peer reviewing system. Meaning that the peer reviewing period would’ve started when the deadline of the assignments is reached.

Creating a chart drawing system into TIM using draw.io as a plugin. This was rejected since it was developed by the customer between our weekly meetings.

7.3 Further development

One big feature to develop later is challenging the received peer review. That’s important feature at least of peer review affects to grade.

Teachers could have some sort of dashboard where they could see statistics, for example if someone didn’t receive any peer reviews.

TIM plugin could be implemented to make it easier to enable peer review for the document.

8. Lessons learnt

We as a team should have been stricter with the client and ensure that the client understands that we have very limited time with this project. We listened way too much all the different possible use cases they will need in the future while we should have from the very starting point pick one use case (the most important one) and focus on that the whole time. It’s not possible do develop a peer review system which works in every possible situation and in all different kinds of courses during this course. Those different use cases should be done in further development and we should have focused on producing a good starting point, an MVP for peer review feature.

Our biggest success was the algorithm we designed for grouping the peer review students. The algorithm works in different group sizes and with different number of students.

We are also very glad we managed to produce smooth and nice user flow with protypes and sketches, they are helpful with further development of the feature.

9. Comments about the course

It was quite a surprise that the client did not have anything more specific thoughts about the new feature than that they needed a peer review feature. We hoped that we as a team would have been prepared more to handle this kind of starting point before starting the project. We spent a huge time trying to figure out what the client needs and wants and what is the possible MVP that we can produce. We also spent a lot time getting to know other peer review systems which ended up being a total waste of time. We wish that there would have been more support from school personnel during this project. Project was way too wide and complex to be developed entirely during this course. It’s obviously not the same to start from the point where a client has no idea what they want or get ready made sketches of the new feature as some other project groups got. School should discuss more with client and ensure that the project is somehow doable during this short spring period time.

10. Statistics

Name of the project: TIM

Size of the group: 3 managers, 4 developers

Name of the customer: Jyväskylän Yliopisto

Bar chart of weekly working hours: Bar chart of realized working hours:

Appendix A: List of all software tools (UI design, development, communication, etc.) used in the project.