Eu ouço e me esqueço.
Eu vejo e relembro.
Eu faço e compreendo.


            Confúncio
AT07 – Professor, Pesquisador, Animador e Mágico




    Tema da sessão:


         Relato de Experiência na Aplicação
              da Taxonomia SOLO no
             Planejamento de Disciplina


                Prof. Camilo Almendra
                 camilo.almendra@ufc.br
25/Abril/2012
Objetivos
●   Ao final dessa apresentação, os participantes
    serão capazes de:
    ●   Avaliar seus objetivos de disciplinas segundo a
        taxonomia SOLO
    ●   Descrever o processo básico de implementação da
        taxonomia em uma disciplina
Agenda
●   Parte 1
    ●   Motivação
    ●   Taxonomia SOLO
●   Parte 2
    ●   Processo de Implementação
    ●   Relato de Experiência
Mas o quê está errado?
Curta metragem: http://www.daimi.au.dk/~brabrand/short-film/
Qualquer semelhança com nomes,
pessoas ou acontecimentos reais
  terá sido mera coincidência...
             ou não?
Exercício: Quais as mensagens principais do filme?
Minha realidade perspectiva
●   Alunos sem hábito de leitura
●   Falta curiosidade
●   Falta persistência
●   Aulas ”não rendem”
●   Alunos não respondem o que espero nas
    provas
●   ”Dispersos...”
Perspectiva deles
●   ”Tem uma lista de exercícios para a prova?”
●   ”A prova é igual a lista?”
●   ”Tem esse livro em pdf?”
●   ”Coloca umas questões de concurso!”
●   ”Professor, não dá para aceitar nada nessa
    questão?”
●   ”Aula chata... opa, alguém curtiu no Facebook!”
O que está acontecendo?
Opinião: http://www.youtube.com/watch?v=kkWxtMFWqZw




Século 20
                                   Século 21
Fato
●   Éramos, na maioria, Susans. Agora somos, na
    maioria, Roberts
●   Mudaram as pessoas, ou outras pessoas
    tiveram acesso ao ensino superior?
    ●   Essa apresentação não busca identificar a causa
●   O fato é que dentro da Universidade, temos um
    novo aluno
    ●   O que vamos fazer?
Exercício:



 O que é bom ensino?


 What is good teaching?
Mudança de Foco




O quê o professor faz
   não é mais tão
                        O quê o aluno
     relevante.         está fazendo?
  O aluno não está
 prestando atenção
      mesmo...
Mudança de Foco
          CONTEÚDO                 COMPETÊNCIA
●   Foco no Conteúdo
●   Exemplo:
     Objetivos:
      –   Requisitos funcionais e não-funcionais
      –   Casos de usos
      –   Estórias de usuário
      –   Gestão de mudanças
      –   Modelagem de processos

                                         Problemas?
Problema #1
            ”Conteúdo” como ”Objetivo”
                                                       Definir requisito funcional,
Analisar requisitos do
                                                        Descrever partes de um
 sistema, Categorizar,
                                                       Caso de uso, Descrever as
Identificar conflitos, ...
                                                         etapas da gestão de ...




                             Compreender:
                             ●   Requisitos funcionais e não-
                                 funcionais
                             ●   Casos de usos
                             ●   Estórias de usuário
                             ●   Gestão de mudanças
                             ●   Modelagem de processos
Problema #2
       ”Compreender” como ”Objetivo”


Muito difícil de avaliar!


                Compreender:
                 ●




                 ●
                     Requisitos funcionais e não-
                     funcionais
                     Casos de usos
                                                    ?
                 ●   Estórias de usuário
                 ●   Gestão de mudanças
                 ●   Modelagem de processos
Mudança de Foco
                CONTEÚDO                       COMPETÊNCIA
●   Foco na Competência
    ●   competencia = conhecimento + capacidade_de_agir;
●   Alunos fazem algo e então o produto ou processo é
    observado (avaliado)
●   Exemplo:
        Objetivos:
         –   Classificar requisitos de sistema em funcionais e não-funcionais
         –   Avaliar atributos de qualidade de requisitos
         –   Construir casos de usos                              Compreender é
         –   Construir estórias de usuário                           pré-requisito!
         –   Aplicar controle de mudanças
         –   Comparar métodos de modelagem de processos
Taxonomia SOLO
●   SOLO - Structured Observed Learning Outcomes
    ●   Ações de aluno indicadas através de verbos
    ●   Resultados esperados = elaborados pelo professor
●   ILO – Intended Learning Outcomes
    ●   Objetivos de aprendizado formulados: Verbo + Substantivo
●   Níveis e ações comuns
    ●   SOLO 2 (mono-estrutural)
        –   definir, citar, identificar, nomear, ...
    ●   SOLO 3 (multi-estrutural)
        –   combinar, descrever, classificar, aplicar método, ...
    ●   SOLO 4 (relacional)
        –   analisar, comparar, integrar, explicar causas, ...
    ●   SOLO 5 (abstração extendida)
        –   teorizar, generalizar, prever, julgar, refletir, ...
Teaching Teaching &
       Understanding Understanding
  ●   Mais informações
      sobre a Taxonomia SOLO




                                            Livro ”Teaching for Quality Learning
                                                     at University ” http://amzn.to/HYWU60

Link: http://www.itu.dk/~brabrand/Teaching-Learning-UFPE-2010.ppt
Processo de Implementação
                                                     Formas de
                                                      Avaliação


                    Operacionalize           Incentivo ao aprendizado
 Objetivos
                          e
  Gerais
                      Formule
 do Curso
                        ILOs
                                              Suporte ao aprendizado
O que os alunos     O que os alunos
aprendem a FAZER?   aprendem a FAZER
                    em relação a cada item
                                                     Formas de
                    da ementa?                         Ensino
Relato: Disciplina ”Requisitos de
               Software”
●   Competências chave
                                                Objetivos
                                                 Gerais
                                                do Curso




     Elicitar e especificar requisitos de sistemas novos
        ou legados em vários domínios de aplicação


    Planejar e executar o ciclo de vida dos requisitos em
                   um projeto de software
Relato: Disciplina ”Requisitos de
               Software”
●   ”Filosofia” Geral
     ●   Conceitos e teorias são PILARES para o trabalho na
         área de Requisitos
     ●   Para a construção de PRODUTOS e artefatos, é
         necessário compreensão dos PILARES
     ●   Com a compreensão do trabalho necessário para a
         fabricação de PRODUTOS, é possível desenhar ou
         adotar PROCESSOS
     ●   PROCESSOS guiam a construção de PRODUTOS
         que aderem a critérios de qualidade definidos nos
         PILARES
Relato: Disciplina ”Requisitos de
           Software”


    Elicitar e especificar requisitos de sistemas
     novos ou legados em vários domínios de
                       aplicação


  Planejar e executar o ciclo de vida dos requisitos
              em um projeto de software




  PILARES           PRODUTOS          PROCESSOS
Relato: Disciplina ”Requisitos de
               Software”      Operacionalize
                                  e Formule ILOs
●   Ementa original! :(
Relato: Disciplina ”Requisitos de
               Software”      Operacionalize
●   Organização da ementa                                                              e Formule ILOs
●   Assunto de ”Especificação Formal de Software”
    ●   Princípios de modelagem como decomposição e abstração. Pré e pós condições. Invariantes. Visão
        geral de modelos matemáticos e linguagens de especificação como Z, VDM, NFR e GORE.
        Interpretação de modelos (sintaxe e semântica).
●   Assunto de ”Fundamentos de Banco de Dados”
    ●   Modelagem de informações (modelo entidade-relacionamento e diagrama de classes).
●   Assunto de ”Modelagem e Analise de Sistemas”
    ●   Modelagem de comportamento (diagramas de estados, diagramas de casos de uso, diagramas de
        interação). Modelagem de estrutura (arquitetura). Modelagem de domínio. Modelagem funcional.
●   Agora sim, ”Requisitos”
    ●   Fundamentos como completitude, consistência, robustez, análise estática, simulação, verificação de
        modelos, segurança, safety, usabilidade, desempenho, análise de causa/efeito, priorização, análise de
        impacto, rastreabilidade. Definição de requisitos de produto, projeto, restrições, fronteiras de um
        sistema. Processo de requisitos. Níveis de requisitos (necessidades, objetivos, requisitos dos usuários,
        requisitos de sistema, requisitos de software. Características de requisitos (testáveis, verificáveis e
        outras). Interação entre requisitos e arquitetura. Fontes e técnicas de elicitação. Documentação de
        requisitos (normas, tipos, audiência, estrutura, qualidade). Especificação de requisitos. Revisões e
        inspeções. Construção de protótipos para validar requisitos. Relação com testes de aceitação.
        Gerência de requisitos. Modelagem de processos de negócios. Padrões de análise.
Relato: Disciplina ”Requisitos de
               Software”      Operacionalize
●   Grupo ”Pilares”                                                      e Formule ILOs
     ●   Definição de requisitos de produto, projeto, restrições,
         fronteiras de um sistema. Níveis de requisitos (necessidades, objetivos, requisitos dos
         usuários, requisitos de sistema). Fontes e técnicas de elicitação. Atributos de
         qualidade (Completitude, consistência, robustez, FURPS, SMART). Características de
         requisitos (testáveis, verificáveis e outras). Tipos ( segurança, safety, usabilidade,
         desempenho).
●   Grupo ”Produtos”
     ●   Especificação de requisitos. Documentação de requisitos (normas, tipos, audiência,
         estrutura, qualidade).
●   Grupo ”Processo”
     ●   Processo de requisitos. Gerência de requisitos. Modelagem de processos de
         negócios. Construção de protótipos para validar requisitos. Relação com testes de
         aceitação.
●   Grupo ”???”
     ●   Processos fundamentais (análise estática, simulação, verificação de modelos, análise
         de causa/efeito, priorização, análise de impacto, rastreabilidade). Padrões de análise.
         Interação entre requisitos e arquitetura. Revisões e inspeções.
Relato: Disciplina ”Requisitos de
            Software”      Operacionalize
Intented Learning Outcomes                        e Formule ILOs

Avaliar atributos de qualidade de requisitos;   SOLO 4 (ou 5)

Elaborar e Categorizar requisitos em diferentes SOLO 3
 níveis de abstração;

Aplicar técnicas de elicitação apropriadas ao   SOLO 4
 contexto;

Especificar requisitos em forma de casos de     SOLO 3
 uso e estórias de usuário;

Modelar processos de negócio;                   SOLO 3

Gerenciar mudanças em requisitos.               SOLO 4 (ou 5)
Processo de Implementação
                                                     Formas de
                                                      Avaliação


                    Operacionalize           Incentivo ao aprendizado
 Objetivos
                          e
  Gerais
                      Formule
 do Curso
                        ILOs
                                              Suporte ao aprendizado
O que os alunos     O que os alunos
aprendem a FAZER?   aprendem a FAZER
                    em relação a cada item
                                                     Formas de
                    da ementa?                         Ensino
Ex: ILO ”Elaborar e Categorizar requisitos
           em diferentes níveis”
●   Pilares
    ●   Stakeholders e suas diferentes necessidades
    ●   Requisitos e seus níveis de abstração (negócio,
        stakeholder, solução)
●   Produtos
    ●   Lista de requisitos funcionais e não-funcionais
    ●   Categorizados por tipo de stakeholder
●   Processos
    ●   Identificação de stakeholders
    ●   Levantamento de requisitos
Ex: ILO ”Elaborar e Categorizar requisitos
           em diferentes níveis”
●   Suporte ao Aprendizado
    ●   Uso de domínio conhecido (Aplicações móveis, Sistemas
        acadêmicos)
        –   Exemplos fabricados
    ●   Práticas de levantamento de requisitos
        –   Geração de material autêntico
    ●   Prática de categorização dos requisitos
        –   Em cima de exemplos didáticos e do material autêntico gerado
        –   Leitura do material didático era indispensável para a prática
●   Incentivo ao Aprendizado
    ●   Mesma prática solicitado em exame
    ●   Domínios diferentes, mas conhecidos (Venda de Passagens
        Aéres e Automação Bancária)
Ex: ILO ”Elaborar e Categorizar requisitos
           em diferentes níveis”
●   Observações após 1º exame
    ●   Alunos reclamaram de ”falta de questões sobre conceitos”
    ●   Dificuldades para redigir os requisitos de acordo com cada
        perspectiva (negócio, stakeholder, usuário)
         –   Mais prática de redação ou falta de entendimento do domínio?
    ●   Sem dificuldade para explicar os conceitos
    ●   Sem dificuldade de classificar requisitos já escritos
●   Oportunidades de aprendizado (não planejadas)
    ●   Demonstrar a dificuldade de se trabalhar com novo domínio
    ●   Demonstrar a dificuldade de redação técnica
Inspiração para Ativação
●   Sua experiência prática!
●   Iniciativas de Educação a Distância
    ●   saas-class.org, db-class.com, coursera.org
    ●   Muitos exemplos de ativação (exercícios, testes)
●   Relatos de aplicação de PBL (Problem-based Learning)
    ●   http://bit.ly/HVctJL
●   Design & Teach a Course (Carnegie Mellon)
    ●   http://www.cmu.edu/teaching/designteach/design/index.html
●   Casos curiosos
    ●   Meu mentiroso favorito - http://www.zenmoments.org/my-favorite-liar/
    ●   Teste Primeiro - http://testfirst.org/
Pontos em Aberto
●   Difícil planejar atividades de nível intermediário
    ●   SOLO 2 é natural, material didático em abundância
    ●   SOLO 5 é o PBL, Projetos Finais
    ●   Mas, e o meio do campo?
●   Tempo necessário para avaliação de atividades e exames
●   Qual é a Filosofia Geral de Engenharia de Software?
●   Como aplicar uma mudança com alunos e docentes ”viciados”?
●   Como estender essa mudança para o nível de graduação ou unidade
    acadêmica?
●   Materiais ”didáticos” muito informativos, mas pouco interativos
●   Avaliação de curso
    ●   ILOs podem não ser facilmente relacionados com ementa
    ●   ENADE focado em conteúdo e não em competências
●   Você tem pontos em aberto a sugerir?
Objetivos

          ●   Ao final dessa apresentação, os
              participantes serão capazes de:
SOLO 5        ●   Avaliar seus objetivos de disciplinas
                  segundo a taxonomia SOLO
              ●   Descrever o processo básico de
SOLO 2            implementação da taxonomia em uma
                  disciplina




          Objetivos Atingidos?
         Resultados Observados?
Obrigado!
●   AT07 – Professor, Pesquisador, Animador e Mágico
    ●   Coordenação: Prof. Arthur Callado (arthur@ufc.br)
●   Contato
    ●   http://groups.google.com/group/ppam-l
    ●   http://www.casa.ufc.br
●   Link para essa apresentação
    ●   http://www.slideshare.net/ccalmendra


                      Prof. Camilo Almendra
                     (camilo.almendra@ufc.br)

Relato Experiência Taxonomia SOLO

  • 1.
    Eu ouço eme esqueço. Eu vejo e relembro. Eu faço e compreendo. Confúncio
  • 2.
    AT07 – Professor,Pesquisador, Animador e Mágico Tema da sessão: Relato de Experiência na Aplicação da Taxonomia SOLO no Planejamento de Disciplina Prof. Camilo Almendra camilo.almendra@ufc.br 25/Abril/2012
  • 3.
    Objetivos ● Ao final dessa apresentação, os participantes serão capazes de: ● Avaliar seus objetivos de disciplinas segundo a taxonomia SOLO ● Descrever o processo básico de implementação da taxonomia em uma disciplina
  • 4.
    Agenda ● Parte 1 ● Motivação ● Taxonomia SOLO ● Parte 2 ● Processo de Implementação ● Relato de Experiência
  • 5.
    Mas o quêestá errado? Curta metragem: http://www.daimi.au.dk/~brabrand/short-film/
  • 6.
    Qualquer semelhança comnomes, pessoas ou acontecimentos reais terá sido mera coincidência... ou não? Exercício: Quais as mensagens principais do filme?
  • 7.
    Minha realidade perspectiva ● Alunos sem hábito de leitura ● Falta curiosidade ● Falta persistência ● Aulas ”não rendem” ● Alunos não respondem o que espero nas provas ● ”Dispersos...”
  • 8.
    Perspectiva deles ● ”Tem uma lista de exercícios para a prova?” ● ”A prova é igual a lista?” ● ”Tem esse livro em pdf?” ● ”Coloca umas questões de concurso!” ● ”Professor, não dá para aceitar nada nessa questão?” ● ”Aula chata... opa, alguém curtiu no Facebook!”
  • 9.
    O que estáacontecendo? Opinião: http://www.youtube.com/watch?v=kkWxtMFWqZw Século 20 Século 21
  • 10.
    Fato ● Éramos, na maioria, Susans. Agora somos, na maioria, Roberts ● Mudaram as pessoas, ou outras pessoas tiveram acesso ao ensino superior? ● Essa apresentação não busca identificar a causa ● O fato é que dentro da Universidade, temos um novo aluno ● O que vamos fazer?
  • 11.
    Exercício: O queé bom ensino? What is good teaching?
  • 12.
    Mudança de Foco Oquê o professor faz não é mais tão O quê o aluno relevante. está fazendo? O aluno não está prestando atenção mesmo...
  • 13.
    Mudança de Foco CONTEÚDO COMPETÊNCIA ● Foco no Conteúdo ● Exemplo: Objetivos: – Requisitos funcionais e não-funcionais – Casos de usos – Estórias de usuário – Gestão de mudanças – Modelagem de processos Problemas?
  • 14.
    Problema #1 ”Conteúdo” como ”Objetivo” Definir requisito funcional, Analisar requisitos do Descrever partes de um sistema, Categorizar, Caso de uso, Descrever as Identificar conflitos, ... etapas da gestão de ... Compreender: ● Requisitos funcionais e não- funcionais ● Casos de usos ● Estórias de usuário ● Gestão de mudanças ● Modelagem de processos
  • 15.
    Problema #2 ”Compreender” como ”Objetivo” Muito difícil de avaliar! Compreender: ● ● Requisitos funcionais e não- funcionais Casos de usos ? ● Estórias de usuário ● Gestão de mudanças ● Modelagem de processos
  • 16.
    Mudança de Foco CONTEÚDO COMPETÊNCIA ● Foco na Competência ● competencia = conhecimento + capacidade_de_agir; ● Alunos fazem algo e então o produto ou processo é observado (avaliado) ● Exemplo: Objetivos: – Classificar requisitos de sistema em funcionais e não-funcionais – Avaliar atributos de qualidade de requisitos – Construir casos de usos Compreender é – Construir estórias de usuário pré-requisito! – Aplicar controle de mudanças – Comparar métodos de modelagem de processos
  • 17.
    Taxonomia SOLO ● SOLO - Structured Observed Learning Outcomes ● Ações de aluno indicadas através de verbos ● Resultados esperados = elaborados pelo professor ● ILO – Intended Learning Outcomes ● Objetivos de aprendizado formulados: Verbo + Substantivo ● Níveis e ações comuns ● SOLO 2 (mono-estrutural) – definir, citar, identificar, nomear, ... ● SOLO 3 (multi-estrutural) – combinar, descrever, classificar, aplicar método, ... ● SOLO 4 (relacional) – analisar, comparar, integrar, explicar causas, ... ● SOLO 5 (abstração extendida) – teorizar, generalizar, prever, julgar, refletir, ...
  • 18.
    Teaching Teaching & Understanding Understanding ● Mais informações sobre a Taxonomia SOLO Livro ”Teaching for Quality Learning at University ” http://amzn.to/HYWU60 Link: http://www.itu.dk/~brabrand/Teaching-Learning-UFPE-2010.ppt
  • 19.
    Processo de Implementação Formas de Avaliação Operacionalize Incentivo ao aprendizado Objetivos e Gerais Formule do Curso ILOs Suporte ao aprendizado O que os alunos O que os alunos aprendem a FAZER? aprendem a FAZER em relação a cada item Formas de da ementa? Ensino
  • 20.
    Relato: Disciplina ”Requisitosde Software” ● Competências chave Objetivos Gerais do Curso Elicitar e especificar requisitos de sistemas novos ou legados em vários domínios de aplicação Planejar e executar o ciclo de vida dos requisitos em um projeto de software
  • 21.
    Relato: Disciplina ”Requisitosde Software” ● ”Filosofia” Geral ● Conceitos e teorias são PILARES para o trabalho na área de Requisitos ● Para a construção de PRODUTOS e artefatos, é necessário compreensão dos PILARES ● Com a compreensão do trabalho necessário para a fabricação de PRODUTOS, é possível desenhar ou adotar PROCESSOS ● PROCESSOS guiam a construção de PRODUTOS que aderem a critérios de qualidade definidos nos PILARES
  • 22.
    Relato: Disciplina ”Requisitosde Software” Elicitar e especificar requisitos de sistemas novos ou legados em vários domínios de aplicação Planejar e executar o ciclo de vida dos requisitos em um projeto de software PILARES PRODUTOS PROCESSOS
  • 23.
    Relato: Disciplina ”Requisitosde Software” Operacionalize e Formule ILOs ● Ementa original! :(
  • 24.
    Relato: Disciplina ”Requisitosde Software” Operacionalize ● Organização da ementa e Formule ILOs ● Assunto de ”Especificação Formal de Software” ● Princípios de modelagem como decomposição e abstração. Pré e pós condições. Invariantes. Visão geral de modelos matemáticos e linguagens de especificação como Z, VDM, NFR e GORE. Interpretação de modelos (sintaxe e semântica). ● Assunto de ”Fundamentos de Banco de Dados” ● Modelagem de informações (modelo entidade-relacionamento e diagrama de classes). ● Assunto de ”Modelagem e Analise de Sistemas” ● Modelagem de comportamento (diagramas de estados, diagramas de casos de uso, diagramas de interação). Modelagem de estrutura (arquitetura). Modelagem de domínio. Modelagem funcional. ● Agora sim, ”Requisitos” ● Fundamentos como completitude, consistência, robustez, análise estática, simulação, verificação de modelos, segurança, safety, usabilidade, desempenho, análise de causa/efeito, priorização, análise de impacto, rastreabilidade. Definição de requisitos de produto, projeto, restrições, fronteiras de um sistema. Processo de requisitos. Níveis de requisitos (necessidades, objetivos, requisitos dos usuários, requisitos de sistema, requisitos de software. Características de requisitos (testáveis, verificáveis e outras). Interação entre requisitos e arquitetura. Fontes e técnicas de elicitação. Documentação de requisitos (normas, tipos, audiência, estrutura, qualidade). Especificação de requisitos. Revisões e inspeções. Construção de protótipos para validar requisitos. Relação com testes de aceitação. Gerência de requisitos. Modelagem de processos de negócios. Padrões de análise.
  • 25.
    Relato: Disciplina ”Requisitosde Software” Operacionalize ● Grupo ”Pilares” e Formule ILOs ● Definição de requisitos de produto, projeto, restrições, fronteiras de um sistema. Níveis de requisitos (necessidades, objetivos, requisitos dos usuários, requisitos de sistema). Fontes e técnicas de elicitação. Atributos de qualidade (Completitude, consistência, robustez, FURPS, SMART). Características de requisitos (testáveis, verificáveis e outras). Tipos ( segurança, safety, usabilidade, desempenho). ● Grupo ”Produtos” ● Especificação de requisitos. Documentação de requisitos (normas, tipos, audiência, estrutura, qualidade). ● Grupo ”Processo” ● Processo de requisitos. Gerência de requisitos. Modelagem de processos de negócios. Construção de protótipos para validar requisitos. Relação com testes de aceitação. ● Grupo ”???” ● Processos fundamentais (análise estática, simulação, verificação de modelos, análise de causa/efeito, priorização, análise de impacto, rastreabilidade). Padrões de análise. Interação entre requisitos e arquitetura. Revisões e inspeções.
  • 26.
    Relato: Disciplina ”Requisitosde Software” Operacionalize Intented Learning Outcomes e Formule ILOs Avaliar atributos de qualidade de requisitos; SOLO 4 (ou 5) Elaborar e Categorizar requisitos em diferentes SOLO 3 níveis de abstração; Aplicar técnicas de elicitação apropriadas ao SOLO 4 contexto; Especificar requisitos em forma de casos de SOLO 3 uso e estórias de usuário; Modelar processos de negócio; SOLO 3 Gerenciar mudanças em requisitos. SOLO 4 (ou 5)
  • 27.
    Processo de Implementação Formas de Avaliação Operacionalize Incentivo ao aprendizado Objetivos e Gerais Formule do Curso ILOs Suporte ao aprendizado O que os alunos O que os alunos aprendem a FAZER? aprendem a FAZER em relação a cada item Formas de da ementa? Ensino
  • 28.
    Ex: ILO ”Elaborare Categorizar requisitos em diferentes níveis” ● Pilares ● Stakeholders e suas diferentes necessidades ● Requisitos e seus níveis de abstração (negócio, stakeholder, solução) ● Produtos ● Lista de requisitos funcionais e não-funcionais ● Categorizados por tipo de stakeholder ● Processos ● Identificação de stakeholders ● Levantamento de requisitos
  • 29.
    Ex: ILO ”Elaborare Categorizar requisitos em diferentes níveis” ● Suporte ao Aprendizado ● Uso de domínio conhecido (Aplicações móveis, Sistemas acadêmicos) – Exemplos fabricados ● Práticas de levantamento de requisitos – Geração de material autêntico ● Prática de categorização dos requisitos – Em cima de exemplos didáticos e do material autêntico gerado – Leitura do material didático era indispensável para a prática ● Incentivo ao Aprendizado ● Mesma prática solicitado em exame ● Domínios diferentes, mas conhecidos (Venda de Passagens Aéres e Automação Bancária)
  • 30.
    Ex: ILO ”Elaborare Categorizar requisitos em diferentes níveis” ● Observações após 1º exame ● Alunos reclamaram de ”falta de questões sobre conceitos” ● Dificuldades para redigir os requisitos de acordo com cada perspectiva (negócio, stakeholder, usuário) – Mais prática de redação ou falta de entendimento do domínio? ● Sem dificuldade para explicar os conceitos ● Sem dificuldade de classificar requisitos já escritos ● Oportunidades de aprendizado (não planejadas) ● Demonstrar a dificuldade de se trabalhar com novo domínio ● Demonstrar a dificuldade de redação técnica
  • 31.
    Inspiração para Ativação ● Sua experiência prática! ● Iniciativas de Educação a Distância ● saas-class.org, db-class.com, coursera.org ● Muitos exemplos de ativação (exercícios, testes) ● Relatos de aplicação de PBL (Problem-based Learning) ● http://bit.ly/HVctJL ● Design & Teach a Course (Carnegie Mellon) ● http://www.cmu.edu/teaching/designteach/design/index.html ● Casos curiosos ● Meu mentiroso favorito - http://www.zenmoments.org/my-favorite-liar/ ● Teste Primeiro - http://testfirst.org/
  • 32.
    Pontos em Aberto ● Difícil planejar atividades de nível intermediário ● SOLO 2 é natural, material didático em abundância ● SOLO 5 é o PBL, Projetos Finais ● Mas, e o meio do campo? ● Tempo necessário para avaliação de atividades e exames ● Qual é a Filosofia Geral de Engenharia de Software? ● Como aplicar uma mudança com alunos e docentes ”viciados”? ● Como estender essa mudança para o nível de graduação ou unidade acadêmica? ● Materiais ”didáticos” muito informativos, mas pouco interativos ● Avaliação de curso ● ILOs podem não ser facilmente relacionados com ementa ● ENADE focado em conteúdo e não em competências ● Você tem pontos em aberto a sugerir?
  • 33.
    Objetivos ● Ao final dessa apresentação, os participantes serão capazes de: SOLO 5 ● Avaliar seus objetivos de disciplinas segundo a taxonomia SOLO ● Descrever o processo básico de SOLO 2 implementação da taxonomia em uma disciplina Objetivos Atingidos? Resultados Observados?
  • 34.
    Obrigado! ● AT07 – Professor, Pesquisador, Animador e Mágico ● Coordenação: Prof. Arthur Callado (arthur@ufc.br) ● Contato ● http://groups.google.com/group/ppam-l ● http://www.casa.ufc.br ● Link para essa apresentação ● http://www.slideshare.net/ccalmendra Prof. Camilo Almendra (camilo.almendra@ufc.br)