[Música] Olá eu sou professor Marcelo Fantinato Essa é a disciplina de gestão da informação nós vamos começar agora com a aula número sete continuando o assunto metodologias de desenvolvimento de sistemas de informação nessa aula nós vamos vamos nos focar mais em duas outras etapas do ciclo de vida de software que é a implementação e teste então na aula anterior nós tratamos análise de requisitos e o projeto de software né Nós saímos lá da lista de requisitos chegamos até ao projeto do software como o software deve ser implementado na verdade é um conjunto de projetos porque
você pode ter que projetar é esperado que você projete diferentes características por exemplo o o o conjunto de componentes internos o detalhamento de cada componente o processo que vai seguir para uso desses componentes até eh questões mais a alto nível por exemplo a tela projetar Como vai ser a tela projetar como vai ser o banco de dados bom uma vez que tudo isso foi projetado nós partimos então pra etapa eh posterior nós estamos agora ent entrando então na implementação do software a implementação ela é feita partindo ah do projeto do sistema que é justamente onde
nós paramos na aula anterior chegando na implementação do sistema ou seja na codificação propriamente dita um programador vai se basear numa parte do projeto em geral nós temos vários programadores se baseando em diferentes partes do projeto para fazer a codificação né ó isso pensando do ponto de vista dos do da programação propriamente dita mas nós podemos precisar implementar outras questões outras partes por exemplo implementar o banco de dados o banco de dados ele também faz parte do projeto durante o projeto você define Quais as tabelas quais os atributos agora isso precisa ser implementado propriamente dito
então a implementação do sistema envolve também a implementação do banco de dados assim como envolve também a implementação das Telas né Dependendo da forma como é o sistema da tecnologia a implementação de uma tela pode ser programação propriamente dita ou pode ser usando algum Framework alguma ferramenta que já cria as telas de uma forma um pouco mais direcionada mas em geral ainda é necessário alguns ajustes do ponto de vista de programação bom para a implementação do sistema a Ah nós podemos usar diferentes tipos de tecnologia tá eh em geral existem ferramentas que apoiam o trabalho
do programador aqui é um exemplo bastante eh ilustrativo bastante comum que é usar a ferramenta Eclipse para desenvolver um código aqui no caso é um código JAVA eh nós temos diferentes linguagens de programação que podem ser usadas tá pensando na programação propriamente dita nós temos diferentes ferramentas que permitem que o o o programador venha Criar o seu código né baseado numa série de relação entre diferentes componentes Ah mas eh de uma forma ou de outra nessa etapa o programador precisa realmente construir é como se a gente tivesse fazendo um mapeamento de novo com a questão
da construção de um edifício agora nós temos realmente a equipe eh lá na obra subindo as paredes colocando os tijolos passando a massa corrida e colocando encanamento colocando afiação elétrica eh tudo isso é representado Aqui nós temos que fazer o código nós temos que fazer a interface nós temos que implementar o banco de dados e são diferentes componentes do software sendo implementado para banco de dados a mesma coisa existem diferentes eh ferramentas de banco de dados que a gente chama na verdade de sistemas gerenciadores de banco de dados então você pode usar diferentes delas para
poder ah desenvolver o sistema né uma série de decisões precisam ser tomadas para saber quais as as técnicas as ferramentas que são serão usadas para cada parte do componente isso em geral costuma ser responsável por 40% ou mais de toda a atividade de engenharia de software tá ah Existem várias formas de ver isso mas por exemplo Alguns podem chegar a 60% e quando 60% do trabalho é feito de codificação sobra apenas 40% para todas as outras etapas Desde da coleta de requisitos até o teste que vem depois Alguns podem entender isso como muita ênfase na
programação propriamente dito e pouca ênfase nas outras atividades pré e pós programação qual um potencial o problema disso um potencial problema é que a Talvez não haja tanta qualidade nas outras atividades n Talvez os requisitos não foram levantados da forma melhor possível Talvez o projeto não foi feito de uma forma tão detalhada Talvez o teste que vai ser feito depois não foi feito de uma forma tão detalhada eh então você pode estar gastando muito tempo na implementação e talvez essa implementação não reflita ex examente o que o sistema precisa ter então isso pode ser um
indício de que as atividades não estão bem balanceadas no ciclo de vida né um outro indício de que algo pode estar errado é quando a atividade de teste consome muito tempo né atividade de teste pode chegar por exemplo a quase 50% e não deveria acontecer se você está gastando muito em teste é porque provavelmente muitos problemas estão sendo encontrados problemas que não precisavam ter do causados em teoria o teste deveria ser rápido apenas para verificar que não tem problema né e não ficar apontando todos os problemas identificados bom nós seguimos então na sequência ah do
da implementação E aí nós chegamos no teste de software que é o que eu estava mencionando justamente agora o teste de software pega o código que foi feito e a testa esse esse esse código então nós temos em geral uma pessoa chamada de testador ele vai executar o software que foi implementado eh buscando os erros então ele vai olhar com uma lupa aquele software e aí o teste pode passar ou o teste Pode falhar né o resultado pode ser positivo ou o resultado negativo se o resultado é negativo aqui ele erro precisa ser corrigido Ah
nós podemos precisar testar diferentes características da mesma forma que o o software ao ser implementado baseado no projeto cobre diferentes características o teste também pode ir para essas diferentes características por exemplo um teste que pode ser feito é as interfaces as telas estão funcionando bem são da forma como o cliente pediu a o banco de dados está consistente os dados estão sendo armazenados no banco de dados da forma correta ou está havendo inconsistência Ah o código propriamente dito quando eu peço para uma função calcular um número a mais um número B né 2 + 3
tá saindo realmente cinco né esse é um exemplo muito simples mas para eh ilustrar melhor Às vezes a ferramenta você pede para calcular 2 + 3 em vez de sair 5 sai 8 isso é um erro então o teste ele tem que pegar aquela implementação do sistema né que foi feita e testar de diferentes perspectivas tentando encontrar os problemas em teoria Então eu tinha dito que o ideal seria que nenhum problema fosse pego agora na prática sempre existem erros nós não podemos eh assumir que os erros não vão existir então a atividade de teste ela
acaba sendo muito importante para isso a uma outra característica importante é que você não consegue nunca provar que o software Está correto você pode no máximo dar um bom indicativo de que o software tem qualidade agora por mais que você já esteja executando a x horas e não conseguiu pegar mais nenhum problema isso não significa que o software está 100% correto o problema pode ser que você não identificou o problema você não foi um testad eficaz o problema está lá e você não conseguiu testar o sistema de uma forma que o problema se manifestasse tá
então a questão é o quão bom a atividade de teste está sendo feita e o quão bom a implementação foi feita você pode pegar muitos ou poucos erros dependendo se o software foi bem feito a implementação foi bem feita você deve pegar poucos erros mas talvez você esteja pegando poucos erros porque o teste está sendo feito de uma forma incorreta bom ah pensando nas diferentes estratégias de teste nós costumamos ah dividir os o software em ah diferentes unidades né então nós podemos pensar isso aqui tudo que está representado nessa figura como o sistema completo tá
e nós podemos eh pensar que esse sistema para organizá-lo melhor é dividido em grandes componentes aqui ilustrativamente eu tenho três grandes componentes poderia ter mais poderia ter menos mas a questão é isso é chamado de modularização é uma muito boa prática de se desenvolver sistemas modularize É aquela ideia de dividir para conquistar não tente fazer tudo de uma forma única e bagunçada Organize então o sistema pode ser dividido por exemplo em módulos uma parte para gerenciar clientes uma parte para gerenciar fornecedores uma parte para tratar das vendas por exemplo e cada uma dessas partes pode
ser subdividida subdividida subdividida você pode ter vários níveis de subdivisão aqui nessa figura só tenho três o sistema como um todo três grandes componentes e depois uma série de componente zinhos pequenos aqui tá de novo é apenas uma ilustração para mostrar que eu posso querer fazer o teste nesses três níveis diferentes eu posso querer pegar cada componente Zinho aqui e testá-lo individualmente isso a gente chama de teste de unidade eu tô testando eu estou testando cada unidade bom assumindo que cada unidade foi bem testada então eu posso testar a integração dessas unidades algumas eu algumas
unidades podem se integrar mais fortemente com outras então eu posso querer identificar né então por exemplo aqui eu integrei quatro unidades e aí eu faço a integração dessas unidades essa já foi testada essa já foi testada essa já foi testada e essa já foi testada cada uma delas individualmente em teoria estão funcionando bem não estão corretas necessariamente mas estão funcionando bem mas elas precisam trabalhar em conjuntos elas precisam ser Integradas então eu vou fazer o Test dessa integração delas quatro trabalhando juntas depois eu posso querer integrar essas nove unidades aqui inclusive uma dessas unidades é
a que faz a interface entre as outras duas unidades a integrações E aí eu testo essa integração para saber se todas as unidades que sozinhas funcionam bem se elas continuam funcionando bem quando elas são Integradas isso não é diferente do que a gente tem no dia a dia né uma pessoa pode fazer bem o seu serviço quando a gente coloca para ela trabalhar com outras pessoas a coisa não funciona bem então a integração pode dar problema eh e essa integração ela pode ir aumentando eu posso testar essa integração Posso testar essa integração e até que
eu testo O componente como um todo depois que eu testei o componente como um todo eu posso testar a integração desse componente com esse componente o mesmo está acontecendo aqui desse outro lado nesse outro componente e a gente vai subindo o teste Até que em algum momento eu possa testar o sistema como um todo o sistema vai ser testado de uma única forma Tá além da granularidade ser diferente as técnicas são diferentes as abordagens são diferentes por exemplo o teste de unidade que testa uma unidade especificamente ele em geral é feito pelo próprio programador o
programador implementa um pedacinho Testa o pedacinho implementa outro pedacinho testa outro pedacinho só que na hora de integrar isso já não é mais possível até mesmo não desejável porque sempre é bom em algum momento ter uma outra parte testando o que um fez para poder aumentar a chance de pegar problemas Ah se se o testador se o programador vai pegar um problema vai testar para tentar pegar um problema ele já sabia que aquele problema existia então em geral ele não consegue pensar em novos problemas adicionais Ah agora como diferentes eh componentes são implementados por diferentes
programadores Então a hora que nós começamos integrar esses componentes nós estamos integrando trabalhos de diferentes programadores e esse é um dos motivos de que a integração pode dar problema porque são códigos de diferentes programadores e aí em geral no teste de Integração eu já começo a ter uma outra figura que é uma pessoa focalizada especializada em fazer o teste de integração Ah E aí o teste de sistema é o teste em que com certeza é bom ter uma pessoa de fora fazendo de fora que eu digo é não da equipe de programadores analistas e de
teste e testadores específicos para fazer esse teste nesse caso em geral nós tratamos o sistema como uma caixa preta o que significa tratar como uma caixa preta significa que quem faz esse teste aqui não tem a noção da estrutura interna não sabe que eu tinha três grandes componentes dividido em outros componentes menores para ele isso aqui tudo é uma grande caixa preta Ele não enxerga o que tem aqui dentro tá não enxerga e ele vai simplesmente falar bom eu vou entrar com Tais informações no sistema vai processar de alguma forma que não me interessa e
vai ter uma saída aqui então eu tenho uma entrada e depois eu tenho uma saída a saída obtida é a esperada baseado nessa entrada se sim o teste passou se não o teste falhou se falhou onde é que está o problema dentro dessa estrutura aqui bom aí volta a obri a a responsabilidade pro programador o testador faz um relatório né Ele termina aquele teste especificamente fazendo um relatório dizendo eu fiz esse teste Eu entrei com esses dados era esperado esses resultados de saída Mas em vez disso eu consegui outros o sistema me deu outros resultados
Esse foi essa é a descrição da falha o sistema está falhando toma agora você vai analisar aí o programador ele que conhece a estrutura interna ele vai começar a tentar simular repetir o os passos do testador para ver lá dentro onde é que está o problema e aí ele corrige esse problema bom eu havia comentado que existiam diferentes tipos de requisitos né requisitos que são funcionais propriamente dito o que o sistema tem que fazer e requisitos que são não funcionais e eu posso querer testar tudo então por exemplo o que o sistema tinha que fazer
ele realmente está fazendo ele está indo direto ao alvo ele faz exatamente aquilo se é uma soma de A + B ele realmente está somando a + b Então esse é o tipo de teste funcional para saber se a funcionalidade está correta agora outras coisas que eu posso querer testar está sendo feito na no tempo correto eu consigo vários usuários ao mesmo tempo existe acessibilidade no sistema ah a comunicação sem fio está sendo feita correta o custo em termos de processamento em termos de energia Ah está sendo feito da forma correta eu consigo armazenar a
o armazenamento das informações Está correto então perceba que eu tenho uma série de outras coisas que eu posso querer testar que não são necessariamente ligados à funcionalidade a fazer correto o que era esperado mas sim podendo várias pessoas usar ao mesmo tempo num tempo adequado com custo adequado armazenando de forma adequada isso são os vários tipos de teste que a gente pode querer fazer tá isso tudo para ao final ter uma segurança de que a os requisitos dos clientes foram bem atendidos agora pensem prestem atenção como é que eu testo a acessibilidade o que eu
sei que é esperado de acessibilidade isso tem que estar especificado nos requisitos lá no início senão eu não consigo testar aqui bom com fim então a gente fecha o principal conjunto de atividades no ciclo de vida de desenvolvimento de software levanta os requisitos modelo o sistema projeto sistema implementa sistema e Testa o sistema e sempre voltando para corrigir problemas de uma etapa anterior bom com isso então a gente fechou as quatro principais atividades de um ciclo de desenvolvimento do sistema de informação nós Ainda temos temos outras atividades que a gente vai cobrir de forma breve
na próxima aula obrigado [Música] [Música] p [Música] [Música]
