Student notice
automatic translation of the ‘Notice élèves’ page
Introduction
All second-year students (except those following the ATPA research track) take part in the software project. They are divided into groups of 4 to 5 students. This project provides an opportunity to deepen and put into practice the knowledge acquired during the first-year computer science courses. The composition of the groups is determined by the computer science teaching department.
The work required consists in building an application that addresses the problem described in the proposed subject. This work is divided into 2 main phases:
- Preliminary study and general design
- explain the need
- describe the proposed solution
- plan the main phases of the implementation
- describe the functional requirements through modeling (UML diagrams)
- plan the implementation of the features (dependencies, priorities…)
- Implementation
- setting up the database
- developing the application in Python
Halfway through the project, you will submit the analysis report corresponding to the work carried out during the first phase.
At the end of the project, you will submit a complete report, as well as your code.
You will present your work during an oral defense.
Project launch
Project teams
The teams are formed by the person in charge of the course, taking into account the levels observed in computer science during the first year and ensuring a balanced distribution of students directly admitted to the second year. It is essential to ensure that students admitted based on their qualifications are properly integrated into the teams.
- A weighted average is calculated for each student based on their first-year grades in computer science subjects
- OOP documentation and testing: 0.5, Relational Databases: 0.2, Algorithms and complexity: 0.2, Data processing project: 0.1
- Following this ranking, the students are divided into 4 pools
- Each team is composed of one student from each pool
The team composition cannot be changed!
The subject
You will be supervised by a tutor who will follow 4 teams throughout the project.
Each of the 9 supervisors has proposed a subject that should allow you to apply all the computer science subjects taught during the first year:
- Application design with UML
- Algorithms
- Object-oriented programming with Python
- Relational databases
The subjects are randomly assigned to the teams. The diversity of backgrounds (English, Dauphine…), the tight deadlines and the associated constraints mean that it is not possible to let you choose your preferences.
First session
Based on feedback from students, the first meeting between members of the same team is important. It is an opportunity for you to get to know each other and to discuss honestly your skills and what you expect from the project. Teams that support each other and work well together are the ones that perform best. There is no magic formula: each team must agree on how it will operate.
Organization and monitoring
Project manager
Within each team, students must appoint a project manager who:
- will be responsible for coordinating the group
- will organize work meetings
- will ensure task allocation, progress monitoring and compliance with the schedule
They are the main point of contact between the supervisor and the team they represent. They must facilitate discussion and collective decision-making.
This role is not related to computer skills, but rather to an interest in team management. You must nevertheless be involved and interested in the work.
Technical lead
This role generally goes to the person with the greatest interest in computer science. Their main responsibilities are:
- git reference person: make sure that all members understand the basics of git, have cloned the repository and know how to share their changes
- code a v0 (for example by using the provided template as a starting point) and explain to the others how it works (a sequence diagram can be very useful)
- assist members in case of technical difficulties
To avoid an excessive workload, it is strongly recommended not to combine the roles of tech lead and project manager.
There may of course be other roles within the team. The important thing is to take initiatives on a topic you enjoy and be an active contributor to the project.
You are engineers, you have ideas, and you should take initiatives. This will be a real asset when you enter the professional world!
Crisis
If the work or involvement of one or more team members falls below expectations, their grades may be separated from those of the rest of the group. This will only be possible after alerting your tutor and the person responsible for the course, and after a discussion with the group has taken place.
Project management and communication
It is recommended to use Microsoft Teams to plan your work and communicate. Creating a conversation for the group seems to be the bare minimum. But you can also install plugins to help you manage your project. Here are a few suggestions:
- Trello: for a collaborative kanban
- Priority Matrix: for prioritizing your tasks
You can also use other software to communicate, such as Slack or Discord (which are proprietary, like Teams). Using Facebook Messenger or other applications linked to a social network is discouraged because they are not used to manage projects in companies. The limitation of these messaging applications is that they do not offer thematic discussion channels to segment your conversations. This leads to information being lost when several discussions get mixed together.
For people who have difficulty organizing themselves but are sensitive to gamification, you can also use Habitica (https://habitica.com/static/home) to help you work regularly.
Weekly update
Every week (until the final report is submitted and except during school holidays), you will have to complete your weekly project progress update:
- When: by Thursday evening at the latest
- Where: in your Git repository, doc/suivi folder
- How: create a file named
YYYY.MM.DD-semaineN.mdusing the template below - Who: all team members
- What: list the completed tasks + the estimated total time
- Why: it will allow your tutor to monitor the progress of your work
The weekly update is mandatory. You will be penalized if you do not complete it or if you submit it late.
- If you have not worked on the project for a week (and you are allowed to)➡️ simply write ras (nothing to report)
- If a task is not finished, you can add the suffix WIP (Work In Progress)
For your information, the software project gives you 4 ECTS, which represents an investment of approximately 100 hours (including in-person sessions) per student.
Do not wait until Thursday evening to try to remember everything you have done during the past week.
Get into the habit of listing your tasks as you go!
YYYY.MM.DD-semaineN.md
# Weekly Update - Project
Date: Thursday ...
Week no. ...
## Tasks completed this week
> Examples: `- [x] Task 1` or - `ras`
### Student First Name Last Name 1
5h
- [x] Task 1
- [x] Task 2
### Student First Name Last Name 2
0h
- ras
### Student First Name Last Name 3
### Student First Name Last Name 4
### Student First Name Last Name 5
---
## Backlog
> List of tasks waiting to be taken on.
### Priorities
### Secondary2024.09.12-semaine2.md
# Weekly Update - Ninja Project
Date: Thursday, September 12, 2024
Week no. 2
## Tasks completed this week
### Maud ZARELLA
5h
- [x] Creation of the JoueurDAO class and methods
- [x] JoueurDAO unit tests
- [x] JoueurService: added method to delete a player
### Tom ATE
2h
- [x] Formatting the class diagram with PlantUML
- [x] Report: presentation of WIP classes
### Anna NACE
0h
- ras
### Harry COVER
3h
- [x] Database modification: modification of the *joueur* table, creation of the *arbitre* table
- [x] Refactor: use of the *tabulate* package to create nice tables
### Éva ZION
3h
- [x] Coding of the *Create a tournament* feature (View + Services + Dao)
- [x] Review of the analysis report
## Backlog
### Priorities
- [ ] Fix player modification bug
- [ ] *Referee a tournament* feature
- [ ] Administrator menu
### Secondary
- [ ] Write READMEProject monitoring
Project progress monitoring will generally take place over 3 hours per week. Each team will review the following with their supervisor:
- the work completed during the week
- the difficulties encountered
- what still needs to be done
Within the team, everyone must have a high-level view of the project’s progress and what you have planned to do.
A monitoring session must be prepared!!!
This applies to other projects, internship follow-ups, meetings… If you show up empty-handed, you will waste valuable time getting back up to speed.
At each session, the supervisor will assess whether serious work has been done since the previous week. Regular work throughout the project will be rewarded, while work done only before deadlines will be penalized.
Monitoring sessions are mandatory. Attendance will be taken. Your supervisor may ask to speak with all the students they supervise at any time.
Tools and Courses
Computer Science Complementary Module
To help you successfully complete your project, a 6-hour course and five 3-hour practical sessions are provided as part of the Computer Science Complementary module. During the course, you will be introduced to the general organization of the project and some new concepts implemented during the practical sessions:
- back-end / front-end separation,
- layered programming,
- version control systems (git),
- calling a web service,
- communication with a database
Although this course is directly intended to help you successfully complete your project, its ultimate purpose is also to provide you with additional computer science knowledge so that you can easily develop your career, particularly in the world of data science.
Unless we go back to the Stone Age, you will inevitably use computer applications in your professional life. Even if you never work on the IT side, having a first understanding of how a software project works will be valuable to you.
Development tools
The development tools available to you will be:
- The Visual Studio Code development environment
- The code sharing and version control software Git, accessible from the development environment, together with a (private) repository that you will have to create on a public server (GitLab, Github, Bitbucket),
- A PostgreSQL database (hosted at Ensai) as the database management system (DBMS) for data persistence,
- A number of libraries and tools for connecting Python to the DBMS, unit testing, and automatic documentation generation
In addition to this list, you are free to use the tools of your choice, provided that you are able to use them independently.
Asking for help is normal and is part of learning. We do not keep track of which groups ask us for help. Being independent does not mean working without asking for help. If you encounter a difficulty, after several attempts cannot find a solution, and finally ask for help to solve it, you are being independent.
On the other hand, if you wait for the problem to disappear or for someone to come and help you, then you lack independence. Be proactive in your approach! You will progress much faster.
Use of Generative AI
Generative AI can be an excellent development accelerator when used wisely. If you understand your architecture, your technologies and your needs, it can help you produce code faster, explore possible approaches or solve specific problems.
It can also help you understand the principles discussed in lectures and practical sessions.
Conversely, asking it to develop poorly defined features or copying code without understanding it can cause you to waste a lot of time. AI can produce incorrect solutions, unsuitable solutions for your project, or solutions that generate bugs.
Consider AI as a technical assistant, not as an autonomous developer. The more precise your requests are and the more you understand what it proposes, the more useful it will be.
Expected work
Development process
Development will be carried out collectively and sequentially. The preliminary study, general design, implementation and validation phases follow one another over time.
Preliminary study
This first analysis phase consists of formalizing the requirements described in the specifications (the subject, the requester’s or project owner’s point of view). It should make it possible to establish:
- The scope of the target information system, clarifying aspects of the subject that may appear unclear
- The needs to be met by the target information system (use cases and menu descriptions)
- Specific requirements and constraints (development standards, architecture)
General design
This second analysis phase will result in a design model to meet the objectives set out in the specifications. The choice of diagrams is made by each team after validation by their supervisor. However, it will include at least:
- A use case diagram
- A class diagram
- A physical data model
Depending on your subject and what your supervisor asks of you, you may add:
- An activity or state diagram
- A sequence diagram
- A logical data model (entity-relationship diagram)
- the subjects and supervisors are different, so prefer doing things that are consistent with their expectations rather than simply checking boxes
- if some diagrams don’t mean anything to you, there are several books on UML modeling in the library.
Software Implementation and Validation
The database
The application will rely on a database, which you must create. To make you aware of the variety of data, your work must include the import or export of a dataset. This dataset will be provided by the supervisor in the format of their choice (XML, JSON, CSV…).
Application coding
The application will be developed in Python. The code should naturally be consistent with the diagrams from the design model already established. If necessary, these should be updated so that this consistency is maintained.
There is no graphical interface to develop, communication with the application being done through the console or a web service. All the features of your application must be testable and demonstrable via the console or HTTP requests.
Software validation
Throughout the development process, you will develop a set of unit tests.
Deliverables
Analysis report
As a client, your tutor has explained their needs to you. The analysis report explains how you are going to address them.
- Where: on Moodle, in the section provided for this purpose
- When: beginning of October
- How: in
pdfformat. It does not have to be written in LaTeX but must be “clean” - How much: 10 to 15 pages, including appendices, is a reasonable size
- Why: it will be graded by your supervisor, who will provide you with feedback
This first deliverable is the outcome of the preliminary study and general design phase. It must show that you have understood your subject and have an initial model of your application. This deliverable will therefore contain:
- A detailed schedule of the 3 phases described above (Gantt chart)
- The diagrams created during the analysis phase
- An architecture document specifying the logical organization of the technical subsystems (business packages, persistence)
- The main menus of the application and their sequences if relevant
- The main endpoints of your application if relevant
- A description of the application’s features
- A list of the components to be implemented, including:
- Their role
- A description of their mutual dependencies
- The planned development time for each of them
- The initial priority order
Final report
Your final report must present the work carried out during these 3 months. It must be submitted on Moodle and will contain the elements below.
- Follow the usual formatting guidelines for a report
- Specify your team number on the cover page
The context of your application
This section should allow someone outside your project and without any particular IT experience to understand the purpose of your work. You are therefore advised to have this section proofread by someone outside your group (friend, family). Writing this section can begin very early because it does not rely on the technical elements that you will implement.
- What needs does it address? The use case diagram is not necessary in the final report;
- Who are the users of the application?
- What are the interesting data in your application? If you use external data, present their source, format, and associated concepts. If you produce data, present the data format and how it can be used. For example:
- You retrieve real estate listings via web scraping: what site or sites are used? What data do you retrieve from the page? You can describe later how you retrieve them;
- You have to process geographical data: how is your data stored in your source? Are there any particular difficulties with this data?
- You retrieve data from an external service: what is the schema of this data?
General architecture
- Is it a Python module? A script without user interaction? A console application? An application with a client and a server communicating via HTTP requests?
- The technologies required for it to work (Python, major libraries used, persistence system, external data sources)
- An architecture diagram (to show the relationship between the different components of your application such as your code, persistence system, etc.)
Meeting the requirements
How does your application meet the needs you have described:
- How your application works:
- Focus on a central process, describing it completely so that the jury understands the logic you have implemented. What does the user do? What does your product do? How does it interact with the other components? Which classes are used? It is not necessary to specify the methods called, unless you think this is useful. To help the reader, you can add use case diagrams, as well as various other diagrams;
- Brief explanation for the others. Your report should not be a list of the Python functions in your application;
Prioritize the quality of the explanations over quantity. If you seriously describe one interesting central feature, the jury will assume that you are capable of doing the same for the others. You can illustrate your explanations using your class diagram. This allows you to:
- Explain the inheritance / associations used
- Present the business objects and how they are used by the application
- Highlight layered decomposition and decoupling between objects
A class diagram is not an end in itself; it is initially produced to serve as a compass during the implementation of your application. Likewise, in your report it should serve to guide your explanations.
Therefore, it is not necessary to produce a single class diagram if it is unreadable. You can break it down into smaller diagrams that focus on specific features. Similarly, it is strongly discouraged to list and describe exhaustively all classes and methods.
Storage system
At what points is it used in your application and why?
You can highlight the use of normal forms.
Indeed, this project should allow you to showcase the knowledge you acquired in 1A on the subject. There is no need to present all your DAOs
Tools implemented
The tools implemented to carry out the project:
- The organization you chose within your group;
- The tools and how they are used;
- The quality assurance approach. The purpose of this section is to show that you have taken into account external events that may impact your application.
- Did you perform tests? Why did you test these particular classes? What did this bring you?
- Did you encounter long processing times? Where do they come from? Did you overcome them?
- If your data source were to disappear but a new similar source existed, how would this impact your application?
- If you set aside some features during development, how could they be implemented in the future?
Individual note
When submitting the report, each student in each group will attach a note describing their experience within the project group. This note must be inserted into the final report at the end of the report. In this note of one page maximum, you will describe both the good practices implemented and the problems encountered.
You can adopt a less formal style than for the report, but keep in mind that this note is read by the jury in the same way as the rest of the report. Maintain proper formatting for this note. To help you, here are some elements that belong in this note:
- Your actual participation in the project (project manager, coding, coordination…)
- How did you experience the project with your group? Was it difficult? Enriching? Avoid clichés and prefer using concrete examples. You can highlight points of tension that occurred.
- What you learned from it, what you would do again, what you would change. You can structure this section as a list of advice you would give to your successors.
We recommend having this individual work proofread by another person (team member, friend, family) to limit mistakes and ensure that it is understandable. This personal note is appreciated by jury members, take it seriously and be honest.
Of course, this list only defines the minimum components of your deliverable. Each project group is free to provide any additional information they consider relevant to highlight their work. This could include explaining design choices that seem relevant to you, tools you used, or any other information that allows you to showcase your work. You are allowed to illustrate your explanations with figures to help the reader. Images that add nothing to your point should be avoided.
The order in which the different points are presented, and their placement in the appendices, is up to you. The optimal size for this report is 25 pages excluding appendices. You can make it longer, but in that case ask yourself: “Is what I am adding necessary?”.
the expected final format is pdf.
For writing, it is strongly recommended to use the Typst template provided in the project template.
Finally, a minimum level of rigor is expected from future engineers. It is normal to let one or two typos slip through, but if this interferes with the understanding of your report, you will be penalized.
The code
You will create an archive containing the entire contents of your git repository, and in particular the source code of your application.
You will submit this deliverable on Moodle.
Be careful not to include files that are too large (> 10MB) in your deliverable, such as data files.
The complete application source code must contain at least:
- A
README.mdfile at the root of the repository written in English for users, which must contain:- a brief presentation of your application (main features, needs it addresses)
- quick installation and launch instructions
- A
README.mdfile in the backend folder for people wishing to continue developing the application:- Presentation of the layered architecture
- Development tools (tests, logs, quality…)
- A
backend/pyproject.tomlfile with all Python modules to install to run your application - a
backend/srcfolder containing your source code and amain.pyor__main__.pyfile that allows you to launch your application - a
data/init_db.sqlfile for creating the tables and data
Between this code submission and the oral defense, you are allowed to modify your code. However, these modifications will only serve to improve the quality of the demonstration because this new code will not count towards the grade.
Only the code in the backend part will be graded!
If you develop a frontend, you can therefore code it with somewhat less rigor.
The oral defense
You will present your work before a jury of 3 people:
- a jury chair (IT professional)
- your project supervisor
- an ENSAI computer science teacher
The oral defense will consist of an oral presentation of your software, shared equally among the members of the group. It will show the development method used, as well as the design and programming choices and options adopted.
You have 20 minutes to give your presentation. Questions and feedback from the jury will follow.
- Presentation: 20 min, including approximately:
- 12 min slide presentation
- 8 min application demonstration
- Time management is up to you but the presentation should be dynamic
- You can mix demonstration and presentation; this is even recommended
- Jury questions: 15 min
- Jury feedback: 10 min
The jury is supportive and will not try to trick you!
A few tips for this oral defense:
- Briefly introduce the team members
- Even if the jury members have read your report, take the time to briefly present the initial need and the data involved, if any
Avoid catalog-style presentations such as: “We did this, this, and also this.” The jury hates this, especially when it is the 4th team in a row telling the same story. Be at least somewhat original, take an unusual angle, tell a story!
Highlight the added value of the team:
- Did you make strong choices?
- Did you implement an interesting process?
- Did you meet the need?
It is not necessary to follow the same structure as the report (this is generally a mistake), nor to reproduce the report (the jury has read it). For example, if you briefly explained a feature in the report but find it interesting, you can go into more detail during the oral defense. The jury likes novelty.
Highlight the project (how you worked over these 3 months) and not just the software produced (you are not trying to sell us your application).
Your slides:
- Number the slides!!!
- Do not overload your slides with text
- You can use diagrams, graphs, screenshots that are useful for understanding. Make sure your images are readable when projected.
- Do not include code, but pseudocode (and only if the algorithm is interesting)
The demo:
- Don’t go too fast!
- Do not present account creation / modification; this has no added value in the eyes of the jury
- For some interesting points, take the time to explain what happens in your code (like a sequence diagram)
- Don’t say “the user can do this, do that”. This isn’t Hollywood, but make an effort anyway: personalize your demo, play a role!
Work on your introduction and conclusion!
Do not end your presentation with: “That’s it, it’s finished…”.
Support each other!
Final grading
The final project grade is divided as follows:
- Analysis report and investment in the project (1/3)
- Final report and investment in the project (1/3)
- Oral defense (1/3)
The code is graded separately. It counts for one third of the Computer Science Complementary grade.
Penalties will be applied to your grade if:
- you have unjustified absences from project monitoring sessions and/or Computer Science Complementary practical sessions
- you were not present on the ENSAI premises during the immersion period
- you did not complete the weekly monitoring files
- your participation in your team’s work is considered insufficient
Schedule
See the presentation to students for the dates
Immersion
3 consecutive days are freed up in your schedule to allow you to make effective progress on your project. Attendance at the school is mandatory and will be checked.
At the end of these 3 days, with serious and effective work, you should have made good progress on the coding phase (> 80 %) and started the skeleton of the final report. This will leave you much more relaxed when tackling the final stretch in November.
You will meet your tutor on the first day so that they can help you prioritize your work, and on the last day to help you. A demonstration, even a limited one, of your application will be required on Wednesday.