# Avaliar tarefas abertas

## Avaliar unha tarefa aberta ou proceso de creación

Para un sector do profesorado convértese nun atranco importante avaliar tarefas abertas e incluso fonte de conflito na aula á hora de cualificar (agravios comparativos…), chegando ao caso de renunciar a facer este tipo de actividades. Chegados a este extremo non debería negarse que tamén se está renunciando a unha aprendizaxe máis diversificada e que fomenta a creatividade e a investigación, centrada nos procesos e na realización de tarefas, e non nos resultados e a repetición.

Como propostas principais de avaliación que facemos estarían:

- Usar rúbricas para avaliar o resultado e o proceso, pero entregándoas ao principio da tarefa cando esta sexa longa.
- Usar e avaliar o aspecto social do programa na plataforma: unha tarefa non pode darse por rematada se non está ben compartida coa comunidade.
- Permitir e incentivar as copias, reciclados e mesturas de código

## Avaliar en espiral

A espiral da creatividade é a proposta de desenvolvemento das tarefas abertas, e tamén para avaliar:

### Imaxinar:

Dada a tarefa (e entendida correctamente, que non sempre será o caso) deberá descompoñerse en subtarefas cando sexa factible, ou ben imaxinar/propoñer unha solución global e logo pensar como chegar a ela. Se é un traballo en grupo poderá haber un documento escrito das propostas.

Espiral da creatividade

### Crear:

Escribir o programa ou subprogramas, preferentemente partindo do diagrama de fluxo ou do pseudocódigo (secuencia de pasos que debe dar o programa). Nunha primeira fase pode avaliarse só se funciona ou non, pero no caso negativo é interesante analizar a estrutura e activar o detector de erros: non funciona, pero por que? é un erro gramatical ou ortográfico?. Tamén debe animarse a escribir o comentario de cada bloque de código á marxe, en especial nos traballos en grupo, pois isto facilita a avaliación e a autoavaliación.

### Xogar/experimentar:

Se a solución xa é útil ou empeza a visualizarse, debe esixirse nesta fase probar novas posibilidades para melloralo, tanto optimizando o código como traballando o deseño. Estas novas posibilidades tamén deben recollerse por escrito, no diario do programa, nas notas ao marxe, etc.

### Reflexionar:

Se o programa se da por rematado satisfactoriamente dende o punto de vista funcional (é unha solución á proposta de traballo), a reflexión debe orientarse á mellora ou uso aumentado do programa, en especial á reutilización. Diante desta reflexión o estudante ou grupo pode adiantar novas funcionalidades que mellorarían o programa. Por suposto tamén é necesario reflexionar sobre o funcionamento do grupo, no seu caso.

Se o programa non é satisfactorio a reflexión debe levarse ao proceso seguido, analizando os erros, o funcionamento do grupo, etc. Neste apartado é onde é tremendamente útil a ferramenta das rúbricas, pois permite orientar a reflexión, ademais de cuantificar os distintos apartados.

### Compartir:

Nunha plataforma educativa como Scratch as tarefas non se dan por rematadas ata que non se comparten coa comunidade. Deberemos avaliar que se cumpra un protocolo determinado (instrucións de uso, notas, agradecementos…). E se pode ser, rematar por compartir o programa nun estudo.

### Inicio

### Marco Teórico

### Aprendendo a programar

### Propostas didácticas

### Interacción coa contorna física

### Avaliación

### Coding in English

### Varios

### Licenza

### Edición

Entrar