QR code to this page.
7.1.2015 - 1.0. Site open for spring 2015, basic information here, but schedule and topic are going to change
19.1.2015 - 1.1. The game has been described and the user stories published
26.1.2015 - 1.2. All dates are updated to 2015
18.2.2015 - 1.22. Many small updates to 2015.
18.2.2015 - 1.24. Canvas hints added.
23.3.2015 - 1.3. Link to blog post about End Gala.

TIE-21100 & TIE-21106 Software Engineering Methodology, spring 2015


Project assignment

Table of Contents


General things

The practical assignment consists of implementing and designing a small game with Processing environment. The game will be implemented with a small team of four students and in an iterative way. The methodology resembles Scrum. The pedagogical aim is to give the students hands-on experience with working as a part of a SW development team working with modern SW development methods.

  • Topic: An Wizball -like game VVizball, Wikipedia: Wizball.
  • Groups of three are also possible under special circumstances. However, the total work amount will still be the same. Ask Marko for more.
  • The assignment will be implemented in four sprints.
  • The sprint review meetings (1..4) with the assistant are mandatory. Remember to book all your meetings in time at Canvas. More information about requirements for different phases can be found on this page.
  • Questions? See FAQ first. You can always ask Marko or your assistant.
  • The requirements and schedule for the assignment may change during the spring. These are informed via e-mail you have set in Canvas.

Registration and forming a group

  • Sign in to Canvas with your account.
  • Form an assignment group in the Canvas page of this course. The deadline is Friday 23.01.2015 16 o'clock.
  • Groups with less than four people are combined later on. So, if you don't have a group and want to take part in the assignment, form a one-person group.

Schedule, spring 2015

Schedule

Events

By Fri 30.1. 16.00

Groups formed in Canvas of this course.

Mon 9.2. - Sun 1.3.

1st Sprint

By Fri 20.2. 16.00

Reserved sprint review meeting for Sprint 1

Mon 23.2. - Fri 27.2.

Sprint review meeting for Sprint 1

Mon 2.3. - Sun 29.3.

2nd Sprint

By Fri 20.3. 16.00

Reserved sprint review meeting for Sprint 2

Mon 23.3. - Fri 27.3.

Sprint review meeting for Sprint 2

Mon 30.3. - Sun 26.4.

3rd Sprint

By Fri 17.4. 16.00

Reserved sprint review meeting for Sprint 3

Mon 20.4. - Fri 24.4.

Sprint review meeting for Sprint 3

Mon 27.4. - Sun 24.5.

4th Sprint

Fri 15.5. 16.00

Returned material for project retrospective meeting

Mon 18.5. - Fri 29.5.

Assessing the material of Sprint 4 and project retrospective

Fri 15.5. 12.00 - 16.00

End Gala: Presentation of the games


An overview and grading

  • The exercise will be worth of 6 points maximum:
    • Project plan and study diary 0-1 p
    • The sprint review meeting with an assistant, 1 point per sprint. As there is four sprints, the max points will be 4. To get the points:
      • The sprint goals have been achieved. The selected tasks to the sprint backlog are done,
      • You have a documentation of the sprint work amounts (a burndown or similar graph). The work should be evenly distributed, no last minute miracles.
      • You have updated the Project Plan and Study Diary (= 1 document).
    • Participating the final presentations 0-1p
  • All parts are mandatory.
  • If some parts are not done due the deadline, either the assignment will be graded as a failure or you have to submit the missing tasks. The total score will be lowered.
  • Using some version control software starting from the first Sprint (1) gives your group one additional (extra) point (+ 1 p). That is a volunteer additional task, not a required part of project assignment.

General document return policy

  • Project Plan and Study Diary are one document (as you have noticed from the document template).
  • Returning of the document is done via Canvas.
  • There will be a short text about guiding you on returning files with Canvas.
  • All documents to the sprint reviews must be returned on previous Friday via Canvas.. If the meeting is on Monday, the deadline is Friday 16 o'clocl, and if the meeting is on Thursday, you should return the document on still before Fri 16 o'clock.

