Guidelines

Posted on Author Timo Poranen

Credits and grading

Course grading is mainly based on

  • the end product (including code) and process quality,
  • customer satisfaction,
  • documentation and reviews,
  • active participation in project activities,
  • reporting and personal reports,
  • presentations, and
  • how the schedule was followed.

It is possible that there are different grades in a team. In the Software Project Management course there is more emphasis on management practices, reporting, and general project organisation.

To pass the course, the project team must produce a running piece of software that implements a reasonable number of client requirements.

The amount of ECTS credits in the TIEA4 Project Work is 5 (this corresponds to 5*26.7h = 133.5h of work). All students are required to contribute at least 115 hours of work for their project.

The amount of credits in the TIETS19 Software Project Management (Practice) is 7 (this corresponds to 7*26.7h = 186.9h of work). All TIETS19 students are required to contribute at least 161 hours of work for their project.

Software Project Management (Theory) gives 3 credits.

First Meeting with the team

In the beginning of the course, get acquainted with other managers of your project, if there are any. Contact them via e-mail first. The list with e-mail addresses of all your project members will be sent to you by the course supervisor. Decide on who will be responsible for contacting the other project members and setting up the first meeting.

2021S projects: Teams will meet virtually (Zoom’s breakout rooms) during second part (11.00-11.45) of Friday’s 22.1.2021 lecture.

2021S project: Because of COVID-19, teams work remotely.

Communication between project managers is crucial! Communicate actively by all means.

Contact project members

Contact team members via e-mail. Describe the project in a nutshell and ask team members to send information about themselves, such as:

  • Name, phone number
  • Where he/she is from
  • What/where he/she studies
  • Is he/she here as an exchange or an undergraduate student
  • Skills and experience in: graphical design, sound design, testing, interaction, usability, web page design, web servers
  • Any other skills or previous experience related to the project.

This information will help later to assign tasks within the project.

Managers can create a Slack-team / facebook group / etc. for communication (see recommended tools).

In order to set up the first meeting you will have to decide on the time and place. The meeting time should be negotiated with other team members. Try to have all team members present in the first meeting. The university and its library (Linna) have meeting rooms that can be reserved online.

Make a plan on what are you going to discuss in the first meeting, such as:

  • Introduce yourself and other managers + talk about the project.
  • Everybody should introduce themselves and talk about their interests in the project.
  • Everyone’s goals about the project and the course.
  • Time of the weekly meetings.
  • Means of communication (facebook, slack/flowdock, whatsap, …)
  • What to do next: Project plan, tool training, meeting with the client,…

Meetings with the course staff

There are 5 compulsory meetings with the course staff during the project: the project plan inspection, three iteration reviews and the final meeting. Teams should have more internal review meetings. To reserve a meeting time, please check the project supervisor’s schedule. You may return the documents in any commonly used format (.pdf, .ood, .doc, .rtf,…) or as a link, but .pdf is the recommended format (other formats might have printing problems).

In the review meetings, teams must follow the review meeting agenda. For all these meetings, the team must send a meeting agenda/invitation in advance, and send material at least 48 hours before the meeting. After the meeting, team must write meeting notes and send the notes to all stakeholders. 

Compulsory meetings for 2021S-projects.

Meeting Participants Duration Deadline Return material
Project plan inspection Team+supervisor+client 2 hours 12.2.2021 48 hours before
Review 1 Team+supervisor+client 2 hours 26.2.2021 48 hours before
Review 2 Team+supervisor+client 2 hours 26.3.2021 48 hours before
Review 3 Team+supervisor+client 2 hours 23.4.2021 48 hours before
Final report meeting Team+supervisor+client 2 hour 14.5.2021 48 hours before

Compulsory meetings for 2020F-projects.

Meeting Participants Duration Deadline Return material
Project plan inspection Team+supervisor+client 2 hours  25.9 48 hours before
Review 1 Team+supervisor+client 2 hours  16.10 48 hours before
Review 2 Team+supervisor+client 2 hours  13.11 48 hours before
Review 3 Team+supervisor+client 2 hours  11.12 48 hours before
Final (report) meeting Team+supervisor+client 2 hour  15.1 48 hours before

Scheduling a meeting with the course staff

Recommendation: After project plan inspection meeting, schedule all forthcoming meetings.

Timo Poranen: 1) Check available meeting times from the calendar. 2) Send an email where you tell: Meeting date and time, meeting place, and purpose of the meeting. 3) Wait confirmation. 4. Send invitation.

Pekka Mäkiaho 1) Make all the meeting invations to Pekka Mäkiaho by using TAU’s Office365-calendar (pekka.makiaho@tuni.fi).

