TP RAS
This commit is contained in:
parent
245ddd11e3
commit
f83249e0b5
3 changed files with 17 additions and 18 deletions
|
@ -16,24 +16,19 @@ Application of a systematic, disciplined and quantifiable approach to the analys
|
|||
- Exam - January 23
|
||||
- Project
|
||||
- Min grade: 10.00
|
||||
- phase 1: teams of five students;
|
||||
- deadline October 20
|
||||
- phase 2: teams unite to create bigger teams project
|
||||
- deadline November 24
|
||||
- phase 3: teams unite to create bigger teams project
|
||||
- deadlines: December 22
|
||||
- project presentation: Jan 08–12
|
||||
- **phase 1**: teams of five students;
|
||||
- deadline: October 20
|
||||
- **phase 2**: teams unite to create bigger teams project
|
||||
- deadline: November 24
|
||||
- **phase 3**: teams unite to create bigger teams project
|
||||
- deadline: December 22
|
||||
- **project presentation**: Jan 08–12
|
||||
- project mark in each phase is affected by individual performance:
|
||||
|
||||
- individual variation (-2..+2) (provided by each team)
|
||||
- sum of variations is 0 within the team
|
||||
- project mark = (mark1 + mark3) /2
|
||||
- project mark in 2022/23 can be reused this year (send email)
|
||||
- Final Mark = min(0.6×max(test, project)+0.4×min(test, project), test+2.5)
|
||||
|
||||
- individual variation [-2..+2] (provided by each team)
|
||||
|
||||
- sum of variations is 0 within the team
|
||||
|
||||
|
||||
- project mark = (mark1 + mark3) /2
|
||||
|
||||
- project mark in 2022/23 can be reused this year (send email)
|
||||
|
||||
|
||||
- Final Mark = min(0.6×max(test, project)+0.4×min(test, project), test+2.5)
|
||||
[[T - Aula 2 - 19 Setembro 2023|Próxima aula]]
|
|
@ -158,3 +158,6 @@ adopted for the user requirements.
|
|||
4. The requirements can be designated as either user or system requirements.
|
||||
5. User requirements are related to the problem domain and are usually expressed in a natural language.
|
||||
6. A system requirement is oriented towards the solution domain and is a detailed specification of a requirement, generally in the form of a formal model of the system.
|
||||
|
||||
[[Próxima aula]]
|
||||
[[TP - Aula 1 - 20 Setembro|Aula prática]]
|
|
@ -17,3 +17,4 @@
|
|||
> >3. requisito funcional: defina uma feature do sistema ;requisito não funcional : é um requisito de segurança
|
||||
> >4. não requisito: não define uma feature (é uma "não-feature") e não se qualifica a requisito não-funcional
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue