Software Engineering Project

This is the live page of the MPRI 1-31 course, by David Baelde and Charlie Jacomme.

Agenda

All sessions take place in C321. Please bring your laptops when exercises are planned.

• 09/20 course organization, introduction to SE and presentation of project proposals
• 09/27 lecture on tests, exercises: find, bheap due on 10/11
• 10/04 git tutorial and exercises; project meeting: infrastructure setup
• 10/11 project meeting
• 10/18 lecture on design, design exercise (due by 11/08)
• 10/25 project meeting
• 11/01 holidays
• 11/08 project meeting (mid-term exams) (design exercice solutions)
• 11/15 networking exam + unsupervised project meeting
• 11/22 end of first phase, second phase requirements, advanced git tutorial + exercise
• 11/29 project meeting
• 12/06 no session due to "journée des carrières" project meeting
• 12/13 project meeting
• 12/20 project meeting, packaging guidelines + exercise (due by December 27th)
• 12/27 holidays
• 01/03 holidays
• 01/10 end of second phase, defense preparation
• 01/17 defenses and demos

Material

• Two modularizations for a KWIC index generator
• Some buggy code for binary heaps: bheap.py

Ressources

Legal aspects:

• What happens if you don't choose a license?
• How to use GNU licenses
• Overview of some open source licenses

Distributing software:

• Linux Hierarchy Standard
• GNU Coding Standards / The Release Process
• Packaging Python projects

Git guidelines

• How to write a git commit message
• Linus on clean history
• Git book: rewriting history

Projects

Students should form groups and choose among five project proposals (updated with 2nd phase requirements).

Projects in 2019:

• Magic
• Canabalt (private)
• Canabalt (rythmic variant)
• Minisoap

Hall of fame:

• Tim Dodge (2017)
• Accounting for Friends (2017)
• Paint 1 and 2 (2017)
• Rogue (2017)
• Dungeon (2015)
• Ocawai (2014)
• Geriatric Terrorist Anarchy (2013)

Requirements

Projects have to satisfy the following requirements, which will be the basis for grading. All requirements but the first one must have a corresponding issue on the development platform, where discussion will take place between students and evaluators, and evaluators will indicate when the requirement is satisfied. Note that satisfaction is not monotonic: a satisfied requirement may become unsatisfied later on.

• Platform: You must use a complete and modern development platform such as github, gitlab, etc. and continuous integration should be used to systematically build and test your software at least after each commit in master. The project must be accessible by teachers and other students. The evaluation of your project will be based on group meetings and content from the development platform: commits, issues, pull requests, comments, continuous integration.
• Standard structure: You must adopt a standard layout for your source code and build system. The build system should provide targets for building, installing, testing and generating the documentation. We also expect reasonable coding conventions regarding:
  • the naming of files, classes, variables, etc.;
  • the presentation of the code, including line length, spacing, markup in comments;
  • the promotion or avoidance of specific programming constructs or APIs;
  • other language- or technology-specific aspects.
  We strongly recommend using a lint-like tool.
• Functional correctness: Your software must satisfy the requirements from the project proposals. Every aspect must be unit tested; exceptions must be appropriately justified and approved by instructors.

The second phase imposes additional requirements:

• Tests: For each test, the property being tested must be clearly stated in natural language, and the test's code must correspond to that property.
• Commits: Every second-phase commit in master must be atomic and have a properly formatted commit message that accurately describes the change, indicating whether it's a new feature, a fix, etc. and referencing issues and other commits when relevant.

Optional requirements may bring extra points:

• Systematic use of issues: A high proportion (say 90%) of second-phase commits is explicitly linked to an issue where the relevant feature or bug is properly discussed. Using branches (and pull requests) is the best way to achieve this, to avoid having to link each commit separately.
• Outstanding contribution: To satisfy this requirement you must do something exceptional: deliver software that is particularly cool/reactive/efficient, implements additional features, or carry out your development in an interesting way (automation, debugging, etc.).