In nutshell

  • Check the availability of course staff and the other participants, early enough, and decide the meeting time and place.
  • Send the invitation to all the participants.
  • Send the material to all the participant (agenda, documents (e.g. project plan) at least 48 hours before the meeting.
  • Prepare for the meeting.

Meeting rooms

  • During academic year 2020-2021, teams work remotely.
  • Group work space Pinni B1076 is suitable for project meetings. B1076 has a reservation book near the door.
  • Linna’s group work rooms.

Tool training

Project managers are in charge of organising tool training for the team. They describe and demonstrate how the training was performed during the project plan inspection. It is required that all students familiarise themselves with the following tools:

  • UI design tool
    • All team members should try and design at least one UI mockup.
  • Version control
    • Many projects are using github at the moment. You can study Git course in Tuni Plussa.
    • Tuni Gitlab. Contact responsible teacher if you need a code repository from university.
    • TortoiseSVN (Windows) can be used as a graphical user interface tool for using subversion.
    • TortoiseGit (Windows) is for Git.
    • All team members make a small update (at least one line of code) to the team’s version control system.
  • Project management tool
    • All team members test a project management took (Trello, Trac, JIRA,…)
  • IDE: Eclipse/NetBeans/some other IDE (integrated development environment)
    • Project managers decide which IDE will be used and taught to the team.
  • “Hello world” application for the project
    • A very small test for the development environment. The example must be shown during the project plan inspection.
  • Logging (voluntary)
    • Familiarise the team with logging (what it is, how it will be done in your project, etc.).
    • Try to find a suitable logging tool/library/platform for your project.
    • Properly implemented logging of application behaviour is important for a variety of reasons: producing an audit trail, catching bugs, analyzing which features are used and how…
    • Each platform has its own logging frameworks, you need to do some research to compare the alternatives and pick one that fits the project’s needs.
    • Apache Logging Services provide ports of the popular log4j framework for different platforms (Java, PHP, .NET, C++).
  • Unit testing (voluntary)
    • Familiarise the team with unit testing (what it is).
    • Think and investigate should unit tests be used in your project.

The deadline to organise the training is the same as the project plan inspection deadline.

Requirements management

Projects should follow their development model’s recommendations when managing and documenting requirements. One possibility to document requirements is to write a requirements specification document. Other often used methods are use cases and user stories. See also an article by Scott W. Ambler on Agile requirements modeling.

Requirements can be divided into functional and non-functional requirements.

A use case is often split into more detailed requirements. A functional requirement might be in different states during the project.

  • in Product Backlog – client or project team has proposed a requirement and the requirement is added to the Product Backlog.
  • in Progress – the group has committed to implement the requirement in the current iteration. Team designs, implements, and tests the requirement. In Scrum: the requirement is in the Sprint Backlog
  • Done – the requirement is implemented and completely tested. The feature is done (see the definition of done from your Project Plan).
  • Rejected (Deleted) – the requirement is rejected for some reason. It might have been a dublicate, or for some reason the project is not going to implement the feature. Rejection reason should be documented

Notice that a requirement should be only in one state at one time.

At some point in a project the statuses of all the requirements might be as follows:

FUNCTIONAL REQUIREMENTS: 20 / 5 / 2 / 0

This sample situation might happen in the second week of the first iteration. There was originally 27 requirements in the Product Backlog, the group has committed to implement 7 requirements in this iteration and so far they have implemented two of them. There are no rejected requirements.

Each project team reports these statuses using Metrics Monitoring Tool. Notice that each requirement must have only one status at any point, so the number of requirements with the “in Product Backlog” status always decreases when the requirement is moved to the “in Progress” state.

Quality attributes for requirements

Below is a checklist of quality requirement attributes originally defined in the IEEE standard. These attributes are ordered so that the most important attributes for student projects are listed on the top. Although these attributes are all important to ensure the requirements’ quality, the first four or five features may be emphasized and should be taken into account in every student project.

  • Correctness: The requirements have to reflect the expected behavior of the users and customers. They have to be consistent with the business objective or the project scope.
  • Comprehensibility: The requirements are understood by all stakeholders.
  • Unambiguity: The requirements should be read in exactly one way by different people (clarify confusing terms in a glossary).
  • Right level of detail: The information given in the requirements is suitable to gain the right understanding of the system and to start implementation.
  • Completeness: All important elements that are relevant to fulfill the different client’s tasks should be specified.
  • Consistency: The stated requirements should be consistent with all other requirements, and other important constraints such as hardware restrictions, budget restrictions, etc.
  • Priority: Each requirement is specified with its importance and/or its stability.
  • Verifiable (especially applies to NFR): There exists a process for a machine or a human to check whether the requirement is fulfilled or not. (NFR is specified in a measurable way)
  • Modifiable: The structure of the SRS allows the integration of changes in an easy, consistent and complete way.
  • Traceable: It should be possible to reference the requirement in an easy way (possible to identify the origin of a requirement).
  • Feasibility: The requirements can be implemented with the available technology, human resources, budget and schedule.

Project plan inspection

Project plan inspection is a formal and compulsory course meeting where the team, the client, the course supervisor and other stakeholders meet and inspect the project plan. The purpose of the meeting is to recognize faults, misunderstandings and possible problems (like scheduling) in the project plan. After the meeting, all participants should have a shared understanding of the contents of the project plan.

Preparation

  • The team writes the project plan.
  • Project managers find a suitable inspection time and place so that all stakeholders can participate.
  • The team sends the project plan to all stakeholders 48 hours before the inspection.
  • Everyone (team members too!) reads the document and marks problematic parts.
  • If someone can’t participate, they should send their notes to the secretary (or to the project managers) before the inspection.
  • The managers are responsible to arrange training on project tools for all members who need it. Also, a “hello world” application must be implemented before the project plan inspection.
  • Reserve time for checking the equipment (laptop, projector, Kinect…) If you invite the client to be present at 12.00, make sure that the meeting really begins at 12 sharp.

During the inspection

  • The leader ensures that it won’t take over two hours to inspect the document.
  • The leader can show the plan (or a list of findings) using a projector.
  • The leader asks for comments to every chapter / section / subsection / paragraph systematically. The whole plan will be checked starting from the first (title) page.
  • The secretary writes meeting notes, including a list of findings on problematic parts.
  • The goal is to find and recognize problems, not to solve them immediately (especially if solving the problem needs a longer discussion). The problems can be handled after the meeting.
  • After the inspection, the team shows their “hello world” application and the managers explain how the team has been trained to use main project tools.

After the inspection

  • Meeting notes must be sent to the project supervisor and to all other stakeholders. Only after receiving the meeting notes will the course staff update the statistics page.
  • An updated version of the project plan should be sent to all stakeholders.

Reviews and review meeting agenda

In addition to the project plan inspection, there are three review meetings with the project supervisor during the course. The following agenda should be used in the review meetings. The managers should send the agenda beforehand to all participants.

  • Project managers welcome participants to the review meeting.
    • Assigning roles: leader (usually one of the project managers), secretary.
    • Is everyone (team, client, course staff…) present?
    • Is there anything to add to the agenda?
  • The team gives an overview of how the iteration went and what they have done during the iteration.
  • Project managers show an overview of the team’s working hours (from Metrics Monitoring Tool).
  • Requirements
    • The project team gives an overview of the requirements documentation / use cases / tasks / etc. used to maintain requirements.
    • The team gives/shows a list of requirements and their corresponding statuses (in Product Backlog, In Progress, Done, Rejected). The statuses of different requirements are explained and discussed. This list can be added to the meeting minutes.
    • All implemented features are demonstrated. The team member who did the task can demonstrate the result (you can show the corresponding code or some other outcome, tell about testing, show how it works, did you encounter problems, etc.).
    • Unimplemented tasks are discussed (why the task is not implemented, problems, etc.)
  • Testing and Code
    • Project managers give an overview of the current state of the code repository and show recent changes and commits to the repository.
    • The team shows/explains how the implemented features were tested. The team shows their test cases and/or other relevant test documentation.
  • Design + UI design
    • The team shows the architectural design of the application (high-level package diagram, class diagram, database diagram).
    • The team shows UI design documentation / mockups.
  • Risks (from Metrics Monitoring Tool).
  • The team describes what they are going to do next (which requirements will be implemented next, etc.)
  • Other issues.
  • Finishing the meeting. Decide when is the next review meeting.

Teams can add more items to the meeting agenda, but the issues mentioned above must be discussed (even shortly) in the review meeting. It is also OK to change the order of the items in the agenda.

After the review meeting notes must be sent to the project supervisor and to all other stakeholders. Only after receiving the meeting notes will the course staff update the statistics page.

Working hour reporting

Metrics Monitoring Tool is used for logging working hours. Read guidelines on work categories.

The following information is needed when working hours are logged: Name, Date, Hours, Activity, Iteration, Work category. The iteration is the current iteration of the project. The iteration is 0 until the project plan is inspected, then the number of iteration depends on the project’s phase (1,2,…,)

A simple example:

Timo Poranen, 8.9.2017, 2 hours, Initial lecture, 0, LECT.

Final meeting

In the final meeting the project team, client and the project supervisor discuss the team’s experiences. Before this meeting, the team returns the final report and test report to the supervisor. The final meeting finishes the project. The team can return the delivery package / project CD also in the meeting.

If a team member has worked less than the required number of hours, project managers should propose extra project-related tasks to this member in the meeting.

Even though this meeting is informal, the minutes are written, mentioning at least the time, place and participants. Moreover, if there are still open items, e.g. minor corrections or missing deliverables, then action points are written down stating who is to take action, what is to be done by when and how this will be verified. Only after these action points are closed will the credits be given.

After the final meeting team members should answer personal report II questions in the Moodle.

Project poster

Project poster is an A4-size pdf-document. The poster must contain at least the following information: name of the project in the top of the poster, course details “TIEA4 and TIETS19 – Fall 2020”, include at least one screenshot of your application, description of the project and team member names. The poster is not published in electronic form outside the course (only in course’s Moodle forum), but paper copies can be printed for introducing the projects for educational purposes. It is still recommended that teams publish their posters in github etc. (see, for example Tomorrow-project, Poster.png).

If a team member does not want to publish his name, then you can leave that information out from the poster.

Return the poster before project presentations to the lecturer. The posters will be linked to the presentation schedule (in Moodle), then printed and put into some wall in the faculty’s premises.