The company grade is determined from two components: The weighted company grade and the grade level. Mathematically, the company grade is the minimum of these two grades.
Weighted company project grade
Each supervisor/customer representative will report one process grade and one result grade, except the CEO, who only gives a process grade. Please, note the difference in weights between processes and results.
Process gradesThe students are judged for how they are identifying, planning, and solving problems during the project. It does not concern the quality of what is produced. More specifically, we are judging:
- Problem handling. Problems and potential problems should be identified as early as possible (risk handling). They should be communicated clearly both to the employees, the CEO, and the consulting supervisors. Different possible solutions should be analyzed, and a possible solution should be suggested and finally implemented.
- Ideas, initiative, and get things done on time. The students should try to have their own ideas on how to solve things. Complement the theory part by searching information on the web and in books. Take initiative to educate people, try alternative solutions. It is important to be creative, but in the end, it is all about getting things done on time.
- Leadership and vision. Place the product in perspective. Customer wants market analysis. Create a long-term plan and relate it to concrete action.
- Respect, cooperation, and positive atmosphere. Students should have respect for each other, both regarding cultural differences and different views on how to work. This is a company, so the employees should work together and learn from each other. Everybody should also aim for having a positive view, even if there will be conflicts and stressful times. The objective is to see solutions to problems, not just problems. Remember that you as an individual is also responsible for the well-being of your company regardless of your role.
- Structured but pragmatic. The work should be planned and executed in a structured way. Plans should be written, but also more important, re-written. However, things should not be done for each own sake. We have a pragmatic viewpoint, i.e., things should be done good enough to solve the objectives of the task. No more, no less. Since there are limited resources and time, tasks must be prioritized in a structured manner.
Result gradesThe result grade concerns the result in the specific area, i.e., what has been produced and how good the quality of that is. More specifically, we are judging:
- Quality of artifacts. For example, how consistent and relevant e.g., the design specification and the requirements specification are. How well-documented, well-designed (modularity, extendability, etc.), and well-implemented the source code and tests are. This includes the quality of the system from a user point of view.
- Quality of presentations. How good presentations are (e.g. tollgate meeting and VSSE), both regarding presentation technique, content, and message.
The following table lists the different grading areas, the reporting
teacher(s), and the weight factor.
|Number||Grading Area||Teacher(s)||Weight factor|
|1||Process grade for architecture, design, implementation, configuration management, requirements, testing, and quality management.||Supervisors||2|
|2||Result grade for architecture, design, implementation, configuration management, requirements, testing, and quality management.||Supervisors||1|
|3||Process grade for planning, organization, process management, and communication of the project and within the company||CEO||4|
|4||Process grade from the customer's viewpoint||Customer||1|
|5||Result grade from the customer's viewpoint||Customer||2|
For each company, each grade in each grading area is multiplied with the grading area's weight factor. The sum is divided by 10, giving the mean value after rounding off. Please note, that it is the examiner who determines the final grades, based on the report from the other personnel and partners.
Grade levelsThe above criteria are the basis for judging the grades. However, to be able to reach different grades, the company must at least have implemented, created, and used the following with an acceptable quality. Deviations from the criteria must be well supported and approved by the supervisors.
Grade 3To be able to get grade 3, at least the following must be done by the company:
- Deliver products and other deliverables on time.
- Deliver weekly status reports on time.
- Create the following documents: (Documents submitted for judgment are placed under files in the TEAMS General/Files/Output)
- architecture notebook
- customer requirements specification
- API specification agreed by all companies
- test plan
- project plan
- education plan
- software quality assurance plan
- Documents shall be well-structured, navigable, easy to access, have a clear authorship, and be version controlled.
- Documents are living artifacts that shall be used and updated as often as needed to be useful to you. They are not hand-ins separated from the project. A hint is to create them early and evolve them.
- To the extent that you have plans, they should be evident in these documents (or we are going to assume that you haven't made any plans.)
- Use MS Teams predefined teams and channels as an internal communication platform. Access shall be granted to teachers of the course.
- Have an updated company website that includes at least photos and current roles of the employees. Access shall be granted to teachers of the course.
Individual requirements on level 3:
- Each student must be present at almost all company meetings.
- Each student shall work and report about 160h.
- Write and hand in reflection reports on time.
(Each student is responsible for meeting these requirements, but the company has responsibility to create an environment where these requirements can be met. For instance, by re-allocating people to different tasks, scheduling, or sending reminders.)
Grade 4To be able to get grade 4, the items for grade 3 should be fulfilled + the following:
- For documents at grade level 3, follow and update the documents when necessary.
- Use a bug-tracking system.
- Have traceability between requirements (or backlog), system design and test documents, with a short description of how each type of traceability is achieved and pointers to relevant documentation.
- Use a version handling system for all artifacts including documents. GitLab must be used for code. Recommendation: Use GitLab for version handling also for documents. Use LaTeX or Markdown to write documents.
- Have an explicated plan for quality assurance, including the use tools for testing and reporting test results. The software quality assurance plan has links to the testing documentation and describes the role of testing in quality assurance.
- Processes are documented and followed throughout the project.
- Have internal inspection for all produced documents.
- Have an internal walk-through before the tollgate meeting.
- Work in cross-functional teams, i.e., teams consisting of employees from both departments.
- Use continuous integration, as introduced in the lectures, from the start of development.
- Have processes for handling and documenting changes
Grade 5To be able to get grade 5, the items for grade 3 and 4 should be fulfilled + the following:
- Show a working product at the end all iterations
- Use continuous delivery, as introduced in the lectures, from the start of development.
- Deliver documentation about future development of the product and ideas including scalability, support, and maintenance
- Process described in the documents of grade level 3 are regularly evaluated and improvements of the processes are continually implemented and documented.
- Use a well-integrated tool chain to support the development and management processes as demonstrated in the lectures.
- Constructive contributions to an API common to all groups for back-end - front-end communication.
For any questions about these items, please contact the CEO or the consulting supervisors. Also note that the above lists of requirements should not be interpreted as a checklist guaranteeing a certain grade. Grading decisions weigh in multiple factors, including how well the above actions were carried out. As a case in point, satisfying a certain grading requirement at the very end of the project (e.g. establishing version control in the last week of development) may detract from the final grade.
We will ask you to submit artifacts in the end of the first study period. In the beginning of the second stud period we will let the companies know their strengths and weaknesses from a mid-term assessment, but we will not give you a preliminary grade. If, however, we have reasons to believe that you face a risk of not passing the course we will let you know immediately.
Individual project grade
The company grade will form the base for the individual student's project grade. However, an individual student can get both a higher or a lower grade than the company grade, depending on his/her individual performance.
Individual Project GradeIf a student performs significantly better than the rest of the company, he/she can get a better grade than the company as such. Likewise, if the student performs less than the rest of the company, he/she can get a lower grade. The assessment is based on artifacts in which the student has been involved, inputs from company meetings, individual discussions, individual time reports, and the individual reflection reports. If not enough information is present, individual students can be called for an interview after project ending. Note that efforts that may lead to improved grades for particular students in a group do not primarily involve acts of individual heroism (e.g. all-night code crunching to single-handedly save a customer demo) but efforts to improve the project's collective performance (e.g. identifying deficiencies in the ways of working and seeking to improve them).
Peer assessment, that is students report on each other's performance, will be collected two times during the course. This information is not directly affecting the grade but can be used as an indicator to call for an interview or other investigations. The major purpose of peer assessment is to be used by the students themselves for reflection.
If the examiner discovers that a student does not contribute enough to the team work, does not hand in reflection reports, does not work and report the budgeted hours (160h), or does not participate in all compulsory company meetings, individual students in the team can fail the project part. This will not affect the grades of the other students in the group.
If part of your project is failing, that is everybody’s problem, even if it’s not within the scope of your role. Nobody can do everything, but we look for and seek to recognize those who identify, highlight and respectfully and constructively seek to address them.
The project part of the course is worth 6 hp, which corresponds to 160 working hours. All students shall try to reach this target, which also gives the company a challenge to balance the workload amongst the participants. Small deviations from the target will be tolerated. Discrepancies are followed up individually. Please note, that working too many hours is not accepted in this course. Processes and planning are important.
Compulsory meetingsCertain meetings, such as the introduction lecture, the company's weekly meeting, the tollgate meeting, and the expo at the end of the course are all compulsory. If the student cannot for some reason participate in such a meeting, an email must be sent to all teachers (including the examiner) before the meeting takes place. Absence for reasons other than sickness might influence the individual grade.
Everyone can make a single mistake, but the students are only allowed one occasion of absence without proper justification (holidays, work, and travels are not considered as justified). Schedule conflicts shall be notified as early as possible.
The company is responsible to send appropriate representatives to the weekly supervisor meeting and customer meetings.
Page responsible: Kristian Sandahl
Last updated: 2022-09-13