1. Coleta de dados
1.1. Etnografia: Coleta de dados por observação. Deve ser complementada com entrevistas, e outros métodos para se coletar os dados (vídeos, áudio)
1.1.1. Etnografia focalizada: combina etnografia com prototipação.
2. REQUISITOS
2.1. Revisões de requisitos: Ser feitas enquanto a definição de requisitos esta sendo formulada. Clientes e fornecedores devem participar.
2.2. Validação de Requisitos: os requisitos definem o sistema que o cliente realmente deseja. Custos de erros de requisitos são altos, por isso, a validação é muito importante.
2.3. TIPOS
2.3.1. Permanentes (estaveis pqe são derivados das atividades principais).
2.3.2. Voláteis (mudam)
2.3.3. Requisito funcional: descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, O QUE tem que ser feito pelo sistema. O que o cliente quer que o sistema faça.
2.3.4. Requisitos não-funcionais: podem constituir restrições aos requisitos funcionais e não é preciso o cliente dizer sobre eles. Características mínimas de um software de qualidade. Fica a cargo do desenvolvedor optar por atender esses requisitos ou não.
2.3.5. DEVE para requisitos obrigatorios e DEVERIA para requisitos desejaveis. Realce o texto para identificar partes importantes.
2.4. 1- Requisitos O QUE fazer, 2- Projeto COMO fazer.
3. PESQUISA
3.1. - Template para documentação boller
3.2. – Ian Sommerville 2006 Engenharia de Software 8ª edição (slides)
4. CASO DE USO - Principios de analise e projeto de sistemas com UML ¨C 2ª edição
4.1. Não é orientado a objeto é orientado a FUNCIONALIDADES que o usuário esta pedindo
4.2. Em caso de uso não precisa seguir a sequencia lógica de passos. O ator interage com CADA caso de uso individualmente.
4.3. Entrevista gera caso de uso. Ter certeza que é isso que o cliente quer
4.4. MONTAGEM DO CASO
4.4.1. Nota: Não existe ligação por dois casos ou atores de uso com linha continua (só pontilhada), ator liga-se a ator com seta (generalização)
4.4.2. Identificar atores - ator é todo elemento externo que interage com o sistema, as areas que serão afetadas (afim de descobrir as pessoas e departamentos envolvidos, os atores)
4.4.3. Identificar casos de uso. Dois tipos de caso de uso: Primario, representa os objetivos dos atores. Secundario:
4.4.4. ____________ relacao ___________> generalizacao; seta fechada!
4.4.5. OQ CONTEM
4.4.5.1. Caso de uso (Eclipse) – captar requisitos, e funcionalidades que o sistema pede.
4.4.5.2. Ator – interage com o caso de uso (entidades que estão interagindo com o sistema)
4.4.5.3. Extend – não é obrigatório fazer, ou não é sempre que ele vai fazer.
4.4.5.4. Include – inclui um caso de uso em outro caso de uso.
4.5. Caso de uso e outras atividades:
4.5.1. Documentação do sistema para os usuários
4.5.2. Validação
4.5.3. Realização de uma iteração
4.5.4. Os casos de uso podem ser alocados entre os membros de equipe de desenvolvimento. Como uma ajuda visual para validacao.
4.6. Exemplo de um Caso de Uso descritivo
4.6.1. Cadastrar internacao do paciente
4.6.2. Sumario: Funcionario usa o sistema para cadastrar paciente
4.6.3. Ator Primario: Funcionario/Adm
4.6.4. Pre-condicoes: Paciente deve ter guia de encaminhamento e documentos pessoais em maos
4.6.5. Fluxo Principais: Passos do sistemas; Sistema solicita entrada de dados, fucionario informa dados... Caso não tenha acompanhante (leva para o fluxo alternativo)
4.6.6. Fluxo Alternativo: Caso o paciente não tenha acompanhante seguir os passos...
4.7. De caso de uso a protótipo
4.7.1. Criar o protótipo das janelas a serem usadas.
4.7.2. Protótipos passam por avaliação do usuario para se aprimorarem
4.7.3. Depois da VALIDACAO do protótipo ele vira janelas
5. LINKS
5.1. Link para Requisitos funcionais e nao funcionais
5.2. Resumo de UML casos de uso
5.3. Norma ISO 9126
6. TESTES
6.1. Processo VV
6.1.1. Estrutura de um plano de teste:
6.1.1.1. • Processo de teste
6.1.1.2. • Rastreabilidade de requisitos
6.1.1.3. • Itens testados
6.1.1.4. • Cronogramas de testes
6.1.1.5. • Procedimentos de registro de testes
6.1.1.6. • Requisitos de hardware e de software
6.1.1.7. • Restrições
6.2. Teste de Caixa branca (integracao)
6.2.1. Quando o tester tem acesso ao código fonte
6.3. Teste de Caixa preta (release)
6.3.1. O tester nao tem acesso ao codigo fonte (geralmente feito pra testar funcionalidade, pode ser feito por qm nao é da area de TI)
6.3.2. Teste de Release (liberação)
6.3.2.1. Dentro dos testes de release Existe:
6.3.2.1.1. Teste de desempenho:
6.3.2.1.2. Teste de estresse:
6.4. Teste funcional:
6.4.1. Testar funcionalidades; é baseado somente na especificação de sistema, testadores não tem conhecimento de implementação do sistema.
7. Etapas da Eng de Software
7.1. Definicao: O QUE será desenvolvido . Requisitos do sistema, funcionalidades
7.2. Desenvolvimento: COMO será desenvolvido. Testes
7.3. Manutencao: mudanças a serem feitas. Adaptações, melhorias...
8. Tipos de processo
8.1. Processo iterativo incremental: se entrega partes do projeto de cada vez. Já sabe como será todo o projeto. Mudanças só depois da liberacao do “congelamento”
8.2. Processo de cascata: se entrega tudo no fim. Uma etapa só começa depois que sua anterior termina.
8.3. Processo evolutivo: Não se sabe o todo do projeto, muda e acontece aos poucos.
9. PROJETO DE INTERFACE
9.1. Interface de usuario
9.1.1. Deve ser desenvolvida para atender as habilidades, experiencias e expectativas dos usuarios. O usuario julga pela interface e não pela funcionalidade.
9.2. Fatores humano no projeto de interface
9.2.1. Memoria limitada de curto prazo;
9.2.1.1. lembrar de poucas coisas
9.2.2. As pessoas cometem erros;
9.2.2.1. mensagens e alarmes não devem irritar o usuario
9.2.3. As pessoas são diferente;
9.2.3.1. capacidades diferentes, fisicas por exemplo
9.2.4. As pessoas tem preferencias diferentes;
9.2.4.1. Alguns gostam de figuras, textos...