Software Engineering Project

This is the live page of the MPRI 1-31 course, by David Baelde and Amélie Ledein.

Agenda

Sessions will generally take place in 2E29; please watch the detailed schedule for details. Please bring your laptops when exercises are planned.

• 09/18 course organization, introduction to SE and presentation of project proposals
• 09/25 testing: lecture, example and exercises 1 & 2 (solutions 1 & 2) ;
• 10/02 project meetings
• 10/09 git tutorial and exercises; project meetings: infrastructure setup
• 10/16 project meetings
• 10/23 project meetings + design lecture and exercise
• 10/30 holidays
• 11/06 project meetings (mid-term exams)
• 11/13 project meetings
• 11/20 end of first phase, debriefing + second phase requirements
• 11/27 packaging guidelines (video) + exercise
• 12/04 advanced git tutorial + exercise (PDF, video)
• 12/11 project meetings + discussion on tools by language groups
• 12/18 project meeting
• 12/25 holidays
• 01/01 holidays
• 01/08 end of second phase, defense preparation
• 01/15 nothing
• 01/21, 14:00–16:30 defenses and demos: DOARM, PenGUI, Squirrel
• 01/22, 13:00–15:30 defenses and demos: Loki, Minisoap, Monocycle

Projects

• Squirrel dungeon battle: repo, requirements
• Adversarial machine learning platform Loki: repo, requirements
• Jump and run unicycle: repo, requirements
• PenGUI immediate GUI in Rust: repo, requirements
• DreamOfARidiculousMan rogue-like: repo, requirements
• Minisoap audio synthesis system: repo, requirements

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

Projects

Students should form groups and choose among several project proposals.

Hall of fame:

• Canabaelde (2019)
• Tim Dodge (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.).