Guidelines for the course's project

Project proposal (stage 1)

During stage 1 of the project, you sent your adviser a project proposal. If your proposal was approved you may continue to the second stage that is described below.

Project planning (stage 2)

Note: the project planning stage constitutes 30% of your final project's grade. The grade is given based on the quality of your planning, and also for following the guidelines that are listed here, therefore you should read them carefully.

(1) Repository setup

Each team will have a single GitHub repository for the project. Note that by team we also mean a single student.

• Each team should fill-in this Google form. After filling-in the form, we will create a repository for the team within this GitHub organization (it may take a few days).

(2) Update README.md

In GitHub, the file README.md is the starting point for someone who wishes to learn about your project.

• Update the README.md file of your project with a short summary of your project's proposal. You are encouraged to learn about GitHub Markdown for styling your text.

(3) Create a ProductBacklog

This is the main task of the planning stage. The ProductBacklog is a list of functional and non-functional requirements (stories), that when turned into functionality, will deliver the vision.

• The ProductBacklog should be created as a GitHub Project as shown in this reference Backlog.
• Carefully read and follow the guidelines attached to that reference Backlog.

(4) Using appropriate software engineering planning methods

You are requested to make an appropriate use of software engineering methods that were taught in class during the planning stage. These mainly include requirement engineering methods, and architecture/design methods. The use of testing methods is also relevant, mostly in defining acceptance tests for the stories.

We are asking you to take an agile approach and produce those diagrams that will help you to produce the best ProductBacklog and to communicate the system to be developed to other stakeholders (including you and us). It is your task to go over the learning materials and search for those methods that fit your specific case.

In principle, the produced artifacts should be placed in the project's Wiki. You may also attach artifacts to a specific Issue of a user story.

Some notes about projects 2,3

The above mentioned guidelines are expressed in a terminology that is more "natural" and understood to the first type of the project - developing a software product. You may wonder how these guidelines fit with the other 2 types, namely, investigating an existing GitHub project (type 2), and conducting a software process improvement (SPI) project (type 3).

The general answer is that also for those project types, a ProductBacklog is of course relevant, and also the use of software engineering methods for planning and communication. You should understand what "user stories" mean in your context (who are your users?) and this will lead you to the correct planning.

We will add more clarifications about that during the class and also document them here.

• Read here about comments sent to students while checking the planning phase so you can learn from the mistakes of others.

Sprint development (stage 3)

In this stage you will implement the stories of Sprint 1. Move to that stage only after your adviser has approved Stage 2.

Notes:

• Make sure that project's artifacts such as ProductBacklog, README, Diagrams, etc. are synchronized with the actual development.
• You work with GitHub should be continuous. In particular, do not commit your code a few days before the end of the project, but do it on a daily (or weekly) basis.
• Use GitHub features wisely. For example, add comments to issues to reflect decisions made during the development, link commit comments to issues, create labels that you actually need.

Remember: the goal is not to produce the best product but to use best software engineering practices, so make sure that you pay attention to SE practices using the development.

Project closure (stage 4)

Closing the projects means:

1. Organize your GitHub project's repository as explained below.
2. Create a final presentation (PPT) file.

And now to the details.

Organizing your GitHub repository

• Polish your README file. Note that this file is the starting point for someone who is interested in your project. Make sure it is well written, e.g., divided into logical sections, and that it contains the relevant material based on your project's type. For project 1, the README should include: about the tool, detailed installation guidelines, how to use the tool, tips for maintainers, e.g., key classes and methods. For other projects, the README should summarize the project and the work done including links to key artifacts.
• Updated ProductBacklog. Make sure your ProductBacklog is updated and reflects the current state of development. Note that the ProductBacklog should be updated during the project and not only by the end of it.
• Documentation. Create Wiki page/s describing the methods you used to make your work on the project more effective. This includes a summary of the software engineering (SE) methods practiced in the project including diagrams if they exist, how you used GitHub for the project, planning methods, communication methods, etc. Naturally, SE methods are more relevant to project 1, but note that some methods such as describing stakeholders in a use case diagram are also relevant to other projects. Whenever possible, provide links to relevant artifacts. For example, if you describe the unit testing done in the project, link to relevant locations in the code.
• External artifacts. You should include in the repository any key artifacts that were produced and used during the project even if they were not listed above.

The final presentation file

You should create a single PPT file summarizing your project, with the following general structure, that you may refine according to your project's context:

• Introduction and motivation
• Planning
• Execution (Development)
• Results
• Conclusions

Prepare a presentation for a 30 minute talk. It sounds reasonable to have around 30 slides (at most).

Note: we are considering a different presentation format this semester, where some of the teams will not have "live" presentation of the project, and their project will be checked "offline". You will be notified about that later on, and in any case, it should not affect your preparation.