Baixe o app para aproveitar ainda mais
Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original
__MACOSX/._ENGENHARIA DE SOFTWARE ENGENHARIA DE SOFTWARE/EngSoft(2).pdf AULA 2 ENGENHARIA DE SOFTWARE Prof. Emerson Antonio Klisiewicz 02 CONVERSA INICIAL Nessa segunda aula estudaremos sobre os modelos clássicos de cálculo de esforço para o desenvolvimento de sistemas que fazem parte do processo de Engenharia de Software. CONTEXTUALIZANDO As métricas para se fornecer os esforços para a construção/desenvolvimento de um projeto de software mais utilizadas pela indústria são as seguintes: Pontos de Função (PF), Linhas de Código (LOC – Line of Code) e Pontos por Casos de Uso (UCP). Vamos a elas. TEMA 1 – MÉTODO GUSTAV KARNER? Criado por Gustav Karner, o método serve para informar o esforço que será gasto em projetos de software orientados a objetos. Ele baseia-se em casos de uso, o que permite ser possível, já no início dos projetos, verificar qual será o esforço desprendido para o desenvolvimento. Isso ocorre já na fase do levantamento de requisitos. Para utilizar esse método, necessitamos seguir 4 passos no nosso desenvolvimento: Os 4 passos do Método de Gustav Karner. 1. Avaliar o Ator. 2. Avaliar o Fluxo (Path). 3. Fazer o ajuste do UCP pelos fatores técnicos (TF) e pela Equipe EV. 4. Calcular o Esforço. TEMA 2 – USE CASE POINT – CALCULANDO O ESFORÇO 2.1 Os 4 passos do método de Gustav Karner 2.1.1 Avaliar o ator: pessoa, sistema ou tempo Pessoa é o ator complexo e vale 3 pontos. Sistema é ator médio e vale 2 pontos. Tempo é ator simples e vale 1 ponto. 03 2.1.2 Avaliar o fluxo (path) Conta-se cada fluxo principal e cada fluxo alternativo. Fluxos de exceção não são contados: De 1 a 3 fluxos – fluxo SIMPLES - 5 pontos. De 4 a 7 fluxos – fluxo MÉDIO - 10 pontos. De 8 ou acima – fluxo COMPLEXO - 15 pontos. UUCP = soma de pontos dos atores + soma de pontos dos fluxos 2.1.3 Ajuste do UCP Fazer o ajuste do UCP pelos fatores técnicos (TF) e da Equipe EV, sendo UCP = UUCP * TF * EF. 2.1.3.1 Fatores técnicos Nesse momento, o analista deve responder a 13 perguntas relacionadas a questões técnicas do projeto ou do sistema que está sendo desenvolvido. Para todas as perguntas, o analista atribuirá um valor de 0 a 5 ao nível de influência que tal questão tem dentro do contexto de desenvolvimento. Em cada pergunta, existe um peso atribuído que será multiplicado pelo valor de influência atribuída pelo analista a tal quesito. Ao final, o analista deve somar os resultados de todas as respostas às perguntas e colocar o valor na seguinte fórmula: TCF = (0,6 + (0,01 * SOMA DAS RESPOSTAS AS PERGUNTAS)). O resultado dessa conta será o valor do fator técnico em nosso processo. As 13 perguntas podem ter variações de empresa para empresa, mas, normalmente, seguem o modelo abaixo descrito: Quadro 1 – Perguntas técnicas sobre o projeto 04 2.1.3.2 Fatores ambientais Para este fator, o analista deve responder a 8 perguntas relacionadas a questões ambientais do projeto ou do sistema que está sendo desenvolvido. Esse fator leva em conta questões relacionadas à equipe que trabalhará no desenvolvimento. Seguindo a mesma ideia dos fatores técnicos, para todas as perguntas o analista deve atribuir um valor de 0 a 5 ao nível de influência que tal questão tem dentro do contexto de desenvolvimento. Em cada pergunta, existe um peso fixo atribuído, o qual deve ser multiplicado pelo valor de influência atribuída a aquele quesito. Ao final, o analista precisa somar os resultados de todas as respostas às perguntas e colocar o valor na seguinte fórmula: EF = (1,4 + (-0,03 * SOMA DAS RESPOSTAS AS PERGUNTAS)). As 8 perguntas podem ter variações de empresa para empresa, mas, normalmente, seguem o modelo abaixo descrito: Quadro 2 – Modelo de perguntas 05 É importante salientar que, no TF, quanto maior o valor encontrado, maior será o esforço gasto no desenvolvimento do sistema. No EF é o contrário. Quanto maior o valor encontrado, menor será o esforço para o desenvolvimento. Com os fatores calculados, obtém-se o valor dos Use Case Ajustados: UCP = UUCP * TF * EF. 2.1.4 Calcular o esforço Com o UCP calculado, faremos a multiplicação dos pontos UCP pelo fator de produtividade (homem.hora por UCP). A produtividade média recomendada é entre 15 e 30 homem.hora por UCP, sendo 20 a média internacional. Esforço (homem.hora) = UCP * produtividade Abaixo há um exemplo do esforço calculado levando-se em consideração o esquema de fluxos mostrados. Note que os fatores de TC e EF têm os respectivos valores: 0,98 e 1,01. Quadro 3 – Cálculo de esforço 05 Motivação São os programadores motivados para trabalhar no projeto? Instabilidade no projeto vai sempre levar para as pessoas que saem no meio do caminho através do seu código-fonte. E a mão sobre torna-se realmente difícil. 1 none 0 0 06 Requisitos estáveis É ao usuário clara sobre o que ele quer? Tenho visto as expectativas dos clientes são o fator mais importante na estabilidade dos requisitos. Se o cliente é de uma natureza altamente mudar, colocar esse valor máximo. 2 none 0 0 07 Part-time trabalhadores Há pessoal em tempo parcial no projeto, como consultores, etc? -1 none 0 0 08 Difícil linguagem de programação Qual é a complexidade da linguagem, Assembly, VB 6.0, C + + e C ou Framework? -1 none 0 0 0 1,4 Efactor EF - Enviroment Factor = ( 1,4 + ( -0,03 * Efactor) ) 06 TEMA 3 – ANÁLISE POR PONTOS DE FUNÇÃO 3.1 NESMA – A associação Para se associar à NESMA (Netherlands Software Metrics Association), a composição de custos varia em 250 € por ano. Sem fins lucrativos, ao associar- se você terá os benefícios de acesso ilimitado ao site, obter uma cópia gratuita de cada novo produto da NESMA, poder participar nas comissões e conferências que essa associação oferece, ter descontos em atividades (conferências, simpósios, workshops etc.) e produtos (estudos, relatórios e manuais) que ela disponibiliza. Muitas grandes empresas são sócias da NESMA, como ABN-AMRO Bank NV, IBM Nederland e BV. 3.2 Para que serve a APF? A Análise por Pontos de Função (FPA) é um técnica de medição do tamanho de softwares que tenta relacionar a complexidade inerente ao processamento com as funcionalidades solicitadas/oferecidas ao usuário por meio do software. 3.3 Quais os objetivos da APF? Os pontos de função têm alguns objetivos. Dentre eles, podemos destacar: a. Medir a funcionalidade que o usuário solicita e recebe. b. Medir o desenvolvimento e a manutenção de software de forma independente da tecnologia utilizada na implementação. c. Ser simples o suficiente para minimizar o trabalho adicional envolvido no processo de medição e informação da condução do desenvolvimento. d. Ser uma medida consistente entre vários projetos e organizações. 3.4 Como usar a APF nas Organizações? A análise por ponto de função também pode ser usada para verificar o tamanho de softwares adquiridos ou já existentes em uma empresa. Também pode ser utilizada para dar apoio à análise no desenvolvimento de softwares, visando mais qualidade no produto final (software). E, ainda, pode ser utilizada como uma ferramenta de apoio à manutenção de software, bem como no controle 07 de custos do desenvolvimento, ajudando nas negociações de contratos nas áreas de TI junto aos usuários. 3.5 Etapas da APF O cálculo da análise de pontos de função terá os seguintes passos para a sua obtenção: a. Identificação do tipo de contagem a ser utilizado. b. Definição da fronteira da aplicação. c. Contagem de pontos de função não ajustados. d. Cálculo do fator de ajuste. e. Contagem de pontos de função ajustados. 3.5.1 Identificação do tipo de contagem a ser utilizado Consiste na identificação do objeto a ser medido, como sendo um projeto de desenvolvimento, manutenção ou produção. Ou seja, faremos a pergunta: “O que medirei?” 3.5.2 Definição da fronteira da aplicação Esta é a etapa em que se estabelece o escopo do sistema objeto da avaliação, sob a visão do usuário. Nesse momento, fazemos a pergunta: “Até onde medirei?” Essa situação é de extrema importância para definirmos qual será o escopo do desenvolvimento, e de onde e para onde irão as informações do sistema/manutenção/desenvolvimento. Tudo isso é preciso prever. 3.5.3 Contagem de pontos de função não ajustados Para essa etapa, iniciaremos o processo de cálculo propriamente dito, levando em consideração os seguintes itens: Arquivo Lógico Interno (ALI). Arquivo de Interface Externa (AIE). Entradas Externas (EE). Saídas Externas (SE). Consultas Externas (CE). Esses itens podem ter a sua dimensão analisada pela figura abaixo: 08 Figura 1 – Contagem de pontos de função não ajustados Iniciaremos o nosso processo de cálculo fazendo a atribuição da complexidade de cada item. Vamos a eles. 3.5.3.1 Atribuindo complexidade a um ALI/AIE Antes da atribuição, vamos entender o que é um ALI e um AIE. Arquivo Lógico Interno (ALI) são dados (arquivos, tabelas ou entrada de dados realizadas no sistema) logicamente relacionados que serão utilizados ou sofrerão algum tipo de manutenção e que estão dentro das fronteiras do software. Podem ser identificados pelos critérios (dados armazenados dentro da fronteira da aplicação que sofrem manutenção por meio de um processo padrão da aplicação e são identificados pelo usuário como sendo um requerimento da aplicação). Exemplo: dados da aplicação, arquivos mestres, como cadastro de clientes ou cadastro de funcionários, arquivos de dados de segurança da aplicação, arquivos de dados de auditoria, arquivos de mensagens de auxílio, arquivos de mensagens de erro. Os Arquivos de Interface Externa (AIE) representam as informações necessárias externas à aplicação. Contribuem para o cálculo dos Pontos por Função com base na quantidade e complexidade funcional relativa de cada um deles. Podemos identificá-los usando critérios, como verificar se são dados armazenados fora da fronteira da aplicação, se não sofrem manutenção por meio de um processo padrão da aplicação e se são também identificados pelos usuários como sendo requerimentos do software. Exemplo: informações de referência (dados externos utilizados pela aplicação, mas que não têm sua 09 manutenção realizada pela aplicação), arquivos de mensagens de auxilio e arquivos de mensagens de erro. Com essas definições, vamos iniciar o processo de atribuição da complexidade. 3.5.3.1.1 Identificar os TERs e TEDs a. TER – Tipo de elemento de registro. É a quantidade de tipos de registros, no caso de um arquivo, ou de tabelas, no caso da utilização de um banco de dados. Podemos dizer que é um subgrupo de dados dentro de um ALI/AIE reconhecível pelo usuário. b. TED – Tipo de elemento de dado. É a quantidade de campos de um arquivo ou de uma tabela utilizados na aplicação. Podemos dizer que, nesse caso, é um campo único, não repetitivo e reconhecível pelo usuário. c. Feita essa análise, atribuímos a complexidade dos ALI e AIE usando a tabela abaixo: Tabela 1 – Complexidade dos ALI e AIE Seguindo a mesma lógica, faremos agora a identificação dos quesitos SE, CE e EE, mas antes apontaremos suas definições: a. ENTRADAS EXTERNAS (EE): São as atividades realizadas pelos usuários por meio de um processo dentro do sistema, como inserção, modificação ou exclusão de dados nos arquivos lógicos internos (ALI). b. SAÍDAS EXTERNAS: São as atividades realizadas pelo sistema/programa, que resultam na extração de dados da aplicação, dados que estão presentes nos ALI´s. c. CONSULTAS EXTERNAS: São as atividades que, por meio de uma requisição de dados (entrada), geram exibições imediatas dos dados (saída) contidas nos ALI´s. Com essas definições, apresentaremos a mesma definição dos processos do ALI e AIE. 010 a. TAR – Tipos de arquivos/tabelas referenciados na aplicação. É a quantidade de ALI/AIE mantida ou referenciada (utilizada) pelas transações do sistema. b. TED – São os elementos de dados; campos reconhecíveis pelo usuário, que podem também cruzar a fronteira da aplicação durante as transações realizadas pela aplicação. Seguindo as definições acima, apresentamos as complexidades usando as tabelas abaixo: Tabela 2 – Complexidade EE Tabela 3 – Complexidade SE e CE Com a definição da complexidade dos itens (Baixa, Média e Alta), a tabela de pontuação para os itens seguirá a relação abaixo: Tabela 4 – Nível de complexidade Dessa forma, fechamos o cálculo de pontos não ajustados. Agora veremos a questão do ajuste a ser realizado (Opcional) aos pontos calculados até aqui. 011 TEMA 4 – ANÁLISE DE PONTOS DE FUNÇÃO – CÁLCULO DO FATOR DE AJUSTE O valor do FATOR DE AJUSTE, similar ao UCP, é calculado com base em 14 características que envolvem o desenvolvimento do software e permitem uma avaliação geral da funcionalidade da aplicação. Estas características são: 1. Comunicação de Dados; 2. Processamento Distribuído; 3. Performance; 4. Utilização do Equipamento; 5. Volume de Transações; 6. Eficiência do Usuário Final; 7. Entrada de dados “on-line”; 8. Atualização “on-line”; 9. Processamento Complexo; 10. Reutilização de Código; 11. Facilidade de Implantação; 12. Facilidade Operacional; 13. Múltiplos Locais; 14. Facilidade de Mudanças. É atribuída uma nota de 0 a 5 a cada uma das Características Gerais do Sistema, correspondendo aos seguintes critérios: nenhuma influência, influência incidental, moderada, média, significante, essencial. Após isso, usamos a seguinte fórmula do fator de ajuste: Em que Nt(total) é a soma dos níveis de influência atribuída às perguntas. Com isso, calculamos o valor final, que é TPF = PFB * VAF, em que PFB é o total de pontos de função bruto calculado. 012 Exemplo de um cálculo sem fazer o ajuste: Tabela 5 – Transações (campos e arquivos referenciados) Tabela 6 – Contagem: entradas externas Tabela 7 – Contagem: saídas externas 013 Tabela 8 – Contagem: consultas externas Tabela 9 – Contagem: Arquivos Lógicos Internos Tabela 10 – Contagem: Arquivos de Interface Externa Tabela 11 – Contagem final de PF (não ajustados) 014 TEMA 5 – ANÁLISE POR PONTOS DE FUNÇÃO SIMPLIFICANDO COM O NESMA Há formas simplificadas de realizar o cálculo do APF por meio de métodos simplificados criados pelo NESMA. Nessa versão, existem 3 tipos de contagem: Indicativa, Estimativa e Detalhada. Vamos a elas. 5.1 Contagem indicativa A contagem Indicativa traz o valor da quantidade de pontos de função sem saber os detalhes do modelo e sem ter um detalhamento do processo. Ela possibilita, dessa forma, medir um software já no início do processo de desenvolvimento, mesmo não possuindo todas as informações. Assim, podemos usá-la na fase inicial do desenvolvimento. A contagem indicativa realiza-se da seguinte forma: Determina-se a quantidade de ALIs e AIEs. O tamanho é calculado contando-se 35 PFs para cada ALI identificado e 15 PFs para cada AIE. Essa estimativa baseia-se somente na quantidade de arquivos lógicos (ALIs e AIEs), calculando-se o total de pontos de função não ajustados da seguinte forma: tamanho indicativo (pf) = 35 x número de ALIs + 15 x número de AIEs. Exemplo: Tabela 12 – Contagem indicativa ALI – Arquivos Lógicos Internos AIE – Arquivos de Interface Externas (pf) = 35 x número de ALIs + 15 x número de AIEs 35 x 2 + 15 x 1 = 70 + 15 = 85 pf 015 5.2 Contagem estimativa É utilizada na fase inicial da proposta de desenvolvimento, quando não se possuem dados detalhados do processo, apenas informações preliminares sobre os processos e o modelo de dados. São necessárias informações um pouco mais detalhadas sobre a funcionalidade da aplicação, levantadas a partir das exigências do usuário. Para usar essa contagem, temos os seguintes passos: 1º PASSO: Encontram-se todos os tipos (ALI, AIE, EE, SE, CE). Não é necessário a identificação dos TAR e TED de cada função. 2º PASSO: Todos os ALI e AIE têm sua complexidade avaliada como baixa. Todos os EE, SE, CE são avaliados como de complexidade. 3º PASSO: Calcula-se o total de pontos de função não ajustados, utilizando a classificação de complexidade. A diferença à contagem usual de pontos de função é que a complexidade não é determinada individualmente, mas pré-definida para todos. Exemplo: O usuário deseja adicionar, alterar, excluir e consultar dados de Clientes, necessita de 4 diferentes tipos de relatórios contendo dados calculados; deseja adicionar, alterar, excluir e consultar dados de Produtos, necessita de um relatório de produtos; deseja consultar o Fornecedor por meio de seu número e precisa de um relatório sobre Fornecedor com totalização de resultados. Veja como ficariam essas requisições: 016 Quadro 3 – Requisições 5.3 Contagem Detalhada É utilizada na fase em que se possui um grande conhecimento da proposta de desenvolvimento (dados detalhados do processo). Saber somente o número de funções de cada tipo (EE, SE, CE, ALI, AIE) não é o suficiente, também é necessário determinar a complexidade funcional (Baixa, Média, Alta) de cada função individualmente. Os requisitos dos usuários precisam ser analisados com mais detalhes: é preciso identificar quais elementos de dados e arquivos lógicos são usados por cada função transacional, e quais grupos lógicos e elementos de dados compõem cada função. FINALIZANDO O surgimento de sistemas de software complexos resultou na necessidade de reavaliar a forma de desenvolver sistemas. A técnica tem evoluído de forma impressionante, notavelmente no que tange ao seu 017 desenvolvimento. A precisão da estimativa do tamanho de uma aplicação varia de acordo com o grau de conhecimento adquirido sobre ela, ou, em outras palavras, da fase em que se encontra o projeto. Segundo a empresa Software Produtivity Research, “ao final da fase de desenho do sistema é possível se fazer estimativas com margem de erro de +/- 10%.” Nesta aula, apresentamos técnicas em que pudemos mensurar os esforços que teremos no desenvolvimento de nossas apresentações. Tais métodos fazem parte da Engenharia de Software como ferramentas que auxiliam o analista a tomar decisões sobre condução e controle do desenvolvimento das aplicações em TI. 018 REFERÊNCIAS ANÁLISE de pontos de função inicial. Nesma. Disponível em: <http://nesma.org/freedocs/analise-de-pontos-de-funcao-inicial/>. Acesso em: 19 set. 2017. AZEVEDO, D. J. P. de. FPA – Function point analysis – sistemática de métrica. Bate Byte, 2009. Disponível em: <http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=415>. Acesso em: 19 set. 2017. __MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(2).pdf ENGENHARIA DE SOFTWARE/EngSoft(3).pdf ENGENHARIA DE SOFTWARE Prof. Emerson Antonio Klisiewicz AULA 3 2 CONVERSA INICIAL Olá! Nesta aula, vamos estudar sobre as metodologias ágeis e seus tipos, pois elas também fazem parte do processo de engenharia de software. TEMA 1 – PROCESSOS ÁGEIS No fim da década de 90, novos modelos começaram a surgir, assumindo que, com as ferramentas e práticas adequadas, era simplesmente mais rentável escrever o código rapidamente, avaliá-lo com o usuário e, em caso de erros, arrumá-lo rapidamente, que tentar antecipar e documentar todos os requisitos primeiro. Nesse contexto, surgem os processos ágeis. 1.1 Criação do manifesto ágil O manifesto ágil foi redigido em uma reunião por um grupo de 17 indivíduos, todos criadores de diversas metodologias: Kent Beck (XP), Mike Beedle, Arie van Bennekum, Alistair Cockburn (Cristal/Clear), Ward Cunningham (XP), Martin Fowler, James Grenning, Jim Highsmith (ASD), Andrew Hunt, Ron Jeffries (XP), Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber (SCRUM), Jeff Sutherland (SCRUM) e Dave Thomas. Nessa reunião, foram discutidos temas relacionados à metodologia para o desenvolvimento de software. 1.2 O manifesto ágil 1.2.1 Valores Estamos descobrindo maneiras melhores de desenvolver software fazendo-o e ajudando os outros fazê-lo. Por meio deste trabalho, concluímos os seguintes valores: os indivíduos na equipe e as interações no desenvolvimento são mais importantes que processos e ferramentas; software entregue e funcionando é mais importante que ter uma documentação completa e totalmente detalhada; a colaboração com o cliente naquilo que ele necessita é mais importante que a realização da negociação de contratos; 3 a adaptação a mudanças do sistema tem uma maior importância que seguir um plano inicial. 1.2.2 Princípios A maior prioridade sempre é satisfazer o cliente por meio da entrega antecipada e contínua de software. As mudanças nos requisitos não são problemas, mesmo no final do desenvolvimento. Os processos ágeis asseguram que a mudança gerará vantagem competitiva para o cliente. As entregas do software funcionando devem ser realizadas com maior frequência, a partir de um par de semanas ou meses, com preferência em uma escala curta de tempo. Equipes de negócios e desenvolvedores trabalhando juntos diariamente durante o desenvolvimento do projeto. A construção de projetos com equipes motivadas. Fornecer o ambiente e o apoio de que necessitam, além da confiança necessária para fazer o trabalho. O Ágil é um método eficiente e eficaz para transmitir informações para dentro da equipe de desenvolvimento. Usa-se a conversa face a face. Ter o software funcionando é a principal forma de se medir o progresso. Os processos ágeis têm um desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter o ritmo constante e de forma indefinida. Sempre deve possuir atenção máxima a excelência técnica e a um bom design, aumentando, assim, a agilidade. Ser simples, ou seja, maximizar a importância do trabalho não feito. Possuir equipes auto-organizadas. A equipe de desenvolvimento deve parar e refletir de tempos em tempos sobre como se tornar mais eficaz e sintonizar e ajustar seu comportamento de acordo com essa reflexão. 4 Leitura obrigatória Para ampliar seus estudos, leia o capítulo 5, itens 1 a 3 do livro: PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. TEMA 2 – EXTREME PROGRAMMING Nos anos 1990, o engenheiro Kent Beck, ao procurar formas mais simples e eficientes para o desenvolvimento de software, identificou o que o tornava simples e o que dificultava no desenvolvimento de software. Nesse caminho, iniciou a eXtreme Programmin, uma metodologia ágil muito utilizada na atualidade. Essa metodologia foi desenvolvida para ser utilizada em equipes médias e pequenas (2 a 12 pessoas) e para trabalhar com requisitos vagos e em constante evolução. Também tem um conjunto de valores e práticas para nortear o desenvolvimento de software. 2.1 Princípios 2.1.1 Comunicação Todos os membros da equipe, sejam clientes, sejam gerentes, sejam programadores, devem se relacionar pessoalmente uns com os outros, agilizando a comunicação. Se possível, devem trabalhar em um mesmo ambiente para se reunirem pessoalmente. 2.1.2 Simplicidade O projeto do software é simplificado continuamente e o processo de desenvolvimento deve ser adaptado, caso essa situação não esteja ocorrendo. 2.1.3 Feedback O cliente deverá estar presente no desenvolvimento do sistema. Testes unitários e de homologação devem fornecer o entendimento sobre o desenvolvimento do software. 5 Questões de oportunidades ou aquelas relacionadas a problemas do desenvolvimento devem ser informadas o mais rápido possível. 2.1.4 Coragem Os membros da equipe de desenvolvimento devem ter coragem para indicar situações de problemas encontrados no projeto e para solicitar ajuda quando necessário. Informar ao cliente – o mais rápido possível – que não será possível implementar um requisito no prazo estimado. 2.2 O processo Figura 1 – Desenvolvimento de software Dessa forma, tem-se uma metodologia interessante para usar no desenvolvimento de software, porém pode haver possíveis barreiras para o sucesso de um projeto XP, como: cultura – pode ser que a organização tenha uma cultura fortemente tradicional, com ênfase em metodologias clássicas, muita documentação, modelagem etc.; tamanho das equipes – as equipes devem ser pequenas, com no máximo 12 pessoas, mas nem sempre isso é possível; espaço físico – o local de trabalho deve servir para aproximar as equipes, facilitando a comunicação; 6 cliente: no XP, o cliente deve trabalhar ou estar com equipe de desenvolvimento. Leitura obrigatória Para ampliar seus estudos, leia o capítulo 5, item 4. PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. TEMA 3 – SCRUM Trata-se de um framework utilizado para organizar times e entregar resultados de maneira mais produtiva e com alta qualidade. O Scrum foi fundamentado no empirismo, com o emprego de um desenvolvimento iterativo e incremental para otimizar a previsibilidade e também controlar os riscos. É uma alternativa para utilizar métodos ágeis na gerência de projetos, sendo aplicável a qualquer tipo de projeto. Trabalha de forma simples com processo, artefatos e regras, que são poucas e fácil entendimento. É fundamentado em 3 pilares: 1. Transparência – A equipe de desenvolvimento deverá ter uma visão clara e objetiva de todo o processo. Para isso, o fundamental será a comunicação; 2. Inspeção – Com frequência, os artefatos (backlog do produto, backlog do sprint, burndown…) deverão ser verificados, sendo informado assim os progressos do projeto; 3. Adaptação – Se o responsável pela verificação identificar que algum processo não está de acordo com o planejado e que o resultado não será favorável ao produto, deverá relatar e realizar o ajuste o mais rápido possível, a fim de que não haja mais desvios. No Scrum, temos 3 papéis de trabalho dentro da equipe: I. Product owner – É a pessoa responsável por apresentar os interesses de todos os stakeholders. Definirá os planos iniciais do projeto, os objetivos e o que será entregue na versão a ser desenvolvida. É responsável pela lista de requisitos (product backlog) e por verificar se as atividades com maior valor para o negócio serão desenvolvidas primeiramente. 7 II. Scrum master – É o responsável pelo sucesso do Scrum, ensinando-o para a equipe de projeto. Deverá verificar se cada pessoa envolvida no projeto está seguindo os papéis e as regras do Scrum, a fim de garantir que aquelas não responsáveis pelo processo interfiram no desenvolvimento. III. Time – É a equipe. Serão os responsáveis por escolher as funcionalidades a serem desenvolvidas em cada interação e desenvolvê-las. A equipe de se autogerenciar. Todos os membros são coletivamente responsáveis pelo sucesso de cada entrega do desenvolvimento. 3.1 O processo Figura 2 – SCRUM Fonte: Elaborado com base em Agile Software Development with Scrum (Schraber & Beedle). Beedle citou que “O Scrum pressupõe o caos...”, mas, na verdade, capacita as equipes de desenvolvimento a trabalhar em processos que normalmente não são livres da incerteza. Leitura obrigatória Para ampliar seus estudos, leia o capítulo 5, item 2. PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 8 TEMA 4 – ESTIMATIVAS Nas metodologias ágeis, estimativas de esforço e tempo são calculadas a partir de estórias (requisitos). Essa atividade é de responsabilidade de toda a equipe técnica, e isso por alguns motivos, alguns dos quais são citados a seguir. Quando se está planejando o desenvolvimento, normalmente não se sabe exatamente quem vai implementar quais partes dos requisitos. Estórias normalmente envolvem diversas pessoas com diferentes conhecimentos (design de interface de usuário, codificação, teste etc.). Para realizar uma estimativa, a equipe precisa de algum tipo de compreensão de cada estória. Um maior entendimento do contexto aumenta as chances dos membros da equipe se ajudarem durante a iteração. Isso também ajuda a aumentar a probabilidade de que questões importantes sobre a estória/requisito surjam cedo. Quando todos da equipe estimam uma estória/requerimento, é frequente que se encontrem desconexões onde mais de um membro da equipe tenha estimativa bastante diferente para a mesma estória/requerimento. É necessário discutir essas situações antes do início da iteração. Nas metodologias ágeis, as estimativas seguem um questionamento relacionado a uma grandeza, e não especificamente a um número, como no exemplo abaixo. Figura 3 – Tamanhos/estimativas Os tamanhos/estimativas estão sendo dados por uma grandeza, e não por um número/valor. Leitura obrigatória Para ampliar seus estudos, leia o capítulo 33, item 9. PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 9 TEMA 5 – PLANNING POKER É uma técnica de estimativa que busca o consenso. Apesar de usualmente ser utilizada no processo de planejamento ágil, não se trata da única. No Scrum, o planning poker é realizado durante o sprint planning metting. Nessa forma de estimativa, cada integrante tem à sua disposição um baralho de 13 cartas, numeradas em uma sequência encontrada nos números de Fibonacci. Figura 4 – Planning poker O objetivo de utilizar esses números não lineares é que o intervalo entre os valores permite visualizar melhor as diferenças de complexidade entre as funcionalidades sugeridas pelo requisito/estória dessa forma, evitando a impressão falsa de precisão na estimativa. Exemplo: se para um item foi dada uma estimativa de 20 pontos, não faz muita diferença se pudesse ser dado um valor próximo. Portanto, esse valor trata-se de um palpite aproximado. Valores acima de 20 são considerados altos e, portanto, trata-se de uma estória/requerimento com um tamanho maior, que pode não ser completamente finalizada numa única iteração. O recomendável é que, ao final da estimativa, usando o planning poker, seja possível fazer com que as estórias/requerimentos da iteração tenham algum valor no intervalo de 1∕2 a 13. No baralho do planning poker, podemos encontrar algumas cartas com propósitos especiais: carta com valor 0 (zero), indicando que uma estória está finalizada ou é muito pequena, podendo ser resolvida rapidamente; 10 carta com ? (interrogação), indicando que o membro da equipe não tem o conhecimento apropriado para estimar/opinar sobre o esforço necessário para a estória/requerimento. Durante o planning poker, devem ser realizadas rodadas para obter a estimativa da estória/requerimento com base nesses valores. As diferenças que surgirem durante essas rodadas deverão ser mediadas por um coordenador. No Scrum, esse papel é de responsabilidade do scrum master. 5.1 Planning poker – Jogando As estórias/requerimentos são apresentadas uma por vez. O product owner as descreve para a equipe Scrum de desenvolvimento e fornece informações a respeito do seu valor de negócio. A seguir, o coordenador pergunta aos membros da equipe o esforço necessário para desenvolvê-la. Cada membro da equipe reflete a respeito do tempo e do esforço necessários para implementar a estória/requerimento apresentado. Os membros da equipe estimam considerando todas as tarefas envolvidas no desenvolver (testar, criar design etc.). Então, o membro da equipe escolhe uma carta no baralho correspondente ao valor dessa estimativa e coloca-a virada para baixo. Quando todos fizerem o procedimento acima, revelam-se as cartas escolhidas simultaneamente. 11 Isso faz com que cada membro da equipe pense por si próprio na hora de uma decisão da estimativa. Todos avaliam os resultados e verificam se houve convergência entre as cartas mostradas, ou seja, todas as estimativas têm valores aproximados para a mesma estória/requerimento. Se não houver essa convergência, o scrum master solicita aos membros que mostraram o menor e o maior valor que expliquem o motivo que os levou a tal decisão. Isso faz com que os integrantes reflitam sobre alguns pontos da estória/requerimento, o que pode fazer com que mudem os valores propostos para as estimativas. Então, uma nova rodada é realizada até que as estimativas cheguem a uma convergência. A estimativa final será o valor que tiver maior ocorrência ou a média entre as estimativas informadas. Então, começa uma nova rodada com a leitura da próxima estória/requerimento pelo product owner. O processo se repete até que tenha sido concluída a estimativa das estórias dos itens do product backlog. Leitura obrigatória Para ampliar seus estudos, leia o capítulo 33, item 9. PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. FINALIZANDO As metodologias ágeis seguem o parâmetro de sempre ter equipes de desenvolvimento que se autogerenciem, que tenham controle sobre o que estão desenvolvendo e tenham uma grande comunicação não só entre os membros das equipes para também com os clientes que recebem o produto desenvolvido, pois a ênfase aqui é que o cliente esteja recebendo constantemente entregas do desenvolvimento que agreguem ao seu negócio, trazendo, assim, sua satisfação. 12 REFERÊNCIAS PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. __MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(3).pdf ENGENHARIA DE SOFTWARE/EngSoft(4).pdf AULA 4 ENGENHARIA DE SOFTWARE Prof. Emerson Antonio Klisiewicz 02 CONVERSA INICIAL Olá, aluno. Nesta aula, vamos estudar as métricas em projetos de testes para o desenvolvimento de sistemas que também fazem parte do processo de engenharia de software. Bons estudos! CONTEXTUALIZANDO “O teste consiste em executar o programa com a intenção de encontrar erros (bugs)”, Myers, 1979. Por que temos que testar os softwares? Será que alguém se sentiria confortável, tranquilo em ser o passageiro de um avião que nunca tivesse decolado antes? Itens como qualidade de software, corretitude, confiabilidade são vitais para um software, e todos eles são construídos a partir de um excelente programa de testes. TEMA 1 – TERMINOLOGIAS 1.1 Garantia de qualidade de software É um conjunto de atividades técnicas que devem ser aplicadas durante todo o processo de desenvolvimento de um software. O objetivo é garantir que tanto o processo de desenvolvimento do software quanto o produto que será entregue tenham os padrões de qualidade especificados. 1.2 Validação Garantirá que o produto final desenvolvido corresponda plenamente aos requisitos solicitados pelo usuário. 1.3 Verificação Visa assegurar a consistência, a completude e a corretude do software desenvolvido em cada fase do projeto e entre as fases consecutivas do ciclo de vida do software. 1.4 Teste Visa garantir o funcionamento do software pelo exame do comportamento do produto por meio da sua execução. 03 1.5 Defeito Deficiência mecânica ou algorítmica encontrada no software que, se ativada, pode levar o produto a ter uma falha. 1.6 Erro É um item da informação ou estado de execução do produto de software inconsistente. 1.7 Falha É a situação encontrada em que o sistema desenvolvido viola suas especificações. TEMA 2 – DETALHANDO ITENS DA TERMINOLOGIA 2.1 Defeitos A principal causa encontrada nas ocorrências de defeitos é a tradução incorreta das informações. No projeto de desenvolvimento, quanto menor o tempo para esse defeito for revelado, menor também será o custo de correção e probabilidade da correção ocorrer de forma correta. A solução é introduzirmos pontos de verificação, validação e testes ao longo de todo o ciclo de desenvolvimento. 2.2 Teste É o processo de execução de um programa com o objetivo de revelar a presença de erros. Contribui para aumentar a confiança de que o software desempenha as funções especificadas. Deve-se ter um conjunto de passos ao qual seja possível alocar técnicas de projeto de casos de teste e estratégias de teste específicos durante o desenvolvimento. 2.3 Depuração 04 É uma situação não previsível ocorrida no teste. Depois de revelada a presença do erro, ele deve ser corrigido. O processo de depuração é a parte mais imprevisível do processo de teste. 2.4 Falha Incapacidade do software desenvolvido de realizar a função requisitada. 2.5 Erro Trata-se do estado de instabilidade. Veja, abaixo, a relação entre as questões de falhas em sistemas. O processo de teste deve ser revisto continuamente, a fim de ampliar sua atuação para possibilitar aos profissionais uma maior visibilidade e organização dos seus trabalhos, resultando em uma maior agilidade e controle operacional dos projetos de testes. Conhecendo-se o funcionamento interno de um produto, testes podem ser realizados para garantir que “todas as engrenagens”, ou seja, que a operação interna de um produto tenha um desempenho de acordo com as especificações e que os componentes internos foram adequadamente postos à prova. TEMA 3 – TÉCNICA ESTRUTURAL: CAIXA BRANCA É um método de projeto de testes que usa a estrutura de controle do projeto procedimental para derivar casos de teste. Baseia-se no exame dos detalhes procedimentais em que os caminhos do software são testados, porém não é viável testar todos os caminhos lógicos de um programa. Na Técnica de Caixa Branca, o engenheiro de software, por meio dos casos de teste, vai: Garantir que todos os caminhos lógicos, independentes do módulo, tenham sido exercitados pelo menos uma vez; Executar todas as decisões lógicas em seus lados verdadeiro e falso; 05 Executar todos os ciclos nos seus limites e dentro de seus intervalos operacionais; Executar as estruturas de dados internas. Nessa ideia, temos o Teste do Caminho Básico. Trata-se de uma técnica que vai permitir a definição de um conjunto-base de caminhos de testes a serem executados. Ele é baseado no fluxo de controle e no conceito da complexidade ciclomática. Antes, porém, vamos ver uma notação para representar o fluxo de controle. 3.1 Grafos Grafos mostram o fluxo de controle. O Nós vai representar um ou mais processos; as Arestas, o fluxo de controle do programa ou estrutura do programa. Figura 1 – Fluxo de controle A definição de regiões do grafo são áreas limitadas pelas arestas e nós. Nelas, podemos ter a seguinte notação: 06 Figura 2 – Regiões de grafo Exemplo: 3.2 Teste do caminho básico 07 Para criarmos um teste do caminho básico, precisamos executar as seguintes situações: Construir um grafo para o módulo do programa em teste; Fazer o cálculo do valor da complexidade ciclomática; Optar por um conjunto de caminhos básicos; Fazer a criação de um caso de teste para cada caminho básico; Executar todos os casos de testes. 3.2.1 Complexidade ciclomática É fundamentada na teoria dos grafos, fornecendo uma métrica de cálculo para testes muito interessante. Ela nos dá um limite de número de casos de testes que deveriam ser executados para que se garanta que cada comando/caminho de execução de um programa tenha sido passado ao menos uma vez. Isso é realmente útil para quando temos módulos com tendências maiores a erros. Ela pode ser calculada usando-se a seguinte fórmula: V(G) = E – N + 2, onde: E: número de ramos do grafo; N: número de nós do grafo. Ex.: Usando a figura abaixo, teríamos: V(G) = 17 arestas – 13 nós + 2 = 6. Portanto, a complexidade para o exemplo acima seria 6. Esse será o número de caminhos a serem seguidos pela estrutura do programa, conforme descrito abaixo: 08 Caminho 1: 1-2-10-11-13 Caminho 2: 1-2-10-12-13 Caminho 3: 1-2-3-10-11-13 Caminho 4: 1-2-3-4-5-8-9-2-... Caminho 5: 1-2-3-4-5-6-8-9-2-... Caminho 6: 1-2-3-4-5-6-7-8-9-2-... Nos caminhos 4, 5 e 6, as reticências indicam que se pode tomar qualquer caminho no restante da estrutura que não comprometerá o resultado do teste. Com isso, os testes devem ser realizados para que façam esses caminhos ao menos 1 vez. TEMA 4 – TÉCNICA FUNCIONAL: CAIXA-PRETA Primeiramente, usamos o particionamento de equivalências, técnica que se adequa aos testes com valores típicos de uma entrada em um programa. Os casos de teste são elaborados sabendo-se quais serão as entradas, de forma sistemática e direta. Para acharmos essas equivalências, siga estes passos: a. Definir as chamadas condições de entrada, qualquer intervalo de entradas válidas em um programa. Ex.: Faixa de valores 1 < CODIGO<99, vetores com X número de elementos, etc.; b. Definir as classes de equivalência, que podem ser válidas ou inválidas. São definidas pela condição de entrada. Ex: 1< CODIGO < 99 Classe válida : 1 <CODIGO< 99. Classes inválidas: CODIGO <= 1 e CODIGO >= 99; c. Para cada classe que for inválida, será criado um caso de teste. As classes declaradas válidas, os casos de teste serão gerados para atender a maior quantidade possível de entradas válidas. Exemplo: 09 Nessa técnica, podemos ter alguma dificuldade em quantificar os testes e acontecer de deixarmos partes essenciais críticas do sistema sem os devidos testes. Também podemos citar como uma dificuldade nessa técnica a questão da automatização dos testes. TEMA 5 – TEST DRIVEN DEVELOPMENT (TDD) Sobre os testes, temos uma metodologia chamada de ágil, que está crescendo no mercado em que os testes são vitais para o desenvolvimento. A Test Driven Development, ou simplesmente TDD, é um desenvolvimento guiado por testes. O primeiro livro sobre esse assunto foi escrito por Kent Beck. Trata-se de um método de desenvolvimento fácil de explicar, porém difícil de aprender, mas de retorno garantido. Essa forma de desenvolvimento deixa o código mais claro, os testes são documentações executáveis que garantem funcionalidades do domínio do problema. Nesse tipo de desenvolvimento, se algum teste parou de rodar, sabemos que algo deu errado. Isso trará economia de tempo e dinheiro em manutenção, e a escrita de testes ajuda na melhoria do design do código. Outras vantagens são: Com a utilização do método ganhando experiência, já no início da implementação de um método, o desenvolvedor poderá refletir sobre como fará para testá-lo; Ao iniciar mais cedo, os testes são feitos, aumentam as chances de que erros sejam encontrados na sua fase inicial de desenvolvimento, evitando que se espalhem pela aplicação, tornando-os mais simples de serem resolvidos. A base do TDD é a seguinte: os testes serão escritos antes do código. Ele é uma técnica para desenvolvimento de software formado por pequenas iterações para o desenvolvimento de uma nova funcionalidade, sempre iniciando pela construção do caso de teste para depois construir o código para fazer o teste passar e, finalmente, pela realização da refatoração do código visando melhorá-lo, incluindo as mudanças realizadas. O TDD vem da ideia de “test-first programming” do XP (Extreme Programming). Os passos da construção com TDD são os seguintes: a. Crie o teste; b. Compile-o e execute-o (com certeza não irá – vermelho); 010 c. Então, codifique o requisito e faça-o passá-lo pelo o teste (verde); d. Realize a refatoração do código para melhorá-lo. A metodologia TDD é conduzida por “testes do programador” ou testes unitários. É de se destacar que não se tratam dos testes de sistema nem os de homologação (feitos pelo usuário final). Siga estes princípios: 1. Construa testes isolados uns dos outros: um caso de teste não deve depender do sucesso de outro para funcionar. Deve ser possível executar um caso de testes isoladamente, sem executar nenhum outro; 2. Comece definindo uma “Test List”: de modo geral, para uma mesma classe ou método que será testado, existirão diferentes casos de teste. Devem-se listar todos primeiro; 3. Primeiro o teste: é chance de refletir sobre o projeto das classes do sistema e controlar o escopo. A codificação deve atender somente o necessário para o teste corrente; 4. Primeiro a assertiva: é necessário refletir sobre o que significará se o teste executar com sucesso antes de seguirmos adiante. 5. Dados para teste: para realizar o teste, procure não escolher números complexos caso eles não tenham algum significado para o teste. Seja simples. Não passe os mesmos valores para diferentes parâmetros. Ex.: Ao fazer o teste de um método Operacao (int x, int y), não o faça utilizando valores iguais Operacao (2,2). O método “Operacao” poderá inverter o “x” e o “y” fazendo o teste passar assim mesmo, dificultando sua análise. Procure usar informações do mundo real em seu sistema. 6. Dados com significado evidente: procurar codificar de forma explicativa (comentar), pois vale lembrar que estamos escrevendo testes para outras pessoas lerem, e não apenas para ser executados pelo computador. FINALIZANDO Qualquer conjunto de testes tem a missão de encontrar em um programa ou sistema o máximo de bugs possíveis utilizando o mínimo de esforço. Nessa aula, vimos como os testes são importantes e a existência de métodos e técnicas para que seja possível implementar um plano de testes que garanta a qualidade daquilo que se está entregando ao usuário. Os testes nunca finalizam. Mesmo após a implantação e, por consequente, seu uso pelo usuário, o sistema será 011 constantemente testado; nesse caso, pelo cliente. E ninguém deseja que ele encontre algum tipo de erro. 012 REFERÊNCIA PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. __MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(4).pdf ENGENHARIA DE SOFTWARE/EngSoft(5).pdf AULA 5 ENGENHARIA DE SOFTWARE Prof. Emerson Antonio Klisiewicz 02 CONVERSA INICIAL Nesta quinta aula, estudaremos a Qualidade de Software para o desenvolvimento de sistemas, que também fazem parte do processo de Engenharia de Software. CONTEXTUALIZANDO É também por meio da Engenharia de Software que objetivamos garantir uma qualidade do software, definindo e normatizando os processos durante o desenvolvimento dentro de um prazo condizente com a necessidade apresentada pelo usuário. TEMA 1 – CONCEITOS 1.1 Qualidade Trata-se de uma visão do desenvolvedor que se une à ideia de que o software sempre deve atender às necessidades do usuário. Para o usuário, qualidade é a ideia do valor, sua utilidade e o cumprimento de todos os requisitos por ele solicitados. 1.2 Funcionalidade Tratam-se dos atributos, das funções e propriedades particulares do software que vão satisfazer as necessidades impostas pelos requisitos do usuário. 1.3 Resumindo Figura 1 – Resumo dos conceitos 03 Leitura complementar Engenharia de Software – Uma abordagem profissional. 8.ª edição. Por Roger Pressman e Bruce Maxim. Capítulo 21. TEMA 2 – QUAL A NECESSIDADE DE SE MEDIR A QUALIDADE? É necessário ter um valor para comparação. Ao medir e realizar uma comparação do software com alguma informação (dado) é possível ter, desse modo, um indicador de qualidade. Mas, então, o que vamos medir? Nesse caso, teremos opções como o processo e o próprio produto desenvolvido. Nesse procedimento, teremos vários fatores que afetaram a qualidade e que podemos dividir em dois segmentos: os que podem ser medidos diretamente como tempo, custos e produção; e os que não podem ser medidos de forma direta, como questões de usabilidade e manutenção, que são muito subjetivos e difíceis de mensurar. A qualidade necessita ser medida de forma comparativa com padrões e também critérios que devem ser pré-definidos. Por exemplo: medir e comparar o software desenvolvido com alguma informação padrão e obter um indicador de qualidade. 2.1 Mas o que é necessário medir? Podemos decidir medir diversas situações dentro do ciclo de desenvolvimento do software, como o tempo e custo do processo, o desempenho do software e os resultados obtidos por ele. Poderemos também medir a produção da equipe e também quais os recursos que foram usados efetivamente no processo. Dessa forma, poderemos criar padrões, estimativas e com elas aplicar correções, sejam elas corretivas ou preventivas diante dos riscos encontrados. 2.2 Fatores de qualidade Vamos encontrar diversos fatores que afetarão a qualidade do software, como características de operação, capacidade em agregar mudanças, sua adaptação a novos contextos. Essas situações podem ser agrupadas nas seguintes categorias: revisão do software, operação do software e transição do software. 04 2.2.1 Revisão Dentro desse item, nós teremos três situações: a questão da manutenção, que visa verificar quanto o software foi desenvolvido, já prevendo futuras alterações; da flexibilidade, que mostrará quanto de esforço deveremos gastar para realizar qualquer alteração; e da testabilidade, que empregará testes para verificar se o software foi desenvolvido conforme suas especificações. 2.2.2 Operação Nesse quesito, atenderemos aos seguintes itens: corretagem, que atenderá a especificações e objetivos definidos pelo usuário; confiabilidade, que verificará se o software sempre executa do mesmo jeito e com a precisão exigida; eficiência, que trará a quantidade de recursos necessários para o programa executar; integridade, que verificará se o controle de acesso é controlado; e usabilidade, que traz o esforço para aprender a trabalhar com o software. 2.2.3 Transição Na transição, vemos questões como a portabilidade, que mede o esforço para transferir o programa a outro ambiente de produção, bem como a questão da reusabilidade, que demonstrará como usar o software ou parte dele em outras aplicações, e também a interoperabilidade, que verificará o esforço para fazer a união de um sistema a outro, integrando, assim, soluções. TEMA 3 – ELEMENTOS DE GARANTIA DE SOFTWARE Engloba preocupações e atividades que se concentram na gestão da qualidade do software. Dentre elas, podemos sintetizar as seguintes. 3.1 Padrões O IEEE, a ISSO e outras padronizações possuem grande quantidade de padrões e documentos que ajudam no gerenciamento da qualidade do software. 3.2 Revisões e auditorias Formalizará e controlará todas as solicitações de mudança no software tanto no desenvolvimento como após sua implantação e posterior manutenção. 05 3.3 Testes Detectarão possíveis falhas e erros no desenvolvimento e manutenção do software, mas somente isso não é o suficiente. 3.4 Coleta e análise de erros/defeitos Coleta é um conjunto de medidas técnicas e orientadas à administração das especificações do software. Dessa forma, com dados em mãos é possível compreender como os erros surgem e quais soluções dentro da engenharia de software podemos usar para sua eliminação. Leitura complementar Engenharia de Software – Uma abordagem profissional, 8.ª edição, por Roger Pressman e Bruce Maxim – capítulo 21, itens 1 e 2. TEMA 4 – SQA: PROCESSOS A garantia da qualidade de software (Software Quality Assurance – SQA) deve ser aplicada em todo o processo de engenharia de software. Avaliações, auditorias e revisões vão definir padrões para o projeto, procedimentos para a geração de relatórios de acompanhamento de erros e também a criação de uma documentação necessária que vai instruir a equipe com conclusões a respeito do projeto do software. Dentre elas, podemos sintetizar nos itens a seguir. 4.1 Revisões de software Métodos de validação de qualidade usados pela equipe de desenvolvimento do software. Eles filtrarão erros e inconsistências no processo de desenvolvimento, tendo como objetivos reportar melhorias no produto ou parte dele e tornar o trabalho técnico de desenvolvimento mais administrável. 4.1.1 Tipos de revisões Inspeções de projeto ou programa, que vão detectar erros nos requisitos, projeto ou código. Revisões de progresso, que informarão para os GPs do projeto o progresso geral do desenvolvimento (planejamento, custos e prazos). 06 Revisões de qualidade, que farão uma análise técnica do produto ou documentação para verificar se existem inconsistências entre a especificação e o projeto, entre o código e documentação e também assegurar se padrões de qualidade foram seguidos. 4.2 Revisão técnica formal Trata-se da principal atividade de um SQA, que tem por objetivos verificar se o software atende a todos os requisitos. Também visa garantir que o software está de acordo com padrões pré-definidos pelo usuário. Obter um software desenvolvido de forma uniforme e tornar os projetos de desenvolvimento mais administráveis também está entre os objetivos dessa técnica. Cada uma dessas revisões é conduzida na forma de uma reunião que segue os seguintes padrões: Restrições à reunião (duração de até 2h). Participação de 3 a 5 pessoas, com preparação antecipada. Foco: um produto ou um componente de software que se está desenvolvendo. Ao final da reunião, o objetivo será todos aceitarem ou rejeitarem, ou ainda, aceitarem temporariamente o que foi apresentado. Leitura complementar Engenharia de Software – Uma abordagem profissional. 8. ed. Por Roger Pressman e Bruce Maxim. Capítulo 21, item 3. TEMA 5 – NORMAS: NBR ISO Um sistema de garantia da qualidade pode ser definido como a estrutura organizacional com responsabilidades, procedimentos, processos e recursos para implementação da gestão (ANS, 87). O controle de qualidade e o uso dos padrões baseados em normas ISO estão influenciando a forma como a qualidade está sendo usada nas últimas décadas, mas historicamente o assunto é muito antigo. Em relatos existentes há mais de quatro mil anos, os egípcios já estabeleciam um padrão de medida de comprimento conhecido como cúbito, que correspondia ao comprimento do braço do faraó reinante. Era utilizado assim como a unidade de medida nas construções egípcias. Porém, havia um problema quando um novo faraó assumia o poder, pois, assim, a unidade de medida 07 também se modificava. Interessante também era a punição para quem não aceitava a mudança: a morte. A ISO 9000 descreve elementos de garantia da qualidade em termos gerais que podem ser aplicados a qualquer empresa, independentemente do tipo de produtos ou serviços oferecidos. A necessidade das organizações se tornarem competitivas passa a ser enfatizada como motivo para a adoção de sistemas que resultem na qualidade. A ISO tem como princípios: Descrever elementos de garantia em termos genéricos, que podem ser aplicados aos negócios (produto ou serviço). Ter um modelo de qualidade que define responsabilidades, crie procedimentos e processos, capacite recursos para realização de uma gestão da qualidade. A empresa, ao adotar essa norma, com certeza vai ganhar produtividade e credibilidade, aumentando sua competitividade no mercado, podendo ser uma diferenciação e, desse modo, possibilitar à empresa buscar novas oportunidades em um mercado global. A certificação é possível seguindo-se os passos: 1. Empresa contrata consultoria específica. 2. Empresa se qualifica para a auditoria de acreditação da ISO. 3. É feita uma avaliação da conformidade do sistema de garantia da qualidade e não se certifica o SOFTWARE e sim a capacidade de desenvolvimento. Geralmente certifica-se por área de atividade da empresa (não na totalidade). 4. Uma vez qualificada (auditoria de validade), a empresa recebe o certificado. 5. Começam as auditorias de vigilância – semestrais ou anuais. A ISO 9000 surge como alternativa para melhoria do processo de desenvolvimento das empresas, gerando produtos e serviços mais competitivos nos mercados nacional e internacional. A certificação ISO surge como um diferencial para que a empresa consiga atingir melhores patamares e oportunidades num mercado que hoje se apresenta na forma global. 5.1 NBR 13596 A seguir mostramos quais são as características das normas NBR 13596, que são uma versão brasileira da ISO 9126. 08 Quadro 1 – Características da norma NBR 13596 Quadro 2 – Mais características da norma NBR 13596 Mas como podemos aplicar as normas ISO/NBR? Para avaliar um software segundo uma norma, deve-se tentar atribuir valores (notas ou conceitos) a cada uma das subcaracterísticas. Porém, é difícil aplicar uma norma sem se estar familiarizado com todo o processo de avaliação de software. Guias para a avaliação da qualidade descrevem, detalhadamente todos os passos para se avaliar um software. 5.2 ISO 9000-3 Trata-se de um guia, criada em 1993, para a aplicação da ISO 9001 voltada ao desenvolvimento, fornecimento e manutenção de um software. Ela especifica 09 os requisitos mínimos para assegurar a qualidade de produtos de software e serviços, porém não define modelos ou impõe sistemas de qualidade. Ela agrupa as atividades do ciclo de vida em nove categorias: análise crítica do contrato, especificação dos requisitos do comprador, planejamento do desenvolvimento, planejamento da qualidade, projeto e implementação, ensaios e validação, aceitação, cópia, entrega e instalação, manutenção. Ela agrupa as atividades relacionadas a suporte em nove situações: gestão de configuração, controle de documentos, registros da qualidade, medição, regras, práticas e convenções, ferramentas e técnicas, aquisição, produto de software incluído e treinamento. A seguir, o fluxo do processo para a certificação. Figura 2 – Fluxo do processo para certificação A seguir, um quadro com mais algumas normas ISO e as suas características. 010 Quadro 3 – Normas ISO e características Leitura complementar Engenharia de Software – Uma abordagem profissional 8. ed. Por Roger Pressman e Bruce Maxim. Capítulo 21, item 8. FINALIZANDO No desenvolvimento de softwares, a qualidade no processo deve existir desde o início. Possuir aferições em cada fase, com métricas, fatores de qualidade e padrões é de vital importância para o sucesso. Buscar inconsistências ter um bom SQA – Software Quality Assurance, realizar avaliações, auditorias, revisões constantemente e ter atividades de controle das mudanças fará toda a diferença no sucesso do desenvolvimento. Num mundo tão competitivo em que estamos, ter uma boa documentação e qualidade no produto que se está entregando selecionará a empresa, que crescerá ou não no mercado de software. 011 REFERÊNCIAS PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016. __MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(5).pdf ENGENHARIA DE SOFTWARE/EngSoft(6).pdf AULA 6 ENGENHARIA DE SOFTWARE Prof. Emerson Antonio Klisiewicz 02 CONVERSA INICIAL Nesta aula 6, estudaremos o gerenciamento da configuração de software e sobre as questões envolvidas na segurança da informação. CONTEXTUALIZANDO Tanto a configuração de software que envolve questões críticas no desenvolvimento, por exemplo, o versionamento de aplicações, como as questões sobre segurança no tratamento das informações fornecidas e processadas pelos softwares são vitais termos o controle no mundo competitivo de desenvolvimento que temos hoje. TEMA 1 – GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE: PROBLEMAS 1.1 Problema dos dados compartilhados Figura 1 – Dados compartilhados Na situação anterior, o desenvolvedor A modifica um software que está compartilhado. Posteriormente, o desenvolvedor B realiza algumas alterações no mesmo software e, ao tentar compilá-lo, erros são apontados pelo compilador, mas nenhum deles ocorre na parte que B alterou, deixando o desenvolvedor B sem a menor ideia da causa do problema. Uma solução simples seria cada desenvolvedor trabalhar em uma cópia “local” do software. Isso resolve o problema dos softwares compartilhados, porém, cria um novo problema. 03 1.2 Problema da manutenção múltipla Figura 2 – Manutenção múltipla Ocorre quando cada desenvolvedor trabalha com uma cópia “local” do que seria o mesmo software. Isso dificultará a identificação das funcionalidades que foram implementadas e em quais versões, bem como quais erros foram corrigidos. Podemos evitá-lo por intermédio do uso de uma biblioteca central com o software. Nessa proposta, cada software é copiado para a biblioteca sempre que for alterado. Contudo, ainda não é o ideal. 1.3 Problema da atualização simultânea Figura 3 – Atualização simultânea Nesse caso, o desenvolvedor A encontra e faz a correção de um erro na sua versão do software. Depois de corrigido, o software modificado é copiado para a biblioteca central. O desenvolvedor B encontra-o e faz a correção do mesmo defeito na sua versão do software, por não saber que A já tinha feito, desperdiçando todo o trabalho de A. Em outra situação, o desenvolvedor A encontra e corrige um defeito em sua versão compartilhada. Uma vez corrigido, ele copia para a biblioteca central. 04 O desenvolvedor B encontra o software e corrige outro erro em sua versão do componente, sem saber do defeito corrigido por A. O desenvolvedor B copia sua versão do componente para a biblioteca central. Além do trabalho de A ser desperdiçado, a versão que está na biblioteca central continua apresentando erro, sendo que o desenvolvedor A pensa que o problema foi resolvido. Para resolver essa situação, precisamos ter um mecanismo de controle para gerenciar a entrada e saída das versões da biblioteca central. Leitura complementar Engenharia de Software: uma abordagem profissional. 8. Ed. Por Roger Pressman e Bruce Maxim. Capítulo 29. TEMA 2 – GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE: POR QUE USAR A aplicação do gerenciamento de configuração de software dentro das empresas oferece um ambiente de desenvolvimento de software estável, porque qualquer alteração sem controle de softwares torna todo o desenvolvimento caótico. O gerenciamento de configuração de software nos oferece uma “memória” da situação do desenvolvimento dos softwares em nossa empresa. Quando muitas pessoas estão trabalhando no mesmo projeto, esse gerenciamento vai coordenar o acesso às alterações a serem feitas nos softwares que estão sendo desenvolvidos. Dentre as tarefas que um gerenciamento de configuração possui, podemos citar os descritos a seguir. 05 Quadro 1 – Tarefas de um gerenciamento de configuração de software TEMA 3 – REPOSITÓRIO DOS ITENS DE CONFIGURAÇÃO Um repositório de itens de configuração é um local com controle de onde são armazenados os itens de configuração de software depois de liberados pelo desenvolvimento. Todos os itens de configuração devem ser identificados, analisados, corrigidos, aprovados e armazenados no repositório de itens de configuração, para posteriormente serem enviados para as áreas de produção. Todos os módulos de um repositório de itens de configuração só poderão ser alterados após uma solicitação de alteração formalmente aprovada pelo gerente de configuração. Isso é importante para que somente pessoas realmente autorizadas possam acessar o módulo. Essa também é uma forma para garantir o controle sobre cada um dos itens de configuração, evitando alguma inconsistência. 06 3.1 Check in/Check out Check in/check out é o método utilizado para trabalhar com itens de configuração que já estão no repositório, ou seja, trata-se de uma conferência na entrada e uma conferência na saída do software do repositório central. Quando for necessária a alteração em algum item de configuração do repositório, uma cópia do item é colocada numa área de trabalho do desenvolvedor (“check out”). Nessa área exclusiva, o desenvolvedor tem total liberdade de trabalho e poderá realizar as alterações necessárias no módulo. Veja a figura a seguir: Figura 4 – Check out Após o final das alterações no módulo, ele será revisado e recolocado no repositório (“check in”). Uma nova data de alteração será criada para o módulo (versão), de modo que uma nova configuração contendo o módulo alterado será formada e congelada no repositório. A seguir, essa situação: Figura 5 – Check in/check out 07 TEMA 4 – CONTROLE DE MUDANÇAS Durante o processo de desenvolvimento de software, mudanças descontroladas podem levar rapidamente o projeto ao caos. Assim, devemos instituir na organização um processo que combine procedimentos humanos e ferramentas automatizadas para proporcionar um mecanismo de controle das mudanças. O processo de controle de mudanças deve ser implementado depois que temos as datas em que serão implantadas as modificações realizadas nos módulos. A seguir, um exemplo para ilustrar um processo de controle de mudanças que pode ser implementado. Figura 5 – Exemplo: organograma de processo de controle de mudanças Os procedimentos de controle das mudanças asseguram que as mudanças em um software sejam feitas de modo controlado, permitindo-se prever o efeito delas em todo o sistema. Procedimentos formais de organização e de controle das mudanças permitem que os pedidos de alteração possam ser considerados em conjunto com outros pedidos e isso não afete o ambiente produtivo dos sistemas. Também permite a organização e controle das mudanças de pedidos incompatíveis entre si ou que possam ser atribuídas prioridades aos pedidos e, de acordo com essas prioridades, possam ser gerados cronogramas. 08 4.1 Ferramentas de GCS Existem algumas ferramentas de software que podem auxiliar as atividades de gerenciamento de configuração de software. Exemplos de ferramentas: CVS (Concurrent Versions System) : <http://www.cvshome.org/>; RCS (Revision Control System): <http://www.gnu.org/software/rcs/rcs.html>; SCCS (Source Code Control System): <http://www.cvshome.org/cyclic/cyclicpages/sccs.html>; Source Forge (Web Pages Versions Management): <http://versionweb.sourceforge.net/>. Leitura complementar Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger Pressman e Bruce Maxim. Capítulo 29. TEMA 5 – SEGURANÇA DA INFORMAÇÃO Segurança da Informação (SI) é a proteção de sistemas de informação contra desastres, erros e manipulação de modo a minimizar a probabilidade e impacto de incidentes. Se divide em duas categorias: Ameaças: É a intenção da parte de alguém em causar dano a um indivíduo/organização. Nesse item, podemos incluir sabotagem de software ou hardware, roubo de informações, ataques a infraestrutura, ataques de hackers, incêndio e inundação. Nas ameaças, temos ações em potenciais que seguem o caminho de menor resistência, ou seja, mais vulnerável. Nesse caso, o risco é medido por meio da probabilidade de que uma ameaça pode acontecer e o dano que pode ser gerado à pessoa/empresa. Vulnerabilidade: Aqui é a deficiência na infraestrutura e organização que expõem riscos a eventos imprevistos/indesejáveis. Isso pode ocorrer por má configuração do sistema operacional, sistema de banco de dados com defeito, falha em um programa de acesso a dados, firewall desatualizado e falta de um nobreak. Na prevenção dentro de SI, temos as seguintes situações. 09 5.1 Confidencialidade É a garantia de que a informação é acessível somente por pessoas autorizadas para não acontecer a divulgação intencional (ou não) de informações reservadas. Questões de confidencialidade surgem porque processos e informação sensíveis do negócio só devem ser divulgados para pessoal/programas autorizados. Para isso, é imprescindível um controle de acesso. 5.2 Integridade Trata-se da garantia da exatidão e completude da informação e dos métodos de processamento da informação. As informações não devem ser modificadas por pessoas/processos desautorizados. As informações também não devem ser inconsistentes e o sistema deve garantir que elas são precisas e completas. 5.3 Disponibilidade Nesse item, temos a garantia de que usuários autorizados obtenham acesso à informação e aos ativos correspondentes sempre que necessário. A informação e os serviços do negócio devem estar disponíveis sempre que forem solicitados. Para isso, existe a necessidade de controles para garantir confiabilidade dos serviços informatizados. 5.4 Classificação dos riscos 5.4.1 Financeiros São os riscos envolvidos no relacionamento entre uma organização e o seu ativo. Nessa situação, temos o indivíduo ou a organização, que estão expostos a riscos, ativos ou receitas, cuja destruição ou perda poderá causar prejuízo financeiro ou uma ameaça que possa causar algum tipo de perda à empresa. 5.4.2 Não financeiros São os riscos representados por perdas não passíveis de mensuração financeira. Por exemplo, uma inundação em que milhões de acres de fazendas 010 foram destruídas, causando bilhões de dólares em perdas financeiras para os proprietários. Não há como mensurar as perdas financeiras resultantes da destruição de fauna e flora selvagem. 5.5 Exemplos de falta de segurança 5.6 Alguns cuidados que devemos ter Utilizar senhas distintas e seguras para cada site ou serviço; Não instalar softwares de fontes duvidosas; Manter seus sistemas sempre atualizados, incluindo antivírus; Evitar conectar pendrives e outros meios de armazenamento de terceiros; Não acessar sites de origem duvidosa; Proteger seus arquivos pessoais em HDs, pendrives e outros dispositivos de armazenamento usando soluções que impeçam que seus arquivos caiam em mãos erradas, mesmo que o dispositivo eletrônico seja perdido ou mesmo roubado; Não clicar em links suspeitos como aqueles recebidos por e-mail ou vistos em sites como os de redes sociais; 011 Não salvar senhas de acesso em navegadores; Ter controle de acesso aos sistemas; Ter logs para saber quem acessou o sistema e o porquê; Trocas automáticas de senha de tempos em tempos. Ter controle de acesso aos locais de desenvolvimento. Leitura complementar Engenharia de Software: uma abordagem profissional. 8. ed. Por Roger Pressman e Bruce Maxim. Capítulo 27. FINALIZANDO Os computadores são utilizados para realizar inúmeras tarefas, tais como transações financeiras, sejam elas bancárias ou mesmo compra de produtos e serviços para comunicação, por exemplo; por meio de e-mails e redes sociais também armazenamento de dados, sejam eles pessoais ou comerciais, etc. Muitos se perguntam o porquê de alguém tentar acessar os nossos computadores e sistemas. Sim há muitos motivos: utilizar seu computador em alguma atividade ilícita, para esconder a real identidade e localização do invasor, utilizar seu computador para lançar ataques contra outros computadores, utilizar seu disco rígido como repositório de dados, furtar dados do seu computador. Só por isso vemos o quanto é importante a questão da segurança da informação e como devemos trabalhar para implementá-la. Uma das formas de fazê-la também é termos um consistente sistema de configuração de software em que qualquer mudança seja bem implementada e segura dentro do contexto em que ela foi solicitada. 012 REFERÊNCIAS PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: McGraw-Hill, 2016. __MACOSX/ENGENHARIA DE SOFTWARE/._EngSoft(6).pdf ENGENHARIA DE SOFTWARE/EngSoft(1).pdf AULA 1 ENGENHARIA DE SOFTWARE Prof. Emerson Antonio Klisiewicz 02 CONVERSA INICIAL Nessa aula 1, estudaremos sobre os modelos clássicos de desenvolvimento de sistemas e a introdução à Engenharia de Software. CONTEXTUALIZANDO O que são softwares? “Software”, segundo o Dicionário Michaelis, consiste em “qualquer programa ou grupo de programas que instrui o hardware sobre a maneira como ele deve executar uma tarefa, inclusive sistemas operacionais, processadores de texto e programas de aplicação.” (Software, 2017). O que são Sistemas? Observe as frases: O sistema telefônico no Brasil foi implantado em 1877. O sistema de coleta de lixo funciona bem. O sistema de avaliação é rigoroso para os professores. O sistema circulatório de Tadeu está comprometido. O sistema de vendas em seu relatório mostrou uma desaceleração no mercado. Considerando as afirmações acima, podemos definir que os sistemas têm sempre o seu objetivo, logo, o objetivo declarado de um sistema é, a priori, a razão de sua existência. Hoje, qualquer país, seja desenvolvido ou não, depende de softwares. Precisamos, portanto, desenvolver sistemas confiáveis, com um desenvolvimento que se dê de forma econômica e em um curto espaço de tempo. Aí fica uma pergunta: “Existe uma diferença entre ser um artista e um engenheiro”? TEMA 1 – SOFTWARES Instruções: quando executadas, produzem a função e o desempenho desejados. 03 Estruturas de dados: possibilitam que os programas manipulem adequadamente a informação. Documentos: descrevem a operação e o uso dos programas. 1.1 Características do Software a. Desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico. b. Não se desgasta, mas se deteriora. c. A maioria é feita sob medida. 1.2 Aplicações do software a. Básico: programas escritos para dar apoio a outros programas. b. De tempo real: software que monitora, analisa e controla eventos do mundo real. c. Comercial: sistemas de operações comerciais e tomadas de decisões administrativas. d. Científico: caracterizado por algoritmos de processamento de números. 1.3 Evolução do software (1950 – 1965) O hardware sofreu contínuas mudanças. O software arte "secundária" para poucos métodos. O hardware era de propósito geral. O software específico para cada aplicação. Sem documentação. (1965 – 1975) Multiprogramação e sistemas multiusuários. Sistemas tempo real. Primeira geração de SGBD’s. Bibliotecas de Software. Cresce o número de sistemas baseado em computador. Manutenção quase impossível. 04 TEMA 2 – CRISE DE SOFTWARE Conjunto de problemas encontrados no desenvolvimento de software. 1. As estimativas de prazo e de custo frequentemente são imprecisas. 2. A produtividade das pessoas da área de software não acompanha a demanda por seus serviços. 3. A qualidade de software, às vezes, não é adequada. 4. O software existente é muito difícil de manter. Diante desse cenário, as seguintes situações acabaram acontecendo: estimativas de prazo e de custo ; produtividade das pessoas ; qualidade de software ; software difícil de manter . 2.1 Problemas associados à Crise de Software 2.1.1 Próprio caráter do software Podemos dizer que Software é a parte lógica do computador. Por consequência, determinaremos o seu sucesso pela medição da qualidade de apenas uma entidade. O software não sofrerá, como algo físico, um desgaste com o passar do tempo, mas, certamente, será corroído pelo tempo, necessitando de alterações (manutenções). 2.1.2 Falhas das pessoas responsáveis pelo desenvolvimento do software Gerentes sem conhecimento ou nulas experiências em softwares. Profissionais da área que não recebem novos treinamentos ou especializações técnicas de desenvolvimento. Também podemos encontrar, dentro das empresas, grande resistência na implementação de mudanças. 2.1.3 Mitos do software Propagaram desinformação e confusão. 05 Lenda: Em nossa empresa, possuímos um manual com todos os padrões para desenvolvimento de um software. Minha equipe terá tudo o que é necessário em termos de conhecimento? Verdade: Esse material é usado pela equipe? Todos os profissionais têm conhecimento da sua existência? Nele já estão contidas as formas modernas de desenvolvimento? O material está completo? Lenda: Minha equipe usa ferramentas de última geração para o desenvolvimento dos sistemas. Recentemente, também adquirimos novas máquinas para o desenvolvimento. Verdade: É necessário possuir mais que apenas novos computadores para produzir software com qualidade. Todo o conhecimento, aqui também, deve estar incluso. Lenda: Como nosso projeto de desenvolvimento de software está atrasado,
Compartilhar