Sprint review general guidelines

  • All sprints (1..4) have a special review meeting.
  • All sprint review meetings are mandatory.
  • You have to reserve a time for the review meeting for your assistant. Use Canvas (there will be short text about guiding you on that.).
  • Some documents (Project Plan) are returned in advance for the sprint review. In addition, some documents are necessary for the review meeting.
    • General guidelines for the returned documents must be followed.
  • Every member of the group must be present.
    • If you have a force majeure situation, you must ask for a permission from the assistant before the meeting.
  • You should have had your sprint planning meeting as soon as possible after the sprint review meeting, as the assistants will check Agilefant for your next sprint plans by the next Monday after your meeting time

How to reserve a sprint review appointment in Canvas

  • In Canvas, select "Calendar" from dark grey horizontal bar.
  • From there select "Sprint (number) review for (assistant-name)"
  • Select the rightmost button, the "Scheduler" view.
  • Now you should have a calendar view to your assistant's time slots for appointments. If not, try to change the week with arrow buttons.
  • Select a free time-slot, click it and "Reserve".

Agilefant

  • Agilefant is a project management / backlog management tool for agile methodologies, such as Scrum.
  • You should use Agilefant during the whole assignment. It keeps track of your done and undone tasks.
    • Agilefant should be used to record all hours spent on the assignment. These include familiarizing yourselves with tools, project planning meetings, Project Plan document writing and updates, and emails etc., (those may be "tasks without story" in an iteration).
    • Try to have small enough tasks in order to have uniform estimations. If a task seems too big to be estimated accurately, you should split the task into several smaller ones.
  • Agilefant user account information will be delivered to groups before Sprint 1.
  • You can check the general instructions here: http://www.agilefant.org/
  • There will be one weekly exercise concerning Agilefant.

Project plan and study diary

How to return the project plan for the sprint review meeting

  • Select "Assignments" from left sidebar.
  • From "Upcoming Assignments" select "Sprint review".
  • On the right side you have "Submit assignment" functionality, click it.
  • And then add a file. Remember good practices on file naming (e.g. group number = unique, short, descriptive, without blanks).

Option one: VVizball

  • Implemented with Processing environment.
  • Processing is also installed in Lintula/Birdland.
  • There is one weekly exercise on topic Processing. However, you are strongly encouraged to explore the possibilities of the environment by yourself.
  • The basic idea of the game can be found in Wikipedia: Wizball. However, our version is the 2015 version, a version of Wizball whit a whiz, so to say. The basic vision is in the User stories. The some new features compared to the original Wizball combination with game VVVVVV to include the concept of gravity flip. You also should use your imagination in designing your game to be the best one in the market.
  • Nice graphics or extensive feature set cannot guarantee you full points (the assignment is more about the methods of development process, not coding or graphic design), but it may give you better change to win the prize in the End Gala.

User stories

Here is the initial product backlog as an ordered list. This is NOT the definition of the final product cast in stone. Rather, it reflects the product owner's initial vision of the product now and will have some inaccuracies in it. In the beginning, you can follow this list, but after a while, you should build your own product backlog. In this assignment, the stakeholders will be the assistant, the group and the other students, too. So, your group's product owner (a role that can be shared amongst you) should aim at the maximum return on the investment. Thus, your final work should try to satisfy the course requirements, be fun for you and perhaps win you the prize in the final presentation! To satisfy the course requirements, you should commit to at least two or three stories per sprint. If you modify the stories or add your own, the estimated work amount will be what counts. Thus, you cannot strip features without adding an equivalent amount of work. However, you are encouraged to be creative with the assignment and stand out in the final presentation.

  • User story 1:
    • When the application starts, it will inquire the player's name.
    • After this, the game greets the player, tells a compelling background story and the game will begin.
  • User story 2:
    • When the game starts, it will show the player character (the ball) in the middle of the 2D play area. The play area consists of floor on which the ball bounces and a background.
    • The ball can be manoeuvred around the screen using the keyboard. When ever ball bounces up, it may be decelerated with a key press. When the ball is coming down, it may be accelerated with key presses. The ball's velocity while impacting the floor will set the trajectory for the next bounce.
  • User story 3:
    • The play area will also have different platforms "in the air" on which the ball can land or bounce from. These are basically just more floor in the air. There is also a "ceiling".
    • The ball will have velocity and momentum. The ball will accelerate automatically when it falls down due to gravitational acceleration. With a special key, the direction of the gravity can be changed from downward force to upward force and vice versa.
    • The rebound will be determined based on the angle of impact, elasticity and velocity and the laws of conservation of energy, just as in the real world.
  • User story 4:
    • The play area will scroll when ever the ball approaches the either the left or right border of the screen. The scrolling area reveals more and more of new floor and platforms. There might be holes in the floor and ceiling, allowing the ball to exit the screen from upper or lower border. The game ends if the ball exits from these holes.
    • The background will also scroll with the level, preferably using some form of parallax scrolling.
  • User story 5:
    • There is a timer counting down seconds from an initial value shown on the screen. When it reaches zero, the game ends.
    • If the ball reaches the end of the game level (the farthest point in the right of the level) before timer runs out, the player can continue from the next game level.
  • User story 6:
    • Some nasties are also infesting the game level, flying, hovering, crawling, standing, bouncing around. If the ball hits a nasty, the game ends.
    • However, there also are some power-ups around the level, too. With a power-up, the ball can temporarily collide with a nasty, destroying the nasty instead of the ball.
  • User story 7:
    • There also is some special power-ups the ball has to collect before entering the level exit.
    • Destroying nasties and collecting specialities bestows the player score points which are shown on the screen. Enough points give the player an extra life.
  • User story 8:
    • When the game ends, a scoreboard is shown where the player names are shown with the corresponding scrore.

  • User story 9:
    • There are different kinds of weapons to be collected, which the player can select with the keyboard.
    • A laser beam can be used to shoot nasties, but it has to be charged in between shots...
    • ...
  • User story X:
    • Your favourite features

1stSprint review

  • Schedule:
    • Review meeting time reserved by fri 20.2.2015 16 o'clock
    • Sprint review meetings are held from mon 23.2.to fri 27.2.2015
  • Document is to be returned beforehand (Project plan):
    • Project plan+study diary
      • Resources for the project (personnel, available time and so on)
      • Lessons learned in sprint 1 in study diary
        • Highlights
        • Failures & problems
        • What you are going to improve in the next sprint
      • A simple risk mitigation plan
    • Check out the generic document return policy.
  • Things to have with you at the meeting:
    • Your application. You should be able to present both the code and a running application. Bring your own laptop or arrange something with the assistant beforehand.
    • Access to your project management data, either on-line or prints.
  • Other requirements
    • At least two implemented user stories.
    • Documentation (in Agilefant, for example) of your burn-up/burndown charts in the sprint.
    • Some plans for your next sprint backlog (for example, are you going to change the order of user stories, any changes or clarfications to the user stories you are going to implement, any new user stories?)

2nd Sprint review

  • Schedule:
    • Review meeting time reserved by fri 20.3. 16 o'clock
    • Sprint review meetings are held from mon 23.3. - fri 27.3.2015
  • Documents to be returned beforehand (1 doc):
    • Project plan+study diary
      • Resources for the project (personnel, available time and so on)
      • Lessons learned in sprint 2 in study diary
        • Highlights
        • Failures
        • What you are going to improve in the next sprint
      • Risk mitigation plan
    • Check out the generic document return policy
  • Things to have with you at the meeting:
    • Your application. You should be able to present both the code and a running application. Bring your own laptop or arrange something with the assistant beforehand.
    • Access to your project management data
  • Other requirements
    • At least two implemented user stories.
    • Documentation (in Agilefant, for example) of your burn-up/burndown charts in the sprint.
    • Some plans for your next sprint backlog (for example, are you going to change the order of user stories, any changes or clarfications to the user stories you are going to implement, any new user stories?)

3rd Sprint review

  • Schedule:
    • Review meeting time reserved by fri 17.4. klo 16 o'clock
    • Sprint review meetings are held from mon 20.4. - fri 24.4.2015
  • Documents to be returned beforehand (1 doc):
    • Project plan+study diary
      • Resources for the project (personnel, available time and so on)
      • Lessons learned in sprint 3 in study diary
        • Highlights
        • Failures
        • What you are going to improve in the next sprint
      • Risk mitigation plan
    • Check out the generic document return policy
  • Things to have with you at the meeting:
    • Your application. You should be able to present both the code and a running application. Bring your own laptop or arrange something with the assistant beforehand.
    • Access to your project management data
  • Other requirements
    • At least two implemented user stories.
    • Documentation (in Agilefant, for example) of your burn-up/burndown charts in the sprint.
    • Some plans for your next sprint backlog (for example, are you going to change the order of user stories, any changes or clarfications to the user stories you are going to implement, any new user stories?)

4th sprint, the delivery of the product and the project retrospective

  • Schedule:
    • Retrospective meeting time reserved by fri 15.5. klo 16 o'clock
    • Project retrospective meetings are held from mon 18.5. - fri 29.5.2015
  • Documents to be returned beforehand (3 docs):
    • Project plan+study diary
      • Resources, risks and such things updated.
      • Study diary collected during the sprint
    • Source code
      • Zip/rar archive sent via Canvas (or e-mail) to your assistant
        • Archive naming G<group number>-WA.<arch>, e.g. G10-WA.zip
        • E-mail subject TIE-21106: G<Group number>-WA, e.g. TIE-21106: G10 WA
    • Manual
      • A PDF file, attached to the same sending as the source code
      • Filename G-<group number>-WA.pdf, e.g. G42-WA.pdf
      • Contents:
        • Game instructions (how the game works, what is the goal, etc.)
        • Controls (which keys to use, mouse...)
        • How the user interface works
        • Different nasties and other kinds of NPC objects (non-player character)
        • Installation (processing version, required libraries)
        • Other things
      • The document is free form
      • Don't spend too much time on this. A good rule of thumb would be 2 hours of work maximum.
    • Check out the generic document return policy
  • Things to have with you at the meeting:
    • Your application. You should be able to present both the code and a running application. Bring your own laptop or arrange something with the assistant beforehand.
    • Access to your project management data
  • Other requirements
    • At least two implemented user stories.
    • Documentation (in Agilefant, for example) of your burn-up/burndown charts in the sprint.

Final presentations

  • A special event in the end of the course. The students have the opportunity to show their end results to the other groups.
  • There is 1 point award from attending the session.
  • The presentation is free-form. However, your group has 10 minutes to set up the presentation, tell about your project (highlights, lessons learned et.) and show yout game, answer some questions and leave the stage.
    • Show your game
    • Tell the highlights and lessons learned of the project
    • You can show some project management data (burndowns and so on)
  • The best presentation selected by the students is awarded with a small prize.
Here is the blog entry about the final presentations of 2014.

Tools and document templates

  • Git
    • You can use TUT Gitlab
    • Every student has rights to create up to five repositories
  • Project plan and study diary template:

Frequently asked questions

  • Can we swap Processing to another language and/or development environment?
    • Most probably yes. The main requirement for the environment is that the assistant can easily run your application on his/her own laptop. If you want to try other languages, please inform your assistant with an e-mail. Include your reasoning why to change and what will be your language of choice and what it will take to set-up a runtime environment to a virgin computer.
  • Can we change the user stories?
    • Yes. You have free hands to change them as long as the main idea of the game stays the same and the workload is not significantly diminished.
  • Processing IDE sucks, are there any alternatives?
    • Yes. You can use for example Sublime Text 2. It can also build the application for you, see this link for example. Eclipse works, too. Vim is no exception. So, several options exist.
  • Can we use the library X?
    • Using libraries is allowed and even encouraged. However, to ease the use of your application, you should keep a list of used libraries and a small how-to document how the libraries are used.
    • Some tried and tested libraries by students:

Tips for group work

  • Patterns for Group Assignments [1] [2]

Personnel

  • Marko: <marko.leppanen(at)tut.fi> (send general questions to Marko)
  • Harsha: <sriharsha.vathsavayi(at)tut.fi> (Harsha's groups questions here)
  • Tensu: <tero.ahtee(at)tut.fi> (Tensu's groups questions here)

Tips for group work

  • Patterns for Group Assignments [1] [2]