Student Class Projects Scenario
From LiquidPubWiki
Contents |
Introduction
This scenario is related to student projects, which are executed as part of a course or as requirement for specific grants/credits.
Considering the organization, professors and students can play different roles in this scenario. The teaching staff member is responsible of coordinating students and performing administrative tasks. On the other hand, project members are the responsible of performing the work related to the project. A specialized project member, the project manager, is responsible of coordinating the student project. The work produced a project and members are evaluated by the reviewer.
Regarding to the work structure, there are activities assigned to student groups. These activities involve a list of tasks and a set of deliverables. Within the student group organization, tasks can be split in smaller tasks and be distributed among the group members. However, from the goals point of view, the work could be replicated or distributed. This means that all groups could have assigned the same activities or different set of activities (e.g. all groups coding the same whole application or different modules of an application). Moreover the distributed work could be part of something bigger and hence require inter-groups collaboration (e.g. modules integration). Furthermore, groups could (or not) be related to specific phases of the lifecycle and they could be assigned different activities per phase.
The lifecycle on these projects involves some development, review and assessment phases. A normal flow could involve iteration over the development and review phases and at some point a submission and evaluation. Nonetheless, the exact lifecycle is defined by the teaching staff. Furthermore, during the lifecycle, deliverables could be subject to many operations. For example, the professor would want to “freeze” a work when a deadline arises (e.g. source code cannot be modified anymore). Moreover, this freeze operation could be also partial as there could be parts that can keep evolving (e.g. source code is frozen but documentation can keep evolving). Also the deliverables could be merged to build a composite deliverable or conversely they can be split.
A feature strongly related to this scenario is the evaluation mechanism. The evaluation here consists in giving marks to both deliverables and students. The deliverables could also imply presentations and other non-completely tangible work that must have a weight in the evaluation. In addition, this feature could include some kind of survey (as part of the course) trying to evaluate a) the interestingness of the project, b) the approach of the course, b) themselves (teaching staff), c) the student (auto-evaluation).
Roles
In this scenario we found the following project roles:
- Project Member: This is the basic role that belongs to all students who participate in the project. The project member role allows the student to work on the assigned tasks, collaborate with the other project members, etc.
- Project Manager: This is a specialized role for a project member that belongs to the student in charge of performing project-related management tasks. As part of these responsibilities, the project manager is in charge of assigning the work to be done to the other project members.
- Reviewer: The reviewer role belongs to the user in charge of performing the review of the student projects. Part of the reviewer’s responsibilities involves a) assigning marks to student projects and students, b) defining the evaluation mechanism and c) evaluating and sending feedback as result of a review.
- Teaching Staff Member: The teaching staff member is a specialized role for a project member that belongs to the user(s) in charge of the coordination tasks. Part of their responsibilities involves defining the project, groups and group-level assignments.
There are also institutional roles played by the users in this scenario: professor and student. These roles are orthogonal to the previous ones. We describe them briefly here:
- Professor: The professor role belongs to the user in charge of the current course. As such, the professor could acquire any of the roles above.
- Student: The student is the project member in charge of performing the actual work of the project. He could assume either the project member of project manager role.
Artifacts
In this scenario we found the following complex artifacts: the project and deliverable.
The Project
The project as an artifact implies collaboration of the Teaching stuff to define the scope, general guidelines, distribution, evaluation mechanism and dates. This artifact could be subject to the following processes:
- Elaboration process
- Evaluation process
Deliverable
A deliverable is a unit of work that has associated a release date. It is composed (in turn) of multiple heterogeneous complex artifacts such as code, presentations and documents in general. Taking a software engineering course as example, possible deliverables could be: requirement analysis document, system specification, test cases, working code, tested code, modules integration, user manual and other additional materials. This artifact is subject to the following processes:
- Elaboration process
- Evaluation process
Data model
Functional requirements
http://spreadsheets.google.com/pub?key=pFiqGdICxhJKXF20GBnPkeA&gid=3
Uses cases
Test cases
See also
- Requirements main article
