Professor Emiliano S. Monteiro. [Versão 6 Maio/2019]

Transcrição

1 Professor Emiliano S. Monteiro [Versão 6 Maio/2019]

2

3

4

5

6 Avaliação e validação No final da fase de especificação de requisitos o documento final pode ser considerado Pai de outros documentos, pois a partir dele irão surgir outros, este documento foi apresentado ao cliente que deu o aceite final. A atividade de confirmar se o que se levantou esta correto e posteriormente certificar o que foi escrito tecnicamente no projeto das escolhas tecnológicas é que desejamos como avaliação e validação. Pois garante que a fase de desenvolvimento (construção) terá escolhido o ferramental correto para solucionar os problemas elencados pelo cliente.

7 Os erros mais significativos são aqueles cometidos durante a análise O custo para a correção dos erros aumenta quanto mais tarde eles forem detectados. Os desenvolvedores não gostam de testar seus sistemas Quando deixados para o final, os testes frequentemente são sacrificados Os sistemas são testados da forma como se acredita que eles irão funcionar, não do modo eles são efetivamente utilizados.

8 A rastreabilidade de todas as possibilidades de uso das funcionalidades pelo usuário é trabalhosa de ser executada e demorada.

9 O teste de software é uma investigação conduzida para fornecer aos interessados informações sobre a qualidade do produto ou serviço em teste. A técnica mais simples é o processo de execução de um programa de aplicação com a intenção de encontrar erros na sua execução O teste de software pode ser definido como o processo de validação e verificação do que um programa de computador / aplicativo / produto realiza. O que é esperado: atende aos requisitos que nortearam a sua concepção e desenvolvimento funciona como esperado pode ser implementado com as mesmas características satisfaz as necessidades dos clientes

10 Teste de caixa-branca (também conhecido como teste de caixa clara, teste de caixa de vidro, teste de caixa transparente e teste estrutural) é um método de teste de software que testa estruturas internas ou funcionamento de um aplicativo. Teste de caixa-preta é um método de teste de software que analisa a funcionalidade de uma aplicação (por exemplo, o que o software faz) sem olhando para as suas estruturas internas ou funcionamentos.

11 Teste de caixa preta: 1. Uma abordagem para testar onde o programa é considerado como uma "caixa-preta. 2. Os casos de teste do programa são baseados na especificação do sistema. 3. O planejamento de testes pode começar cedo no processo de software.

12 Teste de caixa branca: 1. Algum tempo chamado teste estrutural. 2. Derivação de casos de teste de acordo com a estrutura do programa. 3. O conhecimento do programa é usado para identificar casos de teste adicionais. 4. O objetivo é executar todas as instruções do programa (nem todas as combinações de caminho). 5. As medidas de cobertura de teste garantem que todas as declarações tenham sido executadas pelo menos uma vez.

13 Propósito Identificador Introdução Itens Funcionalidades Abordagem Critérios de aceite Suspensão Produtos Tarefas de testes Ambiente Responsabilidades Cronograma Tab Order

14 Testes de unitário é um método pelo qual as unidades individuais de código-fonte, um ou mais módulos, dados, e procedimentos, são testados para determinar se eles estão aptos para uso. Intuitivamente, pode-se ver uma unidade como a menor parte testável de um aplicativo. Na programação de uma unidade processual pode ser um módulo inteiro, mas é mais comumente uma função ou um procedimento individual. Na programação orientada a objetos, uma unidade pode ser uma classe ou um método individual. Os testes unitários são criados por programadores.

15 Os testes unitários são tipicamente escritos e executado por desenvolvedores de software para garantir que o código atende seu projeto e se comporta como deveria. Sua implementação pode variar deste muito manual (lápis e papel) até automatizada. Lista de frameworks de testes unitários: orks

16

17

18 Administrador Gerente Desenvolvedor Relator Visualizador

19

20

21

22

23

24

25

26

27

28

29

30 Novo - Este é o status de chegada de novos problemas. As questões permanecem neste status até que sejam atribuídas, reconhecidas, confirmadas ou resolvidas. O próximo status pode ser reconhecido", "confirmado", "atribuído" ou "resolvido". Reconhecido/Admitido - Este status é usado pela equipe de desenvolvimento para refletir seu acordo com a solicitação de recurso sugerida. Ou para concordar com o que o técnico/analista está sugerindo em um relatório sobre o assunto, embora eles ainda não tentaram reproduzir o que o técnico/analista está se referindo. O próximo status é tipicamente "atribuído" ou "confirmado". Confirmado - Este status é normalmente usado pela equipe de desenvolvimento para mencionar que eles concordam com o que o técnico/analista está sugerindo na questão e que eles confirmaram e reproduziram a questão. O próximo status é tipicamente "atribuído".

31 Atribuído - Esse status é usado para refletir que o problema foi atribuído a um dos membros da equipe e que esse membro da equipe está trabalhando ativamente no problema. O próximo status normalmente é "resolvido". Resolvido - Este status é usado para refletir que o problema foi resolvido. Um problema pode ser resolvido com uma de muitas resoluções (personalizável). Por exemplo, um problema pode ser resolvido como "fixo", "duplicado", "não irá corrigir", "nenhuma alteração necessária", etc. Os status seguintes são tipicamente "fechados" ou no caso de o problema ser reaberto, Então seria "feedback". Fechado - Este status reflete que o problema está completamente fechado e não são necessárias ações adicionais sobre ele. Também normalmente oculta o problema da página Exibir problemas. Algumas equipes usam "fechado" para refletir a assinatura do técnico/analista e outros o usam para refletir o fato de que a correção foi liberada para os clientes.

32 Novo Fechado Retor-no Admitido Atribuí-do Comfirmado Resolvido

33 Novo Fecha do Fechado Retorno (Reaberto) Retor no Resolv ido Admit ido Atribu ído Confir mado

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48 1. Redes Topologia 2. Sistemas operacionais 3. Hospedagens & data center / nuvem (locaweb, aws e amazon) 4. Ferramentas de desenvolvimento 1. Padronização entre membros da mesma equipe 2. Ferramentas que suportam desenvolvimento em grupo 3. Treinamento de novos integrantes da equipe 5. Manuais para a equipe de desenvolvimento 6. Banco de dados 1. Localização de banco de dados (local, lan, wan) 2. Escolha do banco de dados 7. Trocas de dados com outros sistemas 8. Prevenção de falhas 9. Dividir para conquistar 10. Backup do código fonte, documentação e projeto 11. Pessoas, Processos e Ferramentas

49 1.1. Topologia 1.2. Conexões com redes de terceiro/parceiros 1.3. VPN (virtual private network) 1.4. Firewalls 1.5. Link satelital 1.6. Integração com sistemas de telefônia

50 Detalhes de sistemas de arquivos Interfaces gráficas Acessibilidade Atalhos (+ ou padronizados) Desenvolvimento de serviços Microsoft domina o mercado de desktops Queda nas vendas de celular!

51 Client Side Javascript, ajax, ou plugins Browser (Firefox, Opera, Chrome) http request Internet http response (HTML, CSS, Dados, javascript, Imagens, etc) Porta 80 Server Side Web server Apache Microsoft IIS NGINX OS Server Scripts diversos File system Application server SQL Dados Microsoft IIS Tomcat/Glashfish Oracle Weblogic IBM Websphere Red Hat JBoss (WildFly) Zend Server Zope Node.js Exemplo: Porta 3306 (MySQL) e 1433 (SQL Server) Database server Oracle Database Oracle MySQL MariaDB IBM DB2 IBM Informix Microsoft SQL Server SAP Sybase Teradata Adabas Objetos & Tabelas

52 Hostgator

53 Full stack

54 CDN - Content Delivery Networks

55 Padronização entre membros da mesma equipe Ferramentas que suportam desenvolvimento em grupo Treinamento de novos integrantes Como escolher uma ferramenta? Preço em R$ Qualidade e quantidade da documentação Quantidade de usuários (nos fóruns do fabricante e nas redes sociais) Qualidade e quantidade de vídeos no youtube feitos por terceiros Quando saiu a última versão? Existe um change log disponível no site do fabricante? Existe um roadmap no site do fabricante? Política de atualização e preços de atualização Existe versão de avaliação? Demonstração? Webminars para apresentar novas features? Existem empresas na minha região usando? Existem usuários no Brasil usando? Essa ferramenta é usada na sua faculdade?

56 Deve-se escolher um tipo de nomenclatura Padronizar: Prefixos de tabela Nomes de tabelas Variáveis globais e locais Nomes de telas Nomes de relatórios Nomes de consultas Estilo de documentação, etc.

57 6.1. Localização de banco de dados (local, lan, wan) 6.2. Escolha do banco 6.3. Escolha de ferramentas para administração do banco de dados

58 Como são os procedimentos de exportação e importação de dados. Quais os formatos que são aceitos para importação e exportação de dados: XML, JSON, XLS, DOCX, TXT, DBF, CSV, ETC Se a troca de dados é com sistemas de terceiro (Nfe, por exemplo) existem manuais técnicos que devem ser seguidos.

59 Se o sistema não conseguir gravar dados no banco o que acontece? Ele grava localmente? (exemplo: sistema de ponto). Se o sistema não conseguir transmitir um dado ele guarda localmente? O sistema detecta quando a conexão de rede voltou? O sistema tem um módulo de backup do banco ou de partes dos dados na qual o usuário pode acionar a realização deste backup.

60 9.1. Dividir o sistema em partes e cada parte em uma plataforma diferente Um módulo para cada plataforma: mobile, desktop e web; definir o que roda em cada plataforma Dividir o sistema em partes, usar software gratuito onde possível e desenvolver o que é necessário e particular Landing page + ecommerce (OsCommcerce ou PrestaShop)+ CMS (Wordpress ou Joomla) + ERP

61 Existe um esquema de backup? Diário, semanal? O backup envolve a documentação, códigos e projeto? Alguma vez já foi feito um restore para se verificar se o backup esta aproveitável?