![Análise e Desenvolvimento de Sistemas - Em Foco [Uniasselvi]](https://files.passeidireto.com/Thumbnail/0a610d77-f68b-4797-9b4a-a5fc94bc9bc3/105/1.jpg)
Prévia do material em texto
Fundamentos Engenharia de Software
UNIDADE 01
Modelos de Processos de desenvolvimento de Software
Esta Unidade tem início com uma breve introdução dos principais conceitos que envolvem a engenharia de software. Na sequência, apresenta e discute os modelos de processo de desenvolvimento de software. Sobre os modelos, será apresentada a sua evolução, funcionamento e as situações mais propícias de aplicação. Basicamente, os modelos de processos de desenvolvimento de software são divididos prescritivos e ágeis. Os prescritivos foram os primeiros modelos aplicados no desenvolvimento de software e tinham como característica principal determinar de forma mais rígida como as atividades deveriam ser realizadas. Com a evolução e a identificação das deficiências dos modelos prescritivos, surgiram os modelos/métodos ágeis, que trouxeram mais flexibilidade em como as atividades são organizadas para o desenvolvimento de um produto de software.
Fundamentos da engenharia de software
Durante o processo de desenvolvimento do software, as equipes buscam atingir objetivos que são cruciais para o sucesso do projeto. Eles normalmente são: desenvolver o produto correto, ou seja, que resolva o problema do cliente; desenvolver de forma rápida, no menor tempo possível; desenvolver um produto barato, portanto, com o menor custo possível, e assim tornar-se competitivo. No entanto, tais objetivos somente serão alcançados com a aplicação dos conceitos da engenharia de software.
O software hoje é onipresente, também chamado de ubíquo. Ou seja, ele está presente em todas as atividades diárias (profissionais ou pessoais) e, muitas vezes, nem percebemos a sua existência. O seu uso já foi incorporado como algo natural em nossas vidas. Porém, esta presença em tantos ambientes distintos trouxe um ambiente de desenvolvimento muito mais complexo do que há décadas.
Ambientes mais complexos demandam tecnologias, processos e composições de equipes mais complexas também. O trabalho entre pessoas distribuídas geograficamente é uma realidade comum no desenvolvimento de software. Portanto, cada vez mais, precisamos dos métodos, dos processos e das ferramentas propostos pela engenharia de software para entregar um produto de software com qualidade.
Mas o que é qualidade de software?
Há diversas definições e pontos de vistas distintos relacionados a este conceito. Uma dessas definições diz:
Uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam (PRESSMAN, 2016)
A base para a engenharia de software é a camada de processos. O processo de engenharia de software é a liga que mantém as camadas de tecnologias coesas e possibilita o desenvolvimento de software com qualidade. Assim, as palavras-chave na engenharia de software são: qualidade e processos, ambas estão intrinsicamente relacionadas.
Na literatura, encontramos várias definições para a área de engenharia de software. Uma das definições mais claras e objetiva expõe que a
engenharia de software é o processo de estudar, criar e otimizar os processos de trabalhos para os desenvolvedores de software” (WAZLAWICK, 2019)
Áreas do conhecimento
O SWEBOK (guia de referência sobre conhecimentos de engenharia de software), versão 2013, classifica a engenharia de software em 15 áreas do conhecimento.
1. Requisitos de software.
2. Projeto de software.
3. Construção de software.
4. Teste de software.
5. Manutenção de software.
6. Gerência de configuração de software.
7. Gerência da engenharia de software.
8. Processos de engenharia de software.
9. Ferramentas e métodos da engenharia de software.
10. Qualidade de software.
11. Práticas profissionais em engenharia de software.
12. Economia da engenharia de software.
13. Fundamentos de computação.
14. Fundamentos de matemática.
15. Fundamentos de engenharia.
Por se tratar de um grande conjunto de áreas, os assuntos tratados nesta disciplina estão mais relacionados às seguintes áreas: processos de engenharia de software, gerência da engenharia de software, teste de software e qualidade de software. Os demais assuntos são tratados de forma distribuída, em outras disciplinas.
A seguir, serão apresentados alguns dos modelos de processo de desenvolvimento de software mais populares das últimas décadas na indústria do desenvolvimento.
Modelos de processos de desenvolvimento de software
Conceitos-chave
Antes de discutirmos a respeito dos modelos de processo de desenvolvimento de software, é importante entendermos conceitos-chave, tais como o ciclo de vida e de desenvolvimento do software.
O ciclo de vida de um software é semelhante ao ciclo de vida que encontramos na natureza. Ele representa o conjunto de transformações que certos indivíduos de uma espécie podem passar. O software também passa por um conjunto de transformações, o que é chamado de ciclo de vida do software. Independentemente do seu tamanho e da sua complexidade, o software sempre terá o ciclo de vida ilustrado a seguir, na Figura 1.
Figura 1: Ciclo de vida do software
Representação das principais etapas (transformações) do software ao longo da sua existência. Fonte: Autor (2021).
Ou seja, todo projeto de software tem início com o seu estudo de viabilidade. Sendo viável, parte-se para o desenvolvimento, os produtos acabados são implantados, ao longo do tempo ocorrem manutenções neles, até que um dia são descontinuados. Muitas vezes, a descontinuação ocorre pela necessidade de atualização para uma nova tecnologia.
No entanto, antes de avançarmos, é importante entendermos outro conceito-chave: ciclo de desenvolvimento do software. No desenvolvimento do software, cada projeto pode estabelecer um conjunto de atividades e a sua sequência, o que chamamos de processo. Processo é um conjunto de atividades, ações e tarefas realizadas na criação de algum produto de trabalho. Com isso, cada projeto pode ter um processo diferente, de acordo com o seu contexto.
Aqui, é importante chamarmos a atenção para a diferença entre estes dois conceitos: ciclo de vida do software e ciclo de desenvolvimento do software. O ciclo de vida do software é sempre o mesmo, mas o ciclo de desenvolvimento do software pode mudar para cada projeto, dependendo das características e do seu contexto.
Modelos de processos de desenvolvimento
Há várias maneiras de organizar um processo de desenvolvimento de software para evitar o caos. Portanto, conheceremos alguns dos principais modelos de processos propostos e aplicados no mercado.
É importante ressaltar que, independentemente do tamanho e da complexidade de um projeto de software, todos comportarão minimamente as seguintes atividades de desenvolvimento:
· Especificação de requisitos (entender o negócio e as necessidades do cliente).
· Análise e projeto (planejar e projetar o software).
· Construção (implementar o software).
· Testes (testar o software).
· Implantação (implantar o software desenvolvido).
Os modelos de processo normalmente ajudam as equipes a organizarem as suas atividades de maneira a atingir o sucesso no desenvolvimento do software. O modelo mais adequado é aquele que alinha as características do projeto com as características do modelo. E, com certeza, adotar um modelo de processo de software, seja qual for, é muito melhor do que não ter nenhum.
Por volta dos anos 70, surgiram modelos de processo de software mais tradicionais, conhecidos como prescritivos, que contribuíram para trazer ordem ao caos existente no desenvolvimento de software. No entanto, tais modelos apresentavam limitações. Com o objetivo de suprir essas limitações, foram propostos os modelos conhecidos por ágeis.
Na sequência, será exposto o conceito de cada um desses modelos (prescritivos e ágeis) e identificar as situações favoráveis e os pontos de atenção de cada modelo.
Modelos prescritivos
Os modelos prescritivos se baseiam em uma descrição de como as atividades devem ser feitas. São diversos os modelos propostos e que evoluíram com este objetivo. Nesta Unidade, conheceremose assim obter o TPA. O TPA é obtido por meio da aplicação da seguinte fórmula:
TPA = TPNA x FCT x FCA
Para demonstrar a aplicação desta fórmula, vamos utilizar como exemplo, uma situação em que foram obtidos os seguintes dados:
· TPNA = 132.
· FCT = 0,795.
· FCA = 0,755.
Aplicando a fórmula, temos o seguinte resultado:
TPA = 132 x 0,795 x 0,755.
TPA = 79,23.
Observe que após a aplicação dos dois fatores de ajuste, houve uma redução do TPA (79,23 pontos) em relação TPNA (132 pontos). Isso porque, no exemplo utilizado, os fatores técnicos não indicavam grandes complexidades e os fatores de ambientes indicavam situações favoráveis para o projeto.
Exemplo
Exemplo de aplicação da técnica obtendo custo e prazo
Agora que já foi visto, em detalhes, os passos necessários para a aplicação da técnica de estimativa por Pontos de Caso de Uso, será visto um exemplo completo da aplicação da técnica estendendo o cálculo do esforço em um projeto.
As Tabelas 7 e 8 apresentam um contexto com os atores e casos de uso identificados para cada tipo. Após a aplicação dos pesos, e a somatória da coluna resultado, é possível chegar a TPNAA (14 pontos) e TPNAC (75) pontos.
Tabela 7: Exemplo de um contexto com atores identificados
Tipo de ator
Peso
Qtd. de atores
Resultado
Simples
1
2
2
Médio
2
1
2
Complexo
3
4
12
TPNAA
16
A tabela apresenta um exemplo com o preenchimento dos atores identificados, a partir do qual é possível calcular TPNAA. Fonte: O autor (2021).
Tabela 8: Exemplo de um contexto com casos de usos identificados
Tipo de caso de uso
Peso
Qtd. de casos de uso
Resultado
Simples
5
3
15
Médio
10
3
30
Complexo
15
2
30
TPNAC
75
A tabela apresenta um exemplo com o preenchimento dos casos de usos identificados, a partir do qual é possível calcular TPNAC. Fonte: O autor (2021).
Somando TPNAA (14 pontos) com TPNAC (75 pontos), obtemos TPNA (89 pontos).
Após obtermos o TPNA, é necessário realizar os ajustes por meio do cálculo dos fatores técnicos e de ambiente.
Supondo que os valores obtidos para FCT = 1,3 e FCA = 1,7, chegamos ao TPA.
TPA = TPNA x FCT x FCA.
TPA = 89 x 1,3 x 1, 7.
TPA = 196,69.
Neste exemplo, os valores altos para FCT e FCA representam um contexto de complexidades técnicas essenciais e de ambiente desfavoráveis. Portanto, a contagem inicial é ajustada para mais do que o dobro.
Até este ponto, temos o total de pontos ajustados do contexto que está sendo analisado, TPA = 196,69 pontos.
O próximo passo seria utilizar esta informação para calcular o custo e o prazo para o desenvolvimento de uma aplicação.
O criador da estimativa, Karner, sugere a utilização de 20 pessoas-hora/TPA, assim, o exemplo analisado geraria 3.933,8 horas de trabalho. O custo do projeto irá variar de acordo com o valor médio da hora, enquanto o tempo de desenvolvimento irá variar de acordo com as pessoas alocadas na equipe. Se o valor médio da hora fosse R$ 50,00, o custo total do projeto seria: R$ 196.690,00.
Com relação ao prazo, se a equipe fosse composta por quatro pessoas, em que cada uma trabalha em média 160 horas no mês, teríamos 640 horas de trabalho mês. Considerando que o projeto todo foi estimado em 3.933,8 horas e o total de horas de trabalho disponível é 640, logo, levaria aproximadamente (3.933,8/640), seis meses para ser concluído.
Na videoaula abaixo é realizado um fechamento do tema estimativas de esforço, relembrando as técnicas de estimativas aprendidas nas unidades. O objetivo é ressaltar que as técnicas não são as únicas; existem outras técnicas formais e informais que podem ser utilizadas individualmente ou de forma combinada entre elas. A apresentação destaca que mais importante do que conhecer as técnicas, é saber quais e como aplicá-las de acordo com o contexto.
Conclusão
Nesta Unidade, aprendemos como aplicar a técnica de estimativa pontos por caso de uso. Para a aplicação da técnica, é necessário seguir passos em que são definidos critérios e pesos para os elementos a serem identificados. Os primeiros passos orientam sobre o cálculo de pontos não ajustados, em que aspectos técnicos e de ambientes ainda não são considerados. Nos passos seguintes, a técnica propõe um conjunto de fatores que possibilitam ajustar a pontuação de acordo com complexidade do contexto. Ao aplicar os fatores de ajuste, o total de pontos não ajustados podem ser reduzidos ou aumentados. Por fim, com os ajustes realizados, é possível calcular o custo e o prazo (tempo de desenvolvimento) de um projeto de software. A Unidade é finalizada com um exemplo completo, em que é possível observar a aplicação de todos os passos da técnica até o cálculo do custo e do tempo de desenvolvimento de um projeto de software.
Referências bibliográficas
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. 2. ed. Rio de Janeiro: Elsevier, 2019.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 05
Testes de software
Esta Unidade apresenta os conceitos fundamentais relacionados à atividade de testes de software, que é fundamental para garantir a qualidade do software. A Unidade tem início com uma breve introdução a respeito da importância de testes, seus conceitos e desafios. Posteriormente, os testes são apresentados sob perspectivas diferentes: níveis e tipos. Na perspectiva de níveis, será visto que teste é uma atividade a ser realizada em todos os níveis de desenvolvimento, desde o menor componente implementado (método, função etc.) até a entrega de um sistema com inúmeros componentes integrados para o usuário validar. Na perspectiva de tipos, será abordado que tanto requisitos funcionais quanto não funcionais devem ser testados. Por fim, a Unidade é finalizada com a apresentação de duas técnicas mais utilizadas para o teste de funcionalidades do sistema.
Introdução ao teste de software
Antes de falarmos diretamente sobre a atividade de testes de software, é importante abordar a necessidade da garantia da qualidade de produtos ou serviços.
A qualidade é garantida por meio de um conjunto sistemático e planejado de atividades, necessárias para proporcionar a confiança adequada de que produtos e serviços estarão em conformidade com requisitos especificados e atenderão às necessidades do usuário.
O teste é uma atividade fundamental para garantir a qualidade de qualquer produto ou serviço. Isso se aplica a produtos e serviços de qualquer natureza, como para um novo carro, brinquedo, serviço de hotel, alimento, serviço de beleza etc. Portanto, ao desenvolver um novo produto de software, é fundamental executar atividades que garantam a qualidade deste produto, ou seja, que ele atenda plenamente às necessidades do usuário.
Uma das atividades essenciais para a garantia da qualidade de software é o teste de software.
Quando falamos em testes de software, há quatro questões fundamentais que precisamos ter em mente:
1) Por que testar?
São vários os motivos para se testar um software, dentre eles: garantir a qualidade software, reduzir o retrabalho e manter uma boa reputação da empresa.
2) O que testar?
Requisitos funcionais e não funcionais. Da menor unidade de software (um método, uma função etc.) ao produto final (integração entre componentes, sistemas etc.).
3) Quando testar?
Ao longo de todo o ciclo de desenvolvimento do software (desde o levantamento dos requisitos à entrega das funcionalidades).
4) Quem testa?
Todos os participantes de um projeto de desenvolvimento de software (desenvolvedores, testers, usuários etc.), em algum momento, precisam estar envolvidos à atividade de teste de software (quanto mais pessoas de perfis diferentes testarem, melhor).
Conceitos fundamentais
Antes de avançarmoscom o entendimento da atividade de teste, é importante definirmos alguns termos, que podem ser considerados sinônimos, porém, têm significados distintos.
O teste tem como objetivo analisar o comportamento do software por meio de sua execução, com a intenção específica de encontrar defeitos, erros ou falhas, antes da entrega ao usuário final.
· Defeito
· Erro
· Falha
Existem falhas que são provocadas por um defeito no software, mas outras que podem ser provocadas por problemas tecnológicos (segurança, conexão, leitura de dados etc.). Portanto, nem todas as falhas são provocadas por defeitos.
Assim, concluímos que o teste de software se ocupa principalmente em identificar falhas provocadas por defeitos para que os defeitos sejam corrigidos.
Desafios do teste de software
A tarefa de testar software, porém, não é simples. Algumas vezes, pode ser mais fácil produzir o software do que elaborar bons casos de testes. Desta forma, muita sistematização e critérios são necessários para que a atividade de testes deixe de ser uma tarefa aleatória e ingênua para se tornar uma atividade de engenharia com resultados efetivos.
A maioria dos sistemas de médio e grande porte pode conter defeitos ocultos, pois a quantidade de testes necessária para garantir que estejam livres de defeitos pode ser impraticável. Assim, a área de testes de software ocupa-se em definir conjuntos finitos e possíveis de testes que mesmo não garantindo que o software esteja livre de defeitos, consigam localizar os mais prováveis permitindo a sua correção.
Diante de todos os processos, modelos e ferramentas que a engenharia do software disponibiliza para obter qualidade dos produtos desenvolvidos, ainda assim, pode ocorrer incidência de erros e falhas. As técnicas de teste têm se mostrado importantes recursos para minimizá-los.
Para exemplificar o quanto a tarefa de testar um software pode não ser tão simples, vamos realizar um exercício.
Reflexão
Analise quantos casos de testes são necessários para garantir que o seguinte programa tenha sido construído com sucesso.
Cenário
· O programa lê três valores inteiros.
· Estes três valores devem representar o comprimento dos lados de um triângulo.
· O programa apresenta uma mensagem, dizendo se o triângulo é escaleno, isósceles ou equilátero.
Regras
· O comprimento de um lado do triângulo é sempre menor do que a soma dos outros dois lados.
· Triangulo equilátero: todos os lados iguais.
· Triângulo isósceles: dois lados iguais.
· Triângulo escaleno: todos os lados diferentes.
Resultado
Você tem um caso de que avalia:
1. Se é um triângulo? Testes com 2, 5, 10 não são um triângulo escaleno, na verdade, não formam um triângulo.
2. Os testes do caso 1 consideram a permuta dos três valores? (ex.: 2, 5, 10; 2, 10, 5; 10; 2, 5)
3. Um triângulo equilátero?
4. Um triângulo isóscele? Tentando três permutas de dois lados iguais? (ex.: 3, 3, 4; 3, 4, 3; 4, 3, 3)
5. Um triângulo equilátero?
6. Um dos lados tem valor zero?
7. Um dos lados tem valor negativo?
8. A entrada válida para os três valores inteiros?
9. Etc.
Perceba a quantidade de casos de testes que pode ser necessária para obter 100% de cobertura da execução do código, de forma a identificar erros e, consequentemente, a correção de defeitos.
Níveis de testes
A atividade de testes deve ser realizada em fases distintas do desenvolvimento do software e, portanto, pode ser aplicada em níveis distintos. A seguir, conheça alguns deles!
Teste de unidade
Os testes de unidade são os mais básicos e consistem em verificar se um componente individual foi implementado corretamente. Estes componentes podem ser um método, uma classe ou um pacote de funções de tamanho pequeno a moderado. Geralmente, esse teste é realizado pelo próprio programador, inclusive na técnica de desenvolvimento orientado a testes (TDD), recomenda-se que o programador antes de desenvolver uma unidade de software, desenvolva os casos de testes com objetivo de automatização.
Para o teste de unidade, podem ser aplicadas as técnicas de testes funcionais (caixa-preta) e de teste estruturais (caixa-branca). No teste funcional, garante-se que as saídas estão de acordo com as especificações. Já no teste estrutural, procura-se garantir que todos os comandos e as decisões dos componentes implementados tenham sido executados com objetivo de encontrar falhas. Estas técnicas serão detalhadas nas próximas Unidades de Estudo desta disciplina.
Teste de integração
Os testes de integração têm o objetivo de identificar falhas associadas às interfaces entre os componentes (método, classe, pacote etc.), quando esses são integrados.
Um grande desafio dos testes de integração é o fato de que parte dos componentes individuais que precisam ser integrados, muitas vezes não foram codificados ou testados. Nestes casos, as interfaces faltantes precisam ser suprimidas por implementações incompletas ou simplistas desenvolvidas de forma provisória para possibilitar o teste de integração de parte dos componentes.
Para contornar estas situações, pode-se aplicar estratégias distintas, com pontos favoráveis e desfavoráveis.
· Integração big bag
· Integração bottom-up
· Integração top-down
· Integração incremental
As estratégias descritas têm como objetivo realizar testes de integração de forma mais organizada e assertiva. Embora os componentes, depois do teste de unidade, possam funcionar corretamente de forma isolada, o teste de integração é necessário, pois quando colocados juntos, várias situações inesperadas podem acontecer. E quando as integrações ocorrem de forma desordenada ou ainda com implementações provisórias para possibilitar a integração, diversas falhas podem ocorrer mesmo após os testes de integração.
Teste de sistema
Depois de realizar todas as integrações, teremos o sistema completo. Podemos, assim, simular o ambiente de uso final e realizar testes que apontarão falhas em aspectos gerais do sistema.
O teste de sistema visa a verificar se a versão corrente do sistema permite executar um fluxo de um processo ou de um caso de uso completo sobre o ponto de vista do usuário. Neste nível de teste, se utiliza a técnica funcional, em que não se avalia a estrutura interna da implementação (código), mas o comportamento do sistema em relação a sua especificação.
Exemplos de fluxos que são testados neste nível:
· Comprar um livro em uma livraria virtual.
· Realizar a transferência bancária por meio do internet banking.
· Registrar matrícula de um estudante em uma disciplina.
· Pesquisar imóveis à venda em um portal.
Em suma, temos a seguinte sequência dos testes:
· Primeiro, são testados os componentes individualmente pelo teste de unidade, a fim de verificar falhas específicas nas funções de cada componente.
· Em seguida, são agrupados os componentes para verificar erros na interface entre eles e medir seus níveis de desempenho e confiabilidade. Isso é feito por grupos, não considerando o sistema completo.
· Por fim, após testar todos os grupos de integração, é realizado o teste de sistema.
Teste de aceitação
Os testes de aceitação, também conhecidos como homologação, são semelhantes ao teste de sistema; no entanto, deve ser realizado pelo usuário final ou cliente, e não pela equipe de desenvolvimento.
Neste nível de teste, o objetivo principal é validar se os requisitos do software foram desenvolvidos de acordo com o esperado. Neste momento, o usuário aprova a versão ou solicita modificações.
Apesar de todos os testes internos (unidade, integração e sistema), é possível que ainda existam falhas no sistema tanto de codificação quanto de entendimento dos requisitos. O desejável é que neste nível dos testes, o usuário final receba uma aplicação livre de falhas de codificação e que ele possa se concentrar na validação dos requisitos implementados.
Teste de regressão
O teste de regressão é executado sempre em um sistema em operação como uma manutenção. Ou seja, ele é a reaplicação dos testes nas novas versões do sistema para verificar possíveis falhas após a correção de defeitos.
A correção de um defeito ou modificaçãode alguma parte pode gerar novos defeitos. Neste caso, devem ser executados novamente todos os testes. Se aplicar novos testes na nova versão e ela não passar, considera-se que o sistema regrediu, por isso o nome regressão.
Por se tratar por uma atividade de alto custo, pois pode ser executada diversas vezes ao longo do ciclo de vida do software, é importante que os testes sejam automatizados.
Tipos de testes
Os tipos de testes estão diretamente relacionados ao tipo de requisito que está sendo testado e, portanto, classificam-se em duas categorias principais: não funcionais e funcionais.
A seguir, confira o detalhamento dos tipos de testes não funcionais (interface, performance, segurança, recuperação de falhas etc.) e, posteriormente, o teste de funcionalidade.
Teste de interface com o usuário
O teste de interface tem como objetivo verificar se as interfaces, por meio das quais as funcionalidades são executadas, são eficazes e eficientes. Mesmo que a funcionalidade seja aprovada no teste do sistema, ou seja, as saídas são as esperadas, aspectos de usabilidade não atendidos podem provocar modificações na aplicação.
Exemplos do que pode ser verificado em testes de interface:
· Acessibilidade (deficientes visuais, auditivos etc.).
· Ergonomia (uso do mouse que exige muitos movimentos de braço).
· Mensagens do sistema (apropriação do texto e localização das mensagens).
· Sequência de execução das funcionalidades (otimização da sequência das funcionalidades que facilite a execução de caminhos principais e alternativos).
Teste de performance (carga, estresse e resistência)
Este tipo de teste tem o objetivo de executar as funcionalidades e mensurar o seu tempo, avaliando se está dentro dos padrões definidos. Os testes de performance também têm o objetivo de avaliar a estabilidade de um sistema. Eles podem ser classificados em três tipos:
· Teste de carga
· Teste de estresse
· Teste de resistência
Teste de segurança
São diversos os aspectos de segurança que precisam ser verificados em um sistema. A seguir, confira seis tipos de teste de segurança que devem ser testados:
· Integridade: garantir que a informação recebida é correta e completa.
· Autenticação: garantir que o usuário é quem diz que é.
· Autorização: garantir que apenas pessoas autorizadas tenham acesso à informação.
· Confidencialidade: garantir que pessoas não autorizadas não tenham acesso à informação.
· Disponibilidade: garantir que pessoas autorizadas consigam obter a informação.
· Não repúdio: garantir que emissor ou receptor não possam alegar que não enviaram ou receberam uma mensagem.
Alguns tipos de testes podem se complementam mutuamente (ex.: confidencialidade e disponibilidade).
Teste de recuperação de falhas
O teste de recuperação de falhas consiste em verificar a capacidade de o sistema se tornar operacional novamente após a ocorrência de uma falha. Situações em que se aplica:
· Queda de energia no cliente ou servidor.
· Rompimento de fibra ótica.
· Discos corrompidos.
Teste de funcionalidade
Conforme o nome sugere, é o tipo de teste que verifica e valida as funções do sistema, ou seja, os processos que podem ser efetivamente realizados por meio do fluxo entrada, processamento e saída.
Exemplos de funções:
· Incluir um cliente.
· Validar um CPF.
· Pesquisar um livro em uma livraria.
· Transferir valores entre contas financeiras.
Técnicas de testes de funcionalidade
Até este momento, conhecemos os testes sobre duas perspectivas – níveis e tipos.
· Os níveis demonstram que a atividade de teste precisa ser realizada desde a implementação das menores unidade de software (métodos, funções etc.) até a operacionalização completa do sistema incluindo a aceitação do cliente.
· Os tipos demonstram que os testes devem ser realizados tanto para requisitos não funcionais quanto para requisitos funcionais.
O teste de funcionalidade tem uma particularidade especial em relação aos requisitos não funcionais: está mais focado no código implementado. Para os testes de funcionalidade, há duas técnicas mais conhecidas: teste funcional e teste estrutural.
Teste funcional (caixa preta)
O teste funcional, também conhecido como caixa-preta (Figura 1), é executado sobre as entradas e as saídas do programa, sem que se tenha necessariamente conhecimento do seu código-fonte.
Figura 1: Teste funcional (caixa preta)
A figura representa o conceito de teste funcional, em que o foco são as entradas e saídas, sem interesse em como internamente o código está implementado. Fonte: O autor (2021).
O componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno dele. Os dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.
Teste estrutural (caixa-branca)
O teste estrutural, também conhecido como caixa-branca (Figura 2), é executado com conhecimento do código implementado. Ele avalia o comportamento interno do componente de software, atuando diretamente no código-fonte do componente de software.
Figura 2: Teste estrutural (caixa-branca)
A figura representa o conceito de teste estrutural, em que o foco são os elementos internos (estrutura de seleção, repetição etc.) do componente. Fonte: O autor (2021).
Este teste pode ajudar a responder à pergunta-chave:
Quais casos de testes adicionais são necessários para revelar falhas que não são aparentes, usando somente testes de caixa-preta?
A diferença principal entre testes caixa-branca e caixa-preta está na fonte utilizada para estabelecer os casos de teste.
Nas próximas Unidades de Estudo, será apresentado detalhadamente o funcionamento das técnicas de teste funcional e estrutural.
A videoaula dessa unidade apresenta um exemplo de especificação de um programa de computador e os casos de testes necessários para identificar possíveis defeitos nele. É possível observar a importância de utilizar técnicas sistemáticas para a elaboração de casos de testes. A apresentação também ressalta que é possível combinar técnicas funcionais (caixa-branca) e técnicas estruturais (caixa-preta) para obter casos de teste que garantam a qualidade do software.
Conclusão
Nesta Unidade, foi introduzido o tema “testes de software”. Por meio das seções, discutimos a importância, os conceitos e os desafios da atividade de testes, os quais devem ser executados em todas as fases do desenvolvimento de software e ser aplicados para testar tanto requisitos funcionais quanto não funcionais. Para cada tipo de teste, aspectos distintos devem ser avaliados. Concluímos a Unidade com a apresentação dos dois tipos de técnicas focados no teste de funcionalidade: teste funcional (caixa-preta) e teste estrutural (caixa-branca). As Unidades seguintes apresentarão detalhadamente a aplicação de ambas as técnicas.
Referências bibliográficas
BRAGA, P. H. C. Testes de software. São Paulo: Pearson Education do Brasil, 2016. Disponível em: https://plataforma.bvirtual.com.br/Leitor/Publicacao/150962/epub/0. Acesso em: 26 de abril de 2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/. Acesso em: 26 de abril de 2021.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. 2. ed. Rio de Janeiro: Elsevier, 2019.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 06
Testes funcionais
Esta unidade inicia com uma introdução ao teste funcional trazendo o objetivo, os níveis de aplicação e tipos de requisitos associados a este tipo de teste. Posteriormente são apresentados alguns tipos de critérios que podem ser utilizados para especificar casos de testes que busquem identificar possíveis defeitos no código desenvolvido. Ao longo da unidade são apresentados alguns exercícios resolvidos para exemplificar a aplicação da técnica.
Introdução ao Teste Funcional
Como visto na unidade anterior(Testes de Software), os testes de software devem acontecer em etapas distintas do desenvolvimento do software e portanto, há a necessidade de técnicas diferentes para atender os níveis e os tipos de requisitos envolvidos.
O teste funcional pode ser utilizado em todos os níveis de desenvolvimento do software, desde os testes de unidades até os testes de regressão.
O teste funcional, como o próprio nome diz, está focado na funcionalidade, e portanto, a ênfase são os requisitos funcionais. O foco deste tipo de testes são as entradas e as saídas, sem a preocupação em como a funcionalidade está codificada. O componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo (Figura 1).
Neste tipo de teste, os dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado. Se ambos os resultados forem iguais, significa que o código foi desenvolvido conforme a especificação.
A elaboração dos casos de testes, neste tipo de técnica, baseia-se na especificação do requisito funcional. Neste caso, não se pode garantir que partes essenciais ou críticas do software foram executadas, pois a ênfase é a especificação da funcionalidade e não como a funcionalidade foi codificada.
Figura 1: Teste funcional (caixa preta)
A figura representa o conceito de teste funcional onde o foco são as entradas e as saídas e não em como o código internamente está implementado. Fonte: O autor (2021).
Critérios para Teste Funcional
Elaborar e executar todos os casos de testes possíveis para identificar possíveis defeitos no código, pode ser uma missão impossível. Quanto mais complexa a funcionalidade, mais entradas e caminhos de execução distintos são possíveis. Portanto, há que se adotar critérios que possibilite a execução da maior parte dos cenários existentes, porém com o menor esforço possível.
A seguir serão apresentados alguns critérios que podem ser utilizados nos testes funcionais de maneira a executar casos de testes de qualidade que possibilite a maior cobertura possível.
Catálogo de ideias
Este critério é o mais informal, ele é baseado nas experiências de projetos anteriores e conforme a equipe identifica casos de testes recorrentes, ela atualiza uma base de casos de testes que devem ser executados por padrão nos projetos.
Exemplo: as ideias de testes para campos numéricos podem ser catalogadas em conjunto para que sejam aplicadas em qualquer campo dessa categoria.
Exercício
Exercício 1: Um campo de formulário pode aceitar valores inteiros entre 20 e 50. Quais testes poderiam ser realizados?
·
· Resolução do exercício
Particionamento por equivalência
Este tipo de critério tem o objetivo de minimizar o número de casos de teste, tomando como ponto de partida a identificação de classes que devem ter comportamentos equivalentes.
Neste tipo de critério, inicia-se identificando conjunto de estados válidos e inválidos para uma condição de entrada. Os conjuntos de entradas são sempre uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica.
Pode ser impossível testar todos os elementos de cada classe de equivalência, porém, pelos menos um elemento de cada classe de equivalência será testado. Se as entradas válidas são especificadas como um intervalo de valores (ex: de 10 a 20), então são definidas uma classe válida, de 10 a 20, e duas classes inválidas: menor do que 10 e maior do que 20.
Para entender na prática a aplicação deste critério, a seguir são apresentados 3 exercícios. Nos dois primeiros exercícios, a solução é apresentada na própria unidade. Já o último exercício, a solução é apresentada em um vídeo com a explicação detalhada do uso do critério.
Para os 3 exercícios o que se pede é: elaborar casos de testes a partir da especificação utilizando o critério de particionamento por equivalência.
Exercício
Exercício 2: Especificação: "... o cálculo do desconto por dependente é feito de acordo com a idade informada na entrada: Para dependentes com até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 15 (inclusive) o desconto é de 12%. Dos 16 aos 18 (inclusive) o desconto é de 5% e dos 19 aos 21 de 3%"
·
· Resolução do exercício
Exercício
Exercício 3: Especificação: Um programa que recebe 3 valores inteiros superiores a zero que correspondem ao tamanho de três vértices representados pelas variáveis A, B e C, obedecem a seguinte classificação:
Equilátero: Três lados iguais
Isósceles: Dois lados iguais
Escaleno: Três lados diferentes
·
· Resolução do exercício
Exercício
Exercício 4: Especificação: Em um programa devem ser lidos os seguintes dados de uma pessoa:
Sexo(1 = masculino e 2 = feminino)
Idade
Estado de saúde (1= boa e = 0 ruim)
Com base nestas informações, o programa deve informar se a pessoa está apta ou inapta para cumprir o serviço militar. Uma pessoa é apta se é do sexo masculino, tem idade igual ou superior a 18 anos e estado de saúde é boa.
Se sexo diferente de 1 e 2 ou idade menor que 0 ou estado de saúde diferente de 0 ou 1 deve ser informada que entrada inválida.
Assista a videoaula desta unidade com a explicação detalhada do resultado.
Análise do valor limítrofe
Os bugs (defeitos) costumam se esconder nas fretas, sendo assim uma boa estratégia é utilizar a técnica de participação por equivalência em conjunto com o critério de análise de valor limítrofe.
A análise de valor limítrofe consiste em considerar valores fronteiriços nas classes de equivalência ou em outros casos de testes.
Por exemplo, se um programa exige uma entrada que, para ser válida, deve estar no intervalo [n..m], então existe 3 classes de equivalência:
· Válida para qualquer n m
Para cada intervalo é indicado que se incluam casos de testes para:
· Valores limite inferior
· Valores limite inferior -1
· Valores limite superior
· Valores limite superior +1
Utilizando a técnica de Particionamento de Equivalência e posteriormente a Análise do Valor Limítrofe, identifique os casos de testes candidatos.
Exercício
Exercício 5: Especificação: Considere, um programa com um parâmetro de entrada idade, do tipo inteiro, definido de acordo com as classes de equivalência a seguir:
Menor que 0: inválido
Entre 0 e 17: válido (menor de idade)
Entre 18 e 64: válido (adulto)
Entre 65 e 120: válido (idoso)
Acima de 121: inválido (improvável)
·
· Resolução do exercício
Caso de uso
Os testes também podem ser especificados a partir de casos de uso ou cenários de negócio. Um caso de uso descreve a interação do sistema com atores e a entrega de um resultado de valor. Cada caso de uso possui pré-condições e pós-condições.
Um caso de uso sempre possui um cenário principal e frequentemente cenários alternativos (inclusive de exceção) (Figura 2).
Figura 2: Representação gráfica de um caso de uso
A figura apresenta os possíveis fluxos que podem ser especificados a partir de um caso de uso. Fonte: O autor (2021).
Como dito, testes funcionais podem acontecer em vários níveis de testes, neste os casos de testes gerados por meio de casos de uso estão alinhados com testes a nível de sistema. O teste de sistema consiste em testar a interface do sistema como se fosse um usuário realizando todos os fluxos possíveis do caso de uso.
A seguir um trecho de uma especificação para um caso de uso “Comprar itens” existente em um contexto de um e-commerce.
Caso de uso: Comprar itens
Fluxo principal
1. O usuário insere palavras-chave para localizar item.
2. O sistema apresenta a lista de itens relacionados às palavras-chave.
3. O usuário seleciona um item e informa a quantidade desejada.
4. O sistema informa o itens adicionados até o momento e o valor do pedido.
5. O usuário finaliza a compra.
Fluxo alternativo
A5a. O usuário deseja pesquisar novos itens.
Retorna ao passo 1 do fluxo principal.
Fluxo de exceção
E3a. O usuário indica uma quantidade não disponível no estoque.
E3a1. O sistema informa a quantidade disponível no estoque.E3a2. O usuário informa uma quantidade disponível no estoque.
Avança ao passo 4 do fluxo principal.
A Tabela 1 apresenta os casos de testes que podem ser elaborados a partir da especificação do caso de uso.
Tabela 1: Casos de testes extraídos da especificação de caso de uso
Caso de teste
Objetivo
Caminho
Como testar
Resultado esperado
1
Fluxo principal.
1, 2, 3, 4, 5
Entrar com palavras-chave, seleciona um item, indica uma quantidade dentro do estoque e finaliza a compra.
Compra com o item e quantidade registrada.
2
Fluxo alternativo:
Usuário deseja pesquisar novos itens.
1, 2, 3, 4, 1, 2, 3, 4, 5
Entrar com palavras-chave, seleciona um item, indica uma quantidade dentro do estoque. Em seguida entra com novas palavras-chave, indica uma quantidade dentro do estoque e finaliza a compra.
Compra com os 2 itens e quantidades respectivas registradas.
3
Fluxo de exceção:
Usuário indica uma quantidade não disponível no estoque.
1, 2, 3, E3a.1, E3a.2, 4, 5
Entrar com palavras-chave, seleciona um item, indica uma quantidade acima do estoque disponível. Em seguida informa uma quantidade disponível no estoque e finaliza a compra.
Informa quantidade não disponível. Em seguida compra com o item da quantidade disponível registrada.
A tabela apresenta possíveis casos de testes que podem ser elaborados a partir da especificação do caso de uso. Fonte: O autor (2021).
Considerações finais
· Testes funcionais tem como vantagem requerer apenas a especificação funcional do produto para derivar os requisitos de teste
· Independente da arquitetura do software
· Tanto faz ser orientado a objetos, serviços ou procedural
· Tanto faz se a arquitetura é orientada a componentes ou monolítica
· Não garante que partes críticas e essenciais do código seja cobertos
Conclusão
Nesta unidade foi apresentada a técnica de testes funcionais. Os casos de testes funcionais são gerados a partir da especificação da funcionalidade ou regra de negócio. Estes testes podem ser executados em todos os níveis de teste (unidade, integração, sistema, aceitação e regressão). Ao longo da unidade foram apresentados alguns critérios que podem ser utilizados para a geração dos casos de testes, sendo eles: catálogo de ideias, particionamento por equivalência, análise do valor limítrofe e casos de uso. Para cada tipo de critério foram apresentados exercícios e as respectivas soluções para melhor entendimento da sua aplicação. Embora esta técnica permita a geração de casos de testes com qualidade, é possível que existam defeitos no código que não serão descobertos com os casos de testes gerados por meio da técnica funcional. O tipo de teste estrutural, que tem como foco o código implementado, complementa os testes funcionais e procura garantir a cobertura do código. Na próxima unidade veremos em mais detalhes a aplicação da técnica estrutural, também conhecida como teste de caixa-branca.
Referências bibliográficas
BRAGA, P. H. C. Testes de Software. São Paulo, Pearson Education do Brasil, 2016. [Biblioteca Virtual]
PRESSMAN, R. S. ; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. – Porto Alegre: AMGH, 2016. [Minha Biblioteca]
WAZLAWICK, R. S. Engenharia de Software: conceitos e práticas. 2. Ed. Rio de Janeiro: Elsevier, 2019
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 07
Testes estruturais
Esta Unidade apresenta a técnica de estrutural. O início se dá com uma introdução a respeito do objetivo principal da técnica e esclarecimento da diferença entre os testes funcionais e estruturais. Ao longo da Unidade, estão apresentados em detalhes os conceitos e exemplos de aplicação da técnica de teste estrutural caminho básico. Para finalizar, é apresentado o conceito de Test Driven Development (TDD) e as possibilidades de ferramentas para automação dos testes.
Introdução ao teste estrutural
Na Unidade anterior, aprendemos que os testes funcionais não dependem de código implementado, pois podem ser gerados a partir das especificações de software. Já o teste estrutural, também conhecido como teste de caixa-branca, tem como foco o código implementado e procura garantir a cobertura do código.
O teste estrutural avalia o comportamento interno do componente de software e pode ajudar a responder à pergunta-chave:
Quais casos de testes adicionais são necessários para revelar falhas que não são aparentes usando somente testes de caixa-preta?
As técnicas de teste estrutural, também chamadas de testes, se baseiam na estrutura de um componente ou sistema.
Um conceito muito importante na aplicação de técnica de testes estruturais é o de cobertura, uma medida dos elementos de um componente ou sistema que são cobertos pelos testes estruturais. O objetivo é que se tenha um conjunto de testes que percorra todos os elementos estruturais de um código a ser testado.
A seguir, confira a fórmula para calcular o percentual de cobertura de testes de um determinado conjunto de elementos estruturais (código-fonte):
Cobertura = qtd. elementos estruturais executados / qtd. elementos estruturais existentes * 100.
Está apresentado na Figura 1 um exemplo de um código-fonte que calcula a mediana, usando três valores de entrada. Cada comando foi considerado um elemento estrutural e os valores 1, 2 e 3, assumidos para o teste.
Figura 1: Exemplo de um código-fonte
A figura apresenta um exemplo de um código que calcula a mediana e as linhas do código que foram executadas, considerando que os valores de entrada para o teste foram: 1, 2 e 3. Fonte: O autor (2021).
O percentual de cobertura do código, considerando o teste realizado, seria igual a 50%, em que:
Cobertura = 4 / 8 * 100 = 50
Caminho básico: critério para elaboração de testes estruturais
Assim como para elaborar os testes funcionais é necessário utilizar critérios, nos testes estruturais ocorre o mesmo desafio. Nos estruturais é necessário estabelecer um conjunto de casos de testes que garanta que todas as instruções codificadas para um elemento de software sejam executadas pelo menos uma vez.
O uso de critérios é importante para evitar que parte do código seja testado repetidas vezes, enquanto parte do código não seja executada nenhuma vez.
Um dos critérios utilizados para estabelecer os casos de testes estruturais é o caminho básico.
O caminho básico é uma técnica de teste de caixa-branca, proposta por Tom McCabe, em 1976. Esta medida serve como um guia para definir um conjunto de caminhos de execução. A partir dos caminhos de execução é possível identificar quantos casos de testes são necessários para percorrer todos os fluxos do código-fonte.
Grafo de fluxo
A partir do código-fonte é gerado um grafo de fluxo, a partir do qual é possível identificar a complexidade lógica e, consequentemente, o conjunto de caminhos de execução.
A construção do grafo é feita de acordo com os padrões apresentados na Figura 2.
Figura 2: Formas de representação em um grafo das estruturas de um código-fonte
A figura apresenta as formas de representação em um grafo das estruturas básicas de um código-fonte. Fonte: O autor (2021).
A Figura 3, apresentada a seguir, exemplifica como um fluxo de um código-fonte com estruturas sequenciais e de condição seria representado por meio de um grafo. Já a Figura 4 exemplifica como um fluxo de um código-fonte com estruturas sequenciais, de condição e de repetição seriam representadas por meio um grafo.
Figura 3: Exemplo de um código-fonte com estruturas sequenciais e de condição
A Figura exemplifica como um fluxo de um código-fonte com estruturas sequenciais e de condição seria representado por meio de um grafo. Fonte: O autor (2021).
Figura 4: Exemplo de um código-fonte com estruturas sequenciais, de condição e de repetição
A Figura exemplifica como um fluxo de um código-fonte com estruturas sequenciais, de condição e de repetição seria representado por meio de um grafo. Fonte: O autor (2021).
Com o auxílio do grafo apresentado, é possível identificaros caminhos independentes.
Caminhos independentes
Os caminhos independentes, por sua vez, são ciclos que não contêm outros ciclos embarcados. Deverá existir pelo menos um caso de teste para cada caminho independente existente. Desta forma, garante-se 100% de cobertura de execução do código.
Tomando como exemplo o grafo gerado na Figura 4, existem três caminhos independentes, listados a seguir:
· C1: 1,2,7.
· C2: 1,2,3,4,6,2,7.
· C3: 1,2,3,5,6,2,7.
Cada um dos caminhos inclui pelo menos um nó que ainda não foi executado pelos caminhos anteriores. No caso dos caminhos C2 e C3, o que os diferencia é a execução dos nós 4 e 5, respectivamente. Um exemplo de um caminho independente inválido está listado a seguir:
· C4: 1,2,3,4,6,2,3,5,6,2,7.
C4 não é um caminho independente, pois embora apresente uma sequência diferente, não inclui nenhum outro nó ainda não considerado em C1, C2 ou C3.
Ou seja, caminho independente é qualquer caminho que introduza pelo menos um novo conjunto de comandos.
Existe uma maneira para calcular os caminhos independentes, que é por meio da identificação da complexidade ciclomática do código analisado.
Complexidade ciclomática
Para confirmar de uma maneira mais segura quantos caminhos independentes existem em um código, basta calcular a complexidade ciclomática. A complexidade ciclomática é uma métrica de software que fornece a medida quantitativa da complexidade lógica de um programa.
O cálculo pode ser realizado por meio da fórmula apresentada a seguir:
· CC = A – N + 2, em que:
·
· CC = Complexidade ciclomática.
·
· A = número de arcos (arestas) do grafo.
·
· N = número de nós do grafo.
Considerando o exemplo da Figura 3, teríamos:
· CC = 4 – 4 + 2.
CC = 2.
Ou seja, teríamos dois caminhos independentes:
C1 = 1, 2, 4.
C2 = 1, 3, 4.
Considerando o exemplo da Figura 4, teríamos:
· CC = 8 – 7 + 2.
CC = 3.
Ou seja, teríamos três caminhos independentes, confirmando a avaliação manual, exemplificada na seção caminhos independentes.
Lembre-se: os caminhos independentes indicam quantos fluxos distintos podem ser percorridos em um código-fonte. O cálculo da complexidade ciclomática identifica quantos caminhos independentes existem em um código. O seu cálculo é extremamente útil quando o código é mais longo e complexo. Quanto mais longo e complexo o código, mais difícil se torna a identificação manual dos caminhos independentes. Portanto, o cálculo da complexidade ciclomática confirma quantos caminhos independentes existem no código analisado. Se houver um caso de teste para cada caminho independente, será garantida 100% de cobertura do código na execução desses testes.
Uma outra forma mais simples de calcular a complexidade ciclomática é: contar a quantidade de estruturas de seleção e de repetição + 1.
Casos de testes
O último passo do uso do critério do caminho básico é planejar casos de testes para cada um dos caminhos independentes identificados.
Considerando o exemplo da Figura 4, foram identificados três caminhos independentes:
· C1: 1,2,7.
· C2: 1,2,3,4,6,2,7.
· C3: 1,2,3,5,6,2,7.
Agora, é necessário planejar casos de testes que façam com que os caminhos independentes sejam percorridos pelo menos uma vez.
Confira alguns exemplos de parâmetros de entrada que fariam com que o caminho independente fosse executado:
· C1: valor de entrada = 0.
· C2: valor de entrada = 1.
· C3: valor de entrada = -1.
Analise o código-fonte e faça o teste de mesa para verificar como os fluxos de execução são diferentes de acordo com os três cenários de entrada planejados. Estes três casos de testes garantem que todas as instruções do código foram executadas, e, se houver alguma falha, o teste revelará.
Exercício
De acordo com o código-fonte abaixo, realize as seguintes ações:
· Desenhar o grafo de fluxo.
· Calcular a complexidade ciclomática.
· Identificar os caminhos independentes.
· Definir um caso de teste para cada caminho independente.
public static int buscaBinaria( int[] array, int valor )
{ int esq = 0;
int dir = array.length - 1;
int valorMeio;
while ( esq valor ) {
dir = valorMeio - 1;
} else {
return valorMeio;
}
}
return -1;
}
Após realizar o exercício, assista à videoaula desta Unidade para acompanhar a resolução do exercício apresentado.
Na aplicação da técnica estrutural, um conceito que tem ganhado atenção e adoção, principalmente em times ágeis, é o Test Driven Development (TDD). A seção a seguir descreve qual é a filosofia por trás deste conceito.
TDD
TDD é uma técnica ou filosofia que incorpora testes ao processo de produção de código. O desenvolvedor recebe a especificação da nova funcionalidade e programa um conjunto de testes automatizados para um código que não existe. Esse conjunto de testes deve ser executado e falhar. O código é desenvolvido apenas para passar nos testes; então, é refatorado para atender aos padrões de qualidade e testado novamente.
Depois que os testes foram estabelecidos, o programador não deve implementar nenhuma funcionalidade. O objetivo é evitar que os programadores percam tempo com estruturas desnecessárias. Isso atende ao princípio Keep it Simple, Stupid (KISS), que indica como tolice fazer algo a mais do que o necessário.
A aplicação de testes, de uma maneira geral, seja testes funcionais ou testes estruturais, tem demandado a disponibilidade de ferramentas que apoiem desde a gestão até a automatização deles.
As ferramentas são bastante variadas, voltadas para os diversos níveis de testes, tipos de requisitos, tipos de linguagens etc.
Confira a seguir algumas ferramentas que, atualmente, têm sido utilizadas com um certo destaque na indústria de desenvolvimento de software.
Automação e gestão dos testes
A seguir, estão relacionadas algumas ferramentas atualmente utilizadas para a automação e gestão dos testes.
· ComplexGraph: constrói o gráfico e calcula complexidade ciclomática, ou seja, no de testes necessário para 100% de cobertura.
https://code.google.com/archive/p/complexgraph/downloads
· Eclemma: análise de cobertura dos testes.
https://www.eclemma.org/
· JUnit: biblioteca para automatização dos testes unitários para Java.
https://www.eclipse.org/community/eclipse_newsletter/2017/october/article5.php
· PyUnit: biblioteca para automatização dos testes unitários para Python.
http://pyunit.sourceforge.net/
· Selenium: framework para testes em aplicativos web.
https://www.selenium.dev/
· Robotium: voltado para testes em aplicativos de Android.
https://www.methodsandtools.com/tools/robotium.php
· Watir: automação de testes da Web, em código aberto, baseados em bibliotecas de código Ruby.
http://watir.com/
· TestRails: gerenciamento de casos de testes.
https://www.gurock.com/testrail/
· TestLinks: gerenciamento de testes.
https://testlink.org/
· Jira: gerenciamento de testes.
https://support.atlassian.com/jira-software-server/
Existem muitas outras ferramentas disponíveis para a automação de testes. Cada uma delas pode ter uma ênfase diferente, como: a plataforma (web, desktop ou mobile), o tipo de linguagem (Java, Python, Ruby etc.), os tipos de requisitos (funcionais ou não funcionais) e a gestão dos testes (controle da qualidade dos testes, coleta de métricas de testes etc.).
A área de tecnologia evolui continuamente, assim como as ferramentas. No momento em que estiver estudando esta Unidade, pode ser que novas ferramentas tenham sido disponibilizadas pelo mercado. Portanto, sugerimos que faça uma pesquisa exploratória para conhecer quais são as disponíveis atualmente para automação de testes e para quais tipos de testes são mais indicadas.
Foi apresentada nesta Unidade a técnica de testes estruturais. Foi detalhado o uso do critériodo caminho básico, utilizado para a elaboração e a execução dos casos de testes estruturais. Para entender a aplicação desse critério, foram discutidos alguns conceitos, tais como completude, grafo de fluxo, caminhos independentes e complexidade ciclomática. O objetivo principal do teste estrutural é elaborar casos de testes que levem à execução de 100% do código avaliado. Desta forma, garantimos que, se há alguma falha, em alguma parte do código, este conjunto de testes irá revelá-lo. A adoção dos testes tem sido cada vez maior devido à complexidade de desenvolvimento e à necessidade de entrega de produtos de software com mais qualidade. Por conta disso, novos modelos, conceitos e ferramentas têm sido propostos. Ao final da Unidade, foi apresentado o conceito de TDD e alguns exemplos de ferramentas de automação de testes. O TDD tem como objetivo encorajar o programador a codificar os casos de testes antes mesmo de o código ter sido construído. Estes casos de testes facilitam posteriormente a automatização dos testes. Sabemos que a atividade de testes é importante e trabalhosa, portanto, diversas ferramentas têm sido propostas para apoiar nesta atividade. A Unidade foi concluída com uma lista resumida de ferramentas disponíveis com este objetivo, mas encorajamos que você faça a sua pesquisa para ampliar as possibilidades de aplicação.
Referências
BRAGA, P. H. C. Testes de software. São Paulo: Pearson Education do Brasil, 2016. Disponível em: https://plataforma.bvirtual.com.br/Leitor/Publicacao/150962/epub/0.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. 2. ed. Rio de Janeiro: Elsevier, 2019.
DEVCAST. E aí? Como você testa seus códigos? Devmedia, Tecnologias, s.d. Disponível em: https://www.devmedia.com.br/e-ai-como-voce-testa-seus-codigos/39478. Acesso em: 19 maio 21.
DEVMEDIA. Teste unitário com JUnit e ComplexGraph. Devmedia, Tecnologias, 2014. Disponível em: https://www.devmedia.com.br/teste-unitario-com-junit-e-complexgraph/31382. Acesso em: 19 maio 21.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 08
Modelos de maturidade
Nesta unidade iremos conhecer dois dos modelos de maturidade mais conhecidos na indústria de desenvolvimento de software. O primeiro, o CMMI, é um modelo americano e o segundo, o MR-MPS-SW, é um modelo brasileiro. De uma maneira geral, ambos têm o mesmo objetivo que é trazer um conjunto de boas práticas para apoiar as empresas desenvolvedores de software a institucionalizarem processos que tragam mais qualidade para os seus produtos. Por fim, a unidade é finalizada com uma restrospectiva da disciplina para trazer uma reflexão sobre o propósito da área de Engenharia de Software.
Modelos de maturidade
A qualidade de um produto de software pode ser afetada pela qualidade do processo utilizado para desenvolvê-lo. Devido a esta dependência, existem modelos de maturidade que avaliam a qualidade da implementação de processos de desenvolvimento de software nas empresas.
Estes modelos são coleções estruturadas de boas práticas e descrevem características de um processo efetivo. Estas boas práticas são provenientes de experiências efetivas coletadas ao longo do tempo.
É importante ressaltar que estes modelos não são prescritivos, ou seja, descrevem “o que” fazer, mas não “como” fazer.
Nesta unidade iremos conhecer um pouco das características de dois dos modelos mais consolidados no mercado de desenvolvimento de software: o CMMI e o MPS.BR
CMMI (Capability Maturity Model Integration)
O CMMI é um modelo compatível com o modelo SPICE da ISO (norma que tem o objetivo de ajudar uma organização a otimizar seus processos). O CMMI foi construído com a participação de diversos setores da sociedade, tais como, a indústria, o governo norte-americano e o Instituto de Engenharia de Software (SEI).
Sua primeira versão foi lançada em 2002 e a mais atual em 2018. Até a versão 1.3, lançada em 2010, o acesso ao guia era gratuito, porém, a partir das novas versões o seu acesso passou a ser cobrado.
O CMMI pode ser usado como um guia para melhorar o processo de uma organização e a habilidade de gerenciar o desenvolvimento, aquisição e manutenção de produtos e/ou serviços. Ele também pode ser usado como uma ferramenta para avaliar a maturidade da organização em termos de qualidade do processo de desenvolvimento, aquisição e manutenção de produtos e/ou serviços.
Os elementos apresentados nesta unidade, são baseados na versão 1.3. Embora seja uma versão anterior, grande parte dos conceitos discutidos nesta versão, também são encontrados nas versões mais recentes.
O modelo prevê cinco níveis de maturidade conforme representado na Figura 1. Cada um destes níveis representa como um conjunto de processos é desenvolvido na empresa.
· Nível 1
· Nível 2
· Nível 3
· Nível 4
· Nível 5
Figura 1: Níveis de maturidade do CMMI
A figura representa os cinco níveis de maturidade propostos no modelo CMMI, bem como as principais características esperadas em cada um dos níveis. Fonte: http://www.isdbrasil.com.br/o-que-e-cmmi.php
Em cada nível é esperada maturidade em um conjunto de processos, sendo que a empresa atinge esta maturidade apenas se todos os processos esperados daquele nível forem atingidos. Além disso, os níveis de maturidade são compreendidos como estágios, desta forma, o nível somente é atingido, se os níveis anteriores também tiverem sido atingidos.
As empresas avaliadas podem ser consultadas on-line, por meio do site: https://cmmiinstitute.com/pars. No site é possível consultar o nome da empresa, o nível de maturidade, a data de validade da avaliação, entre outras informações.
O modelo traz todo o detalhamento (CMMI - Versão 1.3) de quais são os aspectos a serem avaliados para determinar o nível de maturidade de uma organização que desenvolve produtos de software. Nesta unidade, o objetivo não é entender em profundidade o modelo, mas conhecer o seu propósito e os 5 níveis de maturidade. Recomenda-se que o estudante navegue pelo documento para entender a magnitude do modelo e a sua organização.
MPS.BR
O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, criado em 2003, sob a coordenação da Associação para Promoção da Excelência do Software Brasileiro (SOFTEX).
A sua criação teve o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).
As metas principais do programa são:
· Definir e aprimorar um modelo de melhoria e avaliação de processo de software, para micro, pequenas e médias empresas; e
· Reconhecimento nacional e internacional como um modelo aplicável à indústria de software.
O modelo brasileiro é independente, mas compatível com as Normas ISO 12207 e SPICE, bem como com o CMMI. A sua criação teve como motivação os altos custos dos processos de avaliação ou certificação internacionais, que se tornavam inviáveis para pequenas e médias empresas brasileiras.
O MPS.BR é um programa composto por modelos, métodos e guias tanto para software e serviços de TI, quanto para gestão de pessoas. A Figura 2 representa os componentes estruturais do programa onde constam os três modelos de referências:
· MR-MPS-SW: modelo de referência associado à melhoria de processo de Software;
· MR-MPS-SV: modelo de referência associado à melhoria de processo de Serviços; e
· MR-MPS-RH: modelo de referência associado à melhoria de processo de Gestão de Pessoas.
O modelo MR-MPS-SW apresenta sete níveis de maturidade, representados na Figura 3. São dois níveis a mais do que o CMMI, o que torna a progressão mais suave e adequada às micros, pequenas e médias empresas.
Figura 2: Componentes do MPS.BR
A figura apresenta os modelos, os métodos e os guias que são componentes do programa. A figura também representa as normas ISOque inspiraram a criação dos modelos componentes do programa. Fonte: https://blog.grancursosonline.com.br/mps-br-2020/
Figura 3: Níveis de maturidade do MPS.BR
A figura representa os sete níveis de maturidade propostos no modelo MR-MPS-SW, bem como os processos a serem avaliados em cada nível. Fonte: https://promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/
Para cada um destes sete níveis de maturidade é atribuído um perfil de processos, chamados atributos de processo (AP) que indicam onde a organização deve colocar o esforço de melhoria.
O progresso e o alcance de um determinado nível de maturidade MPS se obtêm, quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível. Assim como no CMMI, os níveis são cumulativos, isto é, para subir um nível devem-se satisfazer todos os critérios dos níveis anteriores e os do nível para o qual se deseja subir.
Cada nível de maturidade possui suas áreas de processo, em que são analisados os processos fundamentais. A capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados.
Os processos estão divididos em dois conjuntos: processos de projetos e processos organizacionais, como pode ser visto na Figura 4. Os processos de projeto são aqueles que são executados para os projetos de software. Esses projetos podem ser de desenvolvimento de um novo produto, manutenção ou evolução de produto. Os processos organizacionais são os processos concebidos para fornecer os recursos necessários para que o projeto/serviço atenda às expectativas e necessidades das partes interessadas.
Figura 4: Conjunto de Processos de Projetos e de Processos Organizacionais
Conjunto de Processos de Projetos e de Processos Organizacionais relacionados aos resultados esperados em cada nível propostos no modelo MR-MPS-SW. Fonte: https://softex.br/download/guia-geral-de-software-2021/
Os resultados esperados dos processos estão adequados a cada nível de maturidade pretendido, ou seja, nem todos os resultados estão presentes nos níveis iniciais e eles vão evoluindo à medida em que evolui a maturidade da organização, conforme a Figura 5. Os resultados são cumulativos, ou seja, os resultados que aparecem no nível G deverão estar presentes, com as mesmas características ou com evoluções, no nível F e acima.
Figura 5: Evolução dos processos nos níveis de maturidade
A figura representa para cada nível de maturidade quais são os processos de projeto e organizacionais envolvidos. Fonte: https://softex.br/download/guia-geral-de-software-2021/
De uma maneira geral, o MPS.BR serve como um selo que indica o nível de maturidade da empresa em relação às práticas relacionadas ao desenvolvimento de software. Assim como o CMMI, o modelo MR-MPS-SW apresenta diversos detalhes. Não é o objetivo desta unidade explorar em detalhes o seu funcionamento. No entanto, recomenda-se que o estudante navegue pelo documento para entender a sua organização e principalmente quais são os processos e os resultados esperados para cada nível de maturidade previsto no modelo.
Saiba Mais
O site da SOFTEX disponibiliza acesso gratuito ao guia geral do modelo (https://softex.br/download/1-guia-geral-de-software-2020/).
Retrospectiva da disciplina
Na Unidade 1, iniciamos a disciplina com uma introdução dos Fundamentos de Engenharia de Software. O objetivo foi entender conceitos essenciais da área, tais como, processo e qualidade. Ainda na introdução, conhecemos as grandes áreas do conhecimento que compõem a Engenharia de Software (15 ao total). Para compreender todas estas áreas precisaríamos de um curso de graduação completo, o que seria inviável para este contexto. Portanto, ao longo desta disciplina demos ênfase à apenas algumas destas áreas para aprofundarmos o entendimento do propósito da Engenharia de Software. Ainda na Unidade 1, apresentamos os modelos de processos de desenvolvimento de software, classificando em modelos tradicionais (prescritivos) e modelos ágeis. O uso institucionalizado de um modelo é crucial para se obter qualidade no processo de desenvolvimento.
Já na Unidade 2, avançamos com o tema estimativas de software para entender a importância dos métodos e das técnicas de estimativas de esforço de desenvolvimento. As estimativas de software apoiam o planejamento de desenvolvimento. Nesta unidade, conhecemos a técnica de estimativa Pontos de Histórias utilizada nos times ágeis. Nas Unidades 3 e 4 aprendemos em detalhes como aplicar algumas das técnicas de estimativas mais utilizadas para este fim: Pontos de Caso de Uso e Pontos de Função.
Nas Unidades 5, 6, 7 aprofundamentos os conhecimentos na área de testes de software. Os testes de software são atividades essenciais para obter qualidade do produto de software. Na Unidade 5 introduzimos os principais conceitos de testes, explorando-os por níveis e tipos. Na Unidade 6 aprendemos em detalhes a aplicação da técnica de testes funcionais (caixa preta), cujos casos de testes são extraídos a partir da especificação de requisitos. Enquanto na Unidade 7, aprendemos em detalhes a aplicação da técnica de testes estruturais (caixa branca), cujos testes dependemos do código fonte para extrair os casos de testes.
Por fim, finalizamos a disciplina com a Unidade 8 onde apresentamos dois dos modelos de maturidade mais conhecidos da indústria de desenvolvimento de software, CMMI e MPS.BR. Estes modelos foram construídos a partir das experiências de diversos projetos de software. De maneira geral, estes modelos têm o objetivo de ser um guia de boas práticas para melhorar o processo de desenvolvimento de software.
Finalizamos a unidade revisitando o mapa mental da disciplina para que possamos reconectar os temas de estudos abordados com os resultados de aprendizagem desenvolvidos.
Ao longo da disciplina, pudemos compreender as contribuições práticas da Engenharia de Software. A Engenharia de Software é uma área responsável por desenvolver métodos, modelos, técnicas e ferramentas que apoiam a melhoria dos processos que envolvem o desenvolvimento de software. Todos os recursos fornececidos pela Engenharia de Software têm como objetivo final entregar um produto com mais qualidade, ou seja, um produto correto que resolva os problemas de um contexto considerando prazos e custos adequados.
Nesta unidade apresentamos os modelos de maturidade CMMI e MR-MPS-BR. De uma maneira geral, ambos têm o mesmo objetivo que é trazer um conjunto de boas práticas para apoiar as empresas desenvolvedores de software a institucionalizarem processos que tragam mais qualidade para os seus produtos. Os modelos ajudam as empresas a identificarem em qual nível de maturidade elas se encontram. A partir desta identificação, as empresas podem focar ações em áreas que precisam ser desenvolvidas. Enquanto o CMMI é organizado em cinco níveis, o MR-MPS-BR é organizado em sete níveis para possibilitar uma progressão mais suave, principalmente para as pequenas empresas. Ao final da unidade foi realizada uma retrospectiva da disciplina para revisitar os principais temas de estudo abordados na disciplina e refletir sobre o propósito da área de Engenharia de Software para o processo de desenvolvimento de software.
Referências bibliográficas
CMMI - Versão 1.3. Disponível em: https://resources.sei.cmu.edu/asset_files/technicalreport/2010_005_001_15287.pdf. Acesso em: 10/12/2020
CMMI – Versão 2.0. Disponível em: https://cmmiinstitute.com/cmmi. Acesso em: 27/05/2021
Guia Geral MPS de Software. https://softex.br/download/1-guia-geral-de-software-2020/. Acesso em: 27/05/2021
MPS.BR – Melhoria de Processo do Software Brasileiro. Disponível em: https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2016.pdf. Acesso em: 10/09/2020
MR-MPS-SW. https://softex.br/mpsbr/guias/#guia-sw. Acesso em: 27/05/2021
PRESSMAN, R. S. ; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. – Porto Alegre: AMGH, 2016. [Minha Biblioteca]. Disponívelem: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/
SEI - www.sei.cmu.edu. Acesso em: 27/05/2021
WAZLAWICK, R. S. Engenharia de Software: conceitos e práticas. 2. Ed. Rio de Janeiro: Elsevier, 2019
https://promovesolucoes.com/niveis-maturidade-cmmi/#:~:text=O%20modelo%20CMMI%20estabelece%206,chegar%20ao%20N%C3%ADvel%205%20%E2%80%93%20Otimiza%C3%A7%C3%A3o. Acesso em: 27/05/2021.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
image6.jpeg
image7.jpeg
image8.jpeg
image9.jpeg
image10.jpeg
image11.png
image12.jpeg
image13.jpeg
image14.jpeg
image15.jpeg
image16.jpeg
image17.jpeg
image18.jpeg
image1.jpeg
image19.jpeg
image20.jpeg
image21.jpeg
image2.jpeg
image22.jpeg
image3.jpeg
image23.jpeg
image24.jpeg
image25.jpeg
image26.jpeg
image27.jpeg
image4.jpeg
image5.jpegalguns dos mais utilizados ao longo da história da engenharia de software.
A seguir, estão apresentados alguns detalhes referentes aos modelos: cascata, incremental, evolucionário (prototipação e espiral) e unificado.
MODELO CASCATA
O modelo cascata segue uma abordagem sequencial e sistemática. Inicia com levantamento de requisitos e avança para as demais atividades quando se entende que a atual está completa.
A Figura 2, apresentada a seguir, representa o ciclo de desenvolvimento de um software proposto no modelo cascata.
Figura 2: Modelo cascata
Ciclo de desenvolvimento no modelo cascata. Fonte: Autor (2021).
thumb_up_alt
Situações favoráveis para adoção do modelo cascata:
· Os requisitos de software estão bem compreendidos.
· Os requisitos de software são estáveis, ou seja, quando não mudam.
· O prazo para uso da solução não é urgente.
Isso significa que o modelo pode funcionar melhor em um contexto em que o domínio da aplicação e as suas regras de negócio são conhecidos pela equipe e que as mudanças de requisitos não são frequentes. Ou, ainda, quando não há uma urgência de prazo para a sua implantação. No entanto, sabe-se que estas situações praticamente não existem. Muitas vezes, o conhecimento do domínio inicia com o desenvolvimento do projeto, as mudanças acabam sendo frequentes, principalmente em cenários competitivos ou quando envolvem legislações. E, por fim, não existir urgência de prazo pode significar que o projeto não é relevante.
error_outline
Pontos de atenção na adoção do modelo cascata:
· Projetos reais raramente seguem o fluxo sequencial que o modelo propõe.
· Dificilmente, o cliente consegue estabelecer explicitamente todas as necessidades no início do projeto.
· O cliente precisa ter paciência para obter uma versão testável, uma vez que uma versão operacional fica disponível apenas muito próximo do final do projeto.
MODELO INCREMENTAL
O modelo incremental tem início com um subconjunto simples de requisitos, e incrementalmente realizam-se entregas de versões até o sistema todo estar implementado. O modelo combina elementos dos fluxos de processos lineares e paralelos.
A Figura 3, apresentada a seguir, representa o ciclo de desenvolvimento de um software proposto no modelo incremental.
Figura 3: Modelo incremental
Ciclo de desenvolvimento no modelo incremental. Fonte: Autor (2021).
Quando se usa um modelo incremental, normalmente, o primeiro incremento é um produto essencial. Ou seja, os requisitos básicos são atendidos, porém, muitos recursos complementares ou mais avançados ainda não são entregues. No planejamento do incremento, já se considera a modificação do produto essencial para se adequar às necessidades.
thumb_up_alt
Situações favoráveis para adoção do modelo incremental:
· Os requisitos de software estão bem compreendidos.
· Os requisitos de software são estáveis, ou seja, quando não mudam.
· O prazo para uso da solução não é urgente.
error_outline
Pontos de atenção na adoção do modelo incremental:
· A funcionalidade entregue para validação pode ainda não estar completa nos primeiros incrementos.
· Podem ocorrer diversas modificações em torno da mesma funcionalidade.
MODELOS EVOLUCIONÁRIOS (PROTOTIPAÇÃO E ESPIRAL)
Os modelos evolucionários surgiram da observação de que a dinâmica de software muda frequentemente (concorrência, legislação, negócios etc.), tornando inviável seguir um planejamento em linha reta, conforme proposto nos modelos anteriores.
Em diversas situações, faz-se necessário um modelo de processo que tenha sido projetado especificamente para desenvolver um produto que evolua ao longo do tempo. Ou seja, um modelo que possibilite desenvolver versões cada mais completas do software. A seguir, estão apresentados dois tipos de modelos evolucionários que apresentam estas características: a prototipação e o espiral.
PROTOTIPAÇÃO
A prototipação pode ser utilizada como um modelo de processo isolado, mas é mais comum que seja aplicada em conjunto com outro modelo de processo citado nesta Unidade, ou ainda, outros modelos de processo existentes.
A Figura 4, apresentada a seguir, representa o ciclo de desenvolvimento de um software proposto no modelo prototipação.
Figura 4: Modelo evolucionário: prototipação
Ciclo de desenvolvimento no modelo prototipação. Fonte: Autor (2021).
Normalmente, a execução do processo tem início com uma reunião para entender os requisitos gerais. O sistema é analisado e projetado de acordo com os requisitos gerais. Do projeto se constroem os protótipos, principalmente as interfaces e os layouts. Os envolvidos fornecem um retorno (feedback), que servirá para aprimorar os requisitos. Dessa maneira, o protótipo atua como um mecanismo para identificar os requisitos do software. Posteriormente, seguem as etapas para o desenvolvimento do produto definitivo.
thumb_up_alt
Situações favoráveis para adoção do modelo prototipação:
· Quando os requisitos ainda não estão claros.
· O protótipo é construído de forma rápida e ajuda a entender o que deve ser desenvolvido.
· O cliente tem uma ideia prévia do que será o sistema.
error_outline
Pontos de atenção na adoção do modelo prototipação:
· As versões iniciais são descartáveis.
· O cliente, muitas vezes, não compreende que o protótipo não é a versão final e que posteriormente o produto deverá ser reconstruído.
· O desenvolvedor pode se acomodar com os resultados provisórios e torná-los definitivos.
ESPIRAL
O modelo espiral é uma combinação de prototipação (iterativo) e etapas de processos lineares (ex.: cascata).
Analise a Figura 5, apresentada a seguir, para entender o funcionamento do modelo.
Figura 5: Modelo evolucionário: espiral
Ciclo de desenvolvimento no modelo prototipação. Fonte: PRESSMAN, R. S. ; MAXIM, B. R. (2016, p. 48).
Iniciamos pelo centro da espiral e prosseguimos no sentido horário. A primeira atividade é a especificação do software. As próximas passagens podem ser usadas para desenvolver um protótipo e, assim, sucessivamente, evoluímos para versões cada vez mais sofisticadas do software. Cada passagem resulta em ajustes no planejamento.
thumb_up_alt
Situações favoráveis para a adoção do modelo espiral:
· Quando os requisitos ainda não estão claros.
· Sistemas de larga escala.
· Combina abordagem sistemática, sugerida pelo modelo cascata, mas incorpora métodos iterativos (prototipação).
error_outline
Pontos de atenção na adoção do modelo espiral:
· É necessária boa experiência da equipe para controlar a evolução do projeto.
· Não indicado para projetos menores.
MODELO UNIFICADO
O último modelo a ser apresentado nesta Unidade é o unificado, um dos últimos modelos prescritivos a serem propostos antes da expansão dos modelos ágeis.
Na tentativa de usar os melhores recursos e características dos modelos prescritivos, mas também incorporando princípios ágeis, foi proposto o modelo unificado, por Jacobson, Rumbaugh e Booch (os três amigos, “pais” da UML), o qual usa a abordagem da orientação a objetos e notação Unified Modeling Language (UML) para mostrar o processo em ação.
As principais características deste modelo são o desenvolvimento iterativo e incremental.
Com base nesta proposta, a IBM criou o Rational Unified Process (RUP). Ele não é apenas um modelo, mas também um produto de software. Toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas.
A Figura 6, apresentada a seguir, representa as fases propostas no modelo, a intensidade de certas áreas do conhecimento (chamadas de disciplina) dada em cada fase e as iterações que podem ocorrer.
Figura 6: Modelo unificado
Ciclo de desenvolvimento no RUP (baseado no modelo unificado). Fonte: Adaptado de KRUCHTEN, 2001.
Ele é considerado um modelo pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém, o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala.
Modelos ágeis
Nesta seção, estão apresentadas brevemente algumas das informações mais relevantes sobre os métodos ágeis.Por se tratar de um assunto vasto, você poderá se aprofundar em disciplinas posteriores ou ainda buscar atividades de extensão.
Os métodos ágeis surgiram para suprir a necessidade de mudanças rápidas no processo de desenvolvimento de software, necessidade que não era atendida integralmente nos modelos prescritivos.
Os métodos ágeis seguem uma filosofia que foca principalmente nos resultados. O modelo de entrega é baseado em ciclos iterativos (integração entre as fases) e incrementais (entregas parciais).
Até a década de 90, as diretrizes eram:
· Um planejamento cuidadoso do projeto.
· Um processo de software rigoroso e controlado.
O termo método ágil surgiu durante a formação do manifesto ágil, em 2001: um grupo de 17 pessoas se reuniu para discutir sobre uma nova abordagem para a gestão de projetos de software. Ao final dessa reunião, todas as pessoas presentes assinaram o manifesto ágil.
Neste manifesto (https://agilemanifesto.org/?utm_source=angelopublio.com.br) são apresentados os valores e os princípios dos métodos ágeis. Os quatro valores principais destacados no modelo são:
1. Indivíduos e interações mais do que processos e ferramentas.
2. Software em funcionamento mais do que documentação abrangente.
3. Colaboração com o cliente mais do que negociação de contrato.
4. Responder a mudanças mais do que seguir um plano.
Os conceitos em verde negrito não anulam a existência dos conceitos em verde que não estão em negrito, apenas reforçam onde as ações devem ser focadas para obter os resultados esperados.
Ao longo do tempo, foram desenvolvidos diversos modelos de desenvolvimento de software, considerados ágeis:
· EXtreme Programming (XP).
· Scrum.
· Feature-Driven Development (FDD).
· Dynamic Systems Development Method (DSDM).
· Crystal clear.
· Adaptative Software Development (ASD).
· Kanban.
Muitos deles foram propostos muito antes do manifesto ágil. Os problemas nos modelos prescritivos já haviam sido identificados por volta da década de 80. A partir de então, as pessoas envolvidas com o processo de desenvolvimento de software iniciaram propostas de modelos que pudessem trazer mais qualidade para o processo de desenvolvimento de software. O manifesto ágil acabou sendo um momento para criar um marco que definiu uma nova era de modelos para desenvolvimento de software.
A seguir, serão apresentadas algumas das principais características dos modelos ágeis mais adotados pela indústria do software.
EXTREME PROGRAMMING (XP)
Os primeiros trabalhos relacionados ao XP tiveram início nos anos 80, bem antes do manifesto ágil (2001). Os valores principais do XP são: comunicação, simplicidade e feedback (retorno).
Neste modelo, são projetadas apenas as necessidades imediatas, sem considerar as futuras. Portanto, isso é importante muita disciplina. O XP preconiza:
· Ciclos curtos para dar previsibilidade e redução de incertezas/riscos.
· Simplicidade e melhorias constantes de código (refactoring) para facilitar a mudança.
· Testes automatizados e integração contínua para aumentar a confiança.
A Figura 7 apresenta o processo XP e destaca alguns conceitos e tarefas-chave associados às atividades.
Figura 7: Modelo XP
Representação das principais atividades e práticas propostas no modelo XP. Fonte: PRESSMAN, R. S.; MAXIM, B. R. (2016, p. 72).
O objetivo da atividade de planejamento é entender o ambiente de negócio do software, o que conduzirá para a criação de um conjunto de histórias. Cada história é estimada e priorizada e, se necessário, desmembrada em outras histórias para reduzir a granularidade. Clientes e membros da equipe trabalham em conjunto nesta atividade.
A atividade de projeto segue o princípio Keep It Simple (KIS), ou seja, em tradução livre, “mantenha a simplicidade”. Nesta atividade, é encorajado o uso dos cartões Classe-Responsabilidade-Colaborador (CRC), mecanismo que ajuda a pensar sobre o software, considerando o paradigma da orientação a objetos. Os protótipos são encorajados para reduzir riscos de estimativas com falhas. O projeto é refeito continuamente conforme o andamento do desenvolvimento e, portanto, poucos artefatos formais são produzidos, pois o projeto é visto como algo transitório.
A atividade de codificação não começa exatamente com a criação dos códigos, mas com o desenvolvimento de testes de unidades que exercitarão as histórias identificadas. Depois da criação dos testes, o desenvolvedor se dedicará à implementação do que foi aprovado no teste. Outro conceito-chave nesta atividade é a programação em duplas. Esta prática amplia a possibilidade de resolução de problemas em tempo real, aumentando a qualidade do software, uma vez que duas cabeças pensam melhor do que uma, certo?
Por fim, a atividade de testes inicia antes da codificação e é finalizada após ela. Como a codificação é derivada dos testes criados, após a codificação, os testes estão praticamente prontos para a automatização. A automatização facilita a execução diária dos testes de integração e de validação e, consequentemente, a identificação cedo dos problemas.
thumb_up_alt
Situações favoráveis para a adoção do modelo XP:
· Embora alguns digam que é mais adequado para projetos menores, há registros de sucesso em grandes projetos.
· Time entrosado e cliente próximo.
· Abertura para mudança e retrabalho (desapego de protótipos, códigos ruins).
error_outline
Pontos de atenção na adoção do modelo XP:
· Proximidade do cliente pode gerar solicitações informais, colocando em risco o planejamento de escopo/prazo e custo.
· Método de levantamento de requisitos superficial, por meio de histórias, o que pode gerar omissões e inconsistências.
SCRUM
O modelo scrum foi desenvolvido a partir dos anos 90. Os principais conceitos utilizados neste modelo são: backlog, sprints, scrum master e product owner.
A Figura 8 apresenta o fluxo geral do modelo scrum, apresentando como estes conceitos estão relacionados.
Figura 8: Modelo scrum
Representação das principais atividades e práticas propostas no modelo scrum. Fonte: PRESSMAN, R. S. ; MAXIM, B. R. (2016, p. 78).
O backlog do produto representa uma lista de requisitos priorizados que fornecem valor ao cliente. Novos itens podem ser adicionados a qualquer momento. As sprints são compostas de itens para atender aos requisitos existentes no backlog, os quais serão implementadas em um ciclo de no máximo 30 dias. As alterações não são introduzidas durante a execução das sprints.
As reuniões são diárias e curtas, de aproximadamente 15 min., para responder três perguntas:
· O que você fez desde a última reunião?
· Quais dificuldades encontrou?
· O que planeja realizar até a próxima reunião?
O líder da equipe que conduz a reunião é chamado scrum master. Outro papel muito importante no método scrum é o Product Owner (PO), que define as histórias (que serão desmembradas em funcionalidades) e prioriza o backlog de um produto de software.
Ao final da sprint, uma nova funcionalidade é entregue. Vários ciclos com este deverão ser executados para atender aos itens que compõem o backlog do produto.
Podcast
Neste podcast, é apresentada uma conversa com especialistas da área de engenharia de software, os quais contam como a área surgiu e como está sendo a sua evolução ao longo dos últimos anos.
Trilha do podcast por ©Jahzzar/freemusicarchive.org
Nesta Unidade, houve uma introdução aos principais conceitos da engenharia de software e exposição sobre os modelos de processo de desenvolvimento de software. Entendemos que os modelos foram evoluindo ao longo do tempo. Os primeiros modelos, conhecidos como prescritivos, tinham um caráter mais rigoroso na determinação de como as atividades de desenvolvimento deveriam ser executadas. No início dos anos 2000, os modelos ágeis ganharam força: eles vieram para suprir as deficiências dos modelos prescritivos, trazendo maior capacidade para acomodar as mudanças, que são naturais ao longo do desenvolvimento do software. É importante entender os motivos que embasaram o surgimento de cada modelo, as situações em que a sua aplicaçãoé mais favorável e os pontos de atenção. Assim, somos capazes de analisar as características do contexto em que estamos inseridos e escolher qual pode nos ajudar a desenvolver softwares com mais qualidade. Lembre-se: processo e qualidade são as palavras-chave da engenharia de software.
Referências
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em: https://agilemanifesto.org/?utm_source=angelopublio.com.br. Acesso em: 21 jan. 2021.
PRESSMAN, R. S. ; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/. Acesso em: 21 jan. 2021
SBROCCO, J. H. T. C.; MACEDO, P. C. Metodologias ágeis: engenharia de software sob medida. São Paulo: Editora Saraiva, 2012.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. 2. ed. Rio de Janeiro: Elsevier, 2019.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 02
Estimativa de Software
Esta Unidade apresenta as motivações e os conceitos relacionados à estimativa de software e tem início com uma visão geral das atividades de medição e os seus distintos objetivos. Na sequência, será aprofundado o entendimento da atividade de estimativa de esforço, que é muito importante no início do projeto, pois apoia o planejamento, ajudando a identificar os custos e o tempo de desenvolvimento do software. Existem várias técnicas que suportam a atividade de estimativa, desde as mais informais até as bastante estruturadas e parametrizadas. Nesta Unidade, conheceremos algumas delas e nos aprofundaremos em uma técnica muito utilizada nos métodos ágeis, que utiliza como parâmetro principal pontos de histórias do usuário.
Introdução à medição de software
No dia a dia, é comum realizarmos medições para variadas situações. Muitas vezes, nem nos damos conta de como a medição é importante para a qualidade das nossas vidas ou dos produtos e serviços que consumimos. Veja alguns exemplos do porquê medimos (Figura 1):
· Acompanhar a evolução do desenvolvimento de uma criança.
· Monitorar parâmetros de saúde.
· Desempenho em atividades físicas.
· Qualidade do atendimento de um serviço etc.
Figura 1: Motivação para a medição
Motivos para executar atividades de medição em nosso dia a dia. Fonte: Autor (2021).
Se conseguimos entender a importância da medição no nosso dia a dia, também devemos considerar que no desenvolvimento de software, a medição é essencial. Mas vamos entender melhor quais são os principais motivos para realizar atividade de medição durante um projeto de desenvolvimento de software.
Por que medir o software?
A medição no escopo de um projeto de desenvolvimento de software é essencial e pode ocorrer em momentos distintos e com objetivos distintos. Alguns motivos para executar atividades de medição são:
· Entender e aperfeiçoar o processo de desenvolvimento de software
· Melhorar a gerência de projetos, assim como o relacionamento com os clientes
· Reduzir frustações e pressões de cronograma
· Indicar a qualidade de um produto de software
· Avaliar a produtividade do processo
· Realizar estimativas
As atividades de medição de software estão bastante alinhadas com a área de qualidade de software. São atividades amplas e, conforme visto, realizadas por diversos motivos. No entanto, nesta disciplina, focaremos especificamente na atividade estimativas de esforço, cujo objetivo principal é identificar o esforço de tempo e de custo necessário para se desenvolver um software, antes da sua construção.
Essa atividade acaba sendo mais alinhada com área de planejamento e gerência de projetos. Se você possui interesse em aprofundar os conhecimentos nas demais atividades de medição, deve buscar por materiais complementares.
Estimativas de esforço
Não se pode planejar um projeto sem saber quanto tempo ele vai durar e quanto vai custar. Uma das questões fundamentais em um projeto de software é saber, antes de executá-lo, quanto esforço, em horas, dias ou meses de trabalho, será necessário para concluí-lo.
A estimativa é uma atividade desafiadora, pois é difícil saber se é possível desenvolver o produto desejado pelo cliente antes de conhecer os detalhes do projeto. Isso é uma realidade não somente na área de desenvolvimento de software. Veja um exemplo na Figura 2, apresentada a seguir, de um cliente que solicita um orçamento para a construção de uma nova casa. No início do projeto pode ocorrer de o cliente não conseguir verbalizar claramente os requisitos necessários para a sua casa, e o projetista precisar muitas vezes imaginar os desejos do cliente. Esta falta de detalhes, ou até falha de comunicação, pode levar a entendimentos diferentes.
Figura 2: O que o cliente queria, o que o projetista entendeu
Dificuldade em entender os desejos do cliente antes da execução do projeto. Fonte: Autor (2021).
Na área de desenvolvimento de software, este detalhamento inicial é ainda mais desafiador pelo fato de o software não ser um ativo físico.
Portanto, uma das coisas mais difíceis no desenvolvimento do software é estimar o tempo para o desenvolvimento. O software é um ativo intangível e de difícil visualização do produto final no início do projeto. A exatidão nas estimativas pode ser algo impossível de atingir uma vez que pode ser afetado por muitas variáveis, tais como fatores humanos, técnicos, ambientais, políticos etc.
Determinar o esforço e o custo é uma das primeiras e principais atividades relacionadas às estimativas a serem efetuadas durante o ciclo de vida do projeto. Esta área, chamada de estimativas de esforço, conta com algumas técnicas que têm apresentado resultados interessantes nos últimos anos.
Técnicas de estimativas
As técnicas de estimativa de software são utilizadas para se chegar às estimativas de custo, de produtividade, de tempo etc. Elas são fundamentais para que se obtenha sucesso em um projeto de desenvolvimento de software.
Ao longo do tempo, foram sendo propostas diversas técnicas para apoiar a atividade de estimativas. A seguir, confira alguns exemplos.
· Pontos de histórias.
· Pontos de função.
· Pontos por caso de uso.
· Constructive Cost Model (COCOMO).
· Delphi.
A maioria das técnicas de estimativas utilizam pelo menos um parâmetro como base, por isso são chamadas técnicas paramétricas. No entanto, há técnicas que não usam nenhum parâmetro, chamadas não paramétricas. Um exemplo é quando a estimativa é utilizada por um especialista. Neste caso, simplesmente pede-se a pessoas com bastante experiência em desenvolvimento de software que deem sua opinião sobre o tempo e esforço total de desenvolvimento.
Algumas técnicas se baseiam no conjunto de requisitos identificados para o projeto, como: pontos de histórias, pontos de função e pontos de caso de uso. Ao longo das próximas seções e Unidades, conheceremos a base e o funcionamento delas.
Pontos de histórias (story points)
Pontos de histórias é a estimativa preferida dos métodos ágeis. A técnica se aproxima muita da estimativa de especialista, uma vez que a equipe ágil usará hipóteses para estimar o esforço de cada história de usuário. A técnica tem a vantagem de poder ser aplicada a praticamente qualquer tipo de sistema, quantos pontos de função se aplicam mais facilmente a sistemas comerciais. Sistemas como jogos, compiladores ou aplicações matemáticas poderão apresentar grandes dificuldades para a aplicação de pontos de função.
Uma técnica bastante utilizada usando pontos de histórias é o planning poker. Nela, o líder do projeto prioriza o que deverá ser realizado primeiro, mas o time de desenvolvimento é quem decide quanto tempo levará o desenvolvimento. Há muita colaboração entre os times, o que aumenta o comprometimento. As estimativas são ajustadas ao longo do processo.
Para aplicação da técnica, é utilizado um baralho (Figura 3) e a série de Fibonacci customizada (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?) para estimar.
Saiba Mais
Para entender o detalhe do funcionamentoda técnica, consulte esse material:
https://www.luiztools.com.br/post/planning-poker-como-estimar-tempo-de-desenvolvimento-de-software/
Figura 3: Planning poker
Técnica que utiliza histórias de usuários e a escala de Fibonacci para estimativas de software. Fonte: Autor (2021).
Saiba Mais
A técnica pode ser aplicada com um baralho físico ou ainda podem ser utilizadas ferramentas virtuais para a sua aplicação. Segue o link de uma dessas ferramentas.
https://www.planitpoker.com/
Nos métodos ágeis, a importância da estimativa normalmente está na comparação entre histórias, ou seja, mais importante do que saber quantos dias uma história efetivamente levaria para ser implementada, é saber que uma história levaria duas vezes mais tempo do que outra para ser implementada.
Além do planning poker, há outras técnicas que usam pontos por histórias, uma delas é a camiseta, ou t-shirt sizes. Nesta técnica, utilizam-se valores, tais como “pequeno”, médio” e “grande”. Ficou curioso sobre o seu funcionamento? Realize uma busca pela internet!
As técnicas e as ferramentas evoluem o tempo todo, precisamos desenvolver a capacidade de pesquisar e de senso crítico para identificar quais são os instrumentos mais eficientes para o contexto que está sendo vivenciado.
Nesta Unidade, houve uma introdução às atividades de medição e apresentação do quanto elas são importantes para a qualidade do software e o planejamento do projeto. Em seguida, aprofundamos o entendimento da atividade de estimativa de esforço, que é essencial para estimar o custo e o tempo de desenvolvimento de software. Existem várias técnicas disponíveis para apoiá-la atividade, desde técnicas informais, que contam com a experiência de um especialista, conhecidas como técnicas não paramétricas, até técnicas baseadas em parâmetros, como os requisitos identificados no software a ser desenvolvido. As técnicas baseadas em parâmetros são conhecidas como paramétricas.
Referências bibliográficas
DUARTE, L. Planning poker: como estimar tempo de desenvolvimento de software. Luiz Tools, Agile, 2016. Disponível em: https://www.luiztools.com.br/post/planning-poker-como-estimar-tempo-de-desenvolvimento-de-software/. Acesso em: 26 abr. 2021.
GOMES, A. E. Métricas e estimativas de software - o início de um rally de regularidade. Linha de Código, Gerência, Estimativas, 2021. Disponível em: http://www.linhadecodigo.com.br/artigo/102/metricas-e-estimativas-de-software-o-inicio-de-um-rally-de-regularidade.aspx. Acesso em: 26 abr. 2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. 2. ed. Rio de Janeiro: Elsevier, 2019.
VIANA, J. Planning poker e pontuação de fibonacci. Agile Pink, 2019. Disponível em: https://agilepink.com/planning-poker/2019/. Acesso em: 26 abr. 2021.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 03
Estimativas de pontos de função
Nesta Unidade, conheceremos em detalhes os elementos da técnica de estimativa que utiliza pontos de função como base de contagem. Também aprenderemos como aplicar essa técnica por meio de exemplos a cada elemento apresentado. A Unidade tem início com uma breve introdução da técnica e na sequência é discutido cada elemento, como identificá-lo, como atribuir complexidade e, por fim, chegar ao ponto de função. Ao final da primeira parte, é apresentado um exemplo consolidado de um sistema para controle de vendas em uma loja de roupas, a fim de demonstrar como a contagem deve ser aplicada. Após a compreensão de como é feita a contagem de pontos não ajustados, são apresentados os fatores técnicos que ajustam a contagem de pontos a partir da complexidade técnica. Quanto maior a complexidade, maior será o total de pontos de função ajustados. Por fim, a Unidade apresenta os cálculos necessários para estimar o tempo de desenvolvimento e o custo envolvido a partir da contagem de pontos de função.
Pontos de função
A Análise de Pontos de Função (APF) é uma técnica paramétrica de estimativa de esforço para o desenvolvimento de software e usa como parâmetro os conceitos de funções de dados e funções transacionais, que basicamente correspondem aos requisitos funcionais de um sistema.
A medida coletada pela APF independe da tecnologia utilizada e/ou da linguagem de programação, em que a(s) funcionalidade(s) foi(ram) implementada(s). A técnica foi proposta em 1979, por Alan J Albrecht, quando ele pesquisava sobre produtividade na IBM. Atualmente, ela é padronizada pelo International Function Point User Group (IFPUG). Para maior aprofundamento, o site pode ser consultado: https://www.ifpug.org/.
É importante ressaltar que essa técnica é bastante utilizada em contratos com o governo. Ela pode ser aplicada para medir o tamanho de um sistema antes de desenvolvê-lo, de forma que seu custo e tempo de desenvolvimento seja previsto adequadamente. Além disso, a APF pode ser utilizada para processos de manutenção, seja de melhorias ou inclusão de novas funcionalidades, e pode ser aplicada para estimar o tamanho funcional de uma aplicação já existente, também.
De maneira geral, a técnica é aplicada de acordo com os seguintes passos:
· Determinar o tipo de contagem (novo projeto, manutenção/melhoria ou aplicação existente).
· Determinar os limites ou fronteiras da aplicação (escopo).
· Identificar e atribuir valor em pontos de função para as funções de dados.
· Identificar e atribuir valor em pontos de função para as funções transacionais.
Identificação das funcionalidades
Um ponto importante na aplicação da técnica é considerar apenas as funcionalidades que são visíveis para o usuário, uma vez que a técnica tem como ponto de partida as funcionalidades sob o ponto de vista do usuário. Portanto, não é qualquer funcionalidade que conta.
Apenas as transferências de informação para dentro e para fora da fronteira do sistema são reconhecíveis pelo usuário.
A técnica APF avalia duas naturezas de funções:
· Funções de dados
· Funções transacionais
O entendimento de cada um destes elementos é decisivo para a aplicação da técnica APF. A seguir, discutiremos em mais detalhes cada uma das funções.
Funções de dados
Conforme visto anteriormente, as funções de dados se dividem em ALIs e AIEs. A seguir, confira o que são e como identificá-los.
ALI
Um ALI pode ser considerado um elemento do modelo conceitual percebido pelo usuário e mantido pelo sistema. Um conceito bem importante neste tipo de arquivo é o de Registros Lógicos (RL), que correspondem aos subconjuntos de informações reconhecidas pelo usuário que está dentro de um ALI. Por exemplo, se um automóvel é composto por motor, carroceria e pneus, apenas o conceito automóvel é considerado um ALI. E os subconjuntos de dados contidos neste ALI são considerados RL. Assim, um ALI é uma classe, que caso participe de uma composição ou agregação, ocupa o lugar mais alto da hierarquia. Um ALI pode ter componentes, mas não ser um componente. Este entendimento é importante para a identificação da complexidade das funções de dados, tanto para ALI quanto para AIE, que veremos a seguir.
Exemplo
ALI em um contexto de uma aplicação que gerencia as vendas em uma loja de roupas:
· Cliente (dados pessoais do cliente).
· Produto (informações do produto).
· Venda (dados da venda).
AIE
Um AIE pode ser considerado um elemento do modelo conceitual percebido pelo usuário e mantido externamente por outras aplicações. Os dados obtidos por meio de web service externo à aplicação são exemplos de AIE. O conceito de RL também se aplica a AIE, ou seja, um AIE pode ser componente, mas não ser um componente.
Exemplo
AIE em um contexto de uma aplicação que gerencia as vendas em uma loja de roupas:
· Dados de crédito (web service integrado com o Serasa para identificar a situação de crédito do cliente).
· Débitos municipais (integração com a prefeiturapara obter certidão negativa de débitos).
Tabela de complexidade das funções de dados
Após a identificação de todos os ALI e dos AIE que fazem parte do escopo da aplicação, é necessário identificar a complexidade de cada arquivo. A complexidade é definida por meio da Tabela 1 (item a).
A tabela a seguir apresenta a complexidade funcional (baixa, média ou alta) para cada função de dados (ALI ou AIE) e função transacional (EE, SE e CE) de acordo com parâmetros. A tabela também apresenta para cada tipo de função (ALI, AIE, EE, SE e CE) e complexidade funcional (baixa, média ou alta) a quantidade de pontos de função não ajustados que devem ser considerados.
Tabela 1: Complexidade funcional e pontos de função não ajustados
Complexidade funcional
ALI e AIE (a)
EE (b)
SE e CE (c)
#TDE
#RL
1 a 19
20 a 50
51 ou +
1
Baixa
Baixa
Média
2 a 5
Baixa
Média
Alta
6 ou +
Média
Alta
Alta
#TDE
#AL
1 a 4
5 a 15
16 ou +
0 a 1
Baixa
Baixa
Média
2
Baixa
Média
Alta
3 ou +
Média
Alta
Alta
#TDE
#AL
1 a 5
6 a 19
20 ou +
0 a 1
Baixa
Baixa
Média
2 a 3
Baixa
Média
Alta
4 ou +
Média
Alta
Alta
Pontos de função não ajustados por tipo de função e sua complexidade (d)
Complexidade funcional
Tipo de função
Baixa
Média
Alta
ALI
7
10
15
AIE
5
7
10
EE
3
4
6
SE
4
5
7
CE
3
4
6
Fonte: O autor (2021).
Em que:
(#RL): corresponde a um subconjunto de dados reconhecível pelo usuário dentro de um ALI.
Tipo de Dado Elementar (#TDE): corresponde a uma unidade de informação (um campo) reconhecível pelo usuário. Normalmente, é um atributo em uma classe ou um campo em uma tabela.
Exemplo
No contexto de uma aplicação que gerencia as vendas em uma loja de roupas, a função de dados cliente (nome, data de nascimento, CPF, RG, estado civil, fone e e-mail) teria a classificação baixa, porque:
· Função de dados = ALI: é um elemento do modelo conceitual mantido pela aplicação.
· RL = 1: não apresenta nenhum subconjunto de dados.
· #TDE = 7: não ultrapassa de 19 campos.
Funções transacionais
As funções transacionais se dividem em EE, SE e CE. A seguir, será apresentado o que são e como identificá-los.
EE
A EE consiste em uma entrada de dados ou controle que tem como consequência a alteração do estado interno dos dados dos sistemas. Esta função tem o objetivo de incluir, alterar ou excluir dados. Caso a operação ocorra em dois passos, ou seja, a consulta de um registro e posteriormente a sua alteração, devem ser contadas duas funções, uma que será CE e outra, EE.
Exemplo
EE em um contexto de uma aplicação que gerencia as vendas em uma loja de roupas:
· Cadastrar cliente.
· Alterar cliente.
· Excluir cliente.
· Cadastrar produto.
· Alterar produto.
· Excluir produto.
Além disso, se uma entrada externa produzir um conjunto de mensagens de erros, cada mensagem conta como um argumento de entrada.
SE
Uma SE consiste em uma saída de dados que pode ser precedida ou não da entrada de parâmetros. Pelo menos um dos dados de saída deve ser derivado, ou seja, calculado. SE são funções que recuperam dados do sistema e apresentam ou usuário ou enviam à outras aplicações, sendo que pelo menos um valor calculado deve existir para ser considerado uma saída externa.
Exemplo
SE em um contexto de uma aplicação que gerencia as vendas em uma loja de roupas. Considera-se neste exemplo que é necessário informar o CPF do cliente e a partir dele, filtrar todas as vendas realizadas com um totalizador ao final.
· Relatório de vendas de um cliente com totalização.
CE
A CE é uma saída de dados que pode ser precedida ou não de entrada de parâmetros. Os dados armazenados no sistema não sofrem transformações ou cálculos. Normalmente, a consulta incluem parâmetros de entrada para localizar os objetos da consulta.
Exemplo
CE em um contexto de uma aplicação que gerencia as vendas em uma loja de roupas. Considera-se neste exemplo que é necessário informar parte da descrição de um produto e a partir do mesmo filtrar todos os produtos com descrição similar.
· Consulta de produtos por descrição.
Tabela de complexidade das funções transacionais
Após a identificação de todos os EE, SE e CE que fazem parte do escopo da aplicação, é necessário identificar a complexidade de cada transação. A complexidade é definida por meio da Tabela 1 (itens b e c).
A tabela a seguir apresenta a complexidade funcional (baixa, média ou alta) para cada função de dados (ALI ou AIE) e função transacional (EE, SE e CE), de acordo com parâmetros. A tabela também apresenta para cada tipo de função (ALI, AIE, EE, SE e CE) e complexidade funcional (baixa, média ou alta) a quantidade de pontos de função não ajustados que devem ser considerados.
Tabela 1: Complexidade funcional e pontos de função não ajustados
Complexidade funcional
ALI e AIE (a)
EE (b)
SE e CE (c)
#TDE
#RL
1 a 19
20 a 50
51 ou +
1
Baixa
Baixa
Média
2 a 5
Baixa
Média
Alta
6 ou +
Média
Alta
Alta
#TDE
#AL
1 a 4
5 a 15
16 ou +
0 a 1
Baixa
Baixa
Média
2
Baixa
Média
Alta
3 ou +
Média
Alta
Alta
#TDE
#AL
1 a 5
6 a 19
20 ou +
0 a 1
Baixa
Baixa
Média
2 a 3
Baixa
Média
Alta
4 ou +
Média
Alta
Alta
Pontos de função não ajustados por tipo de função e sua complexidade (d)
Complexidade funcional
Tipo de função
Baixa
Média
Alta
ALI
7
10
15
AIE
5
7
10
EE
3
4
6
SE
4
5
7
CE
3
4
6
Fonte: O autor (2021).
Em que:
#AL: corresponde a uma ALI ou AIE, envolvido na transação em questão.
#TDE: corresponde a uma unidade de informação (um campo) reconhecível pelo usuário. Normalmente é um atributo em uma classe ou um campo em uma tabela.
Sobre a contagem do TDE, no caso de EE podem ser os campos de entrada das informações, nas SE podem ser os campos em um relatório e nas CE podem ser os campos usados para pesquisa e os mostrados como resposta. As mensagens de erros e os botões que podem ser pressionados também podem ser contabilizados.
Exemplo
No contexto de uma aplicação que gerencia as vendas em uma loja de roupas, a função de transação relatório de vendas de um cliente com totalização poderia ter as seguintes informações:
· AL = 3, se considerarmos que o relatório envolverá a recuperação de dados nas três funções de dados: cliente, produto e venda).
· #TDE = 5 a 15, se considerarmos que no relatório serão impressas as seguintes informações: nome, CPF e fone (cliente); descrição (produto); data, qtd. de itens, valor unitário e valor total (venda).
· Logo, a complexidade desta função de transação seria igual a média.
A Figura 1 a seguir ilustra os principais elementos mobilizados para a aplicação da técnica APF.
Figura 1: Elementos a serem identificados para a aplicação da APF
Para a aplicação da APF é necessário entender e identificar os elementos considerados pela técnica. Fonte: ABREU (2011).
Pontos de Função Não Ajustados (PFN)
Após identificadas todas as funções de dados (ALI e AIE), as funções transacionais (EE, SE e CE) e suas respectivas complexidades, é o momento da identificação dos pontos gerados para cada tipo de função. A Tabela 1 (item d) apresenta a respectiva pontuação.
A tabela apresenta a complexidade funcional (baixa, média ou alta) para cada função de dados (ALI ou AIE) e função transacional (EE, SE e CE) de acordo com parâmetros. A tabela também apresenta para cada tipo de função (ALI, AIE, EE, SE e CE) e complexidade funcional (baixa, média ou alta) a quantidade de pontos de função não ajustados que devem ser considerados.
Tabela 1: Complexidade funcional e pontos de função não ajustados
Complexidade funcional
ALI e AIE (a)
EE (b)
SE e CE (c)
#TDE
#RL
1 a 19
20 a 50
51 ou +
1
Baixa
Baixa
Média
2 a 5
Baixa
Média
Alta
6 ou +
Média
Alta
Alta
#TDE
#AL
1 a 4
5 a 15
16 ou +
0 a 1
Baixa
Baixa
Média
2
Baixa
Média
Alta
3 ou +
Média
Alta
Alta
#TDE
#AL
1 a 5
6 a 19
20 ou +
0 a 1
Baixa
Baixa
Média
2 a 3
Baixa
Média
Alta
4 ou +
Média
Alta
Alta
Pontosde função não ajustados por tipo de função e sua complexidade (d)
Complexidade funcional
Tipo de função
Baixa
Média
Alta
ALI
7
10
15
AIE
5
7
10
EE
3
4
6
SE
4
5
7
CE
3
4
6
Fonte: O autor (2021).
No exemplo citado anteriormente, para a SE relatório de vendas de um cliente com totalização, cuja complexidade identificada foi média, a quantidade de pontos atribuídos a esta função seria de: cinco pontos não ajustados.
Exemplo
Sistema para gerenciar vendas em uma loja de roupas.
A seguir, vamos aplicar um exemplo consolidado a partir de um escopo definido para um sistema que gerencia vendas em uma loja de roupas.
Considere que neste exemplo, fazem parte do escopo os seguintes requisitos funcionais:
· RF1
· RF2
· RF3
· RF4
· RF5
O resultado dos pontos para cada função identificada é apresentado na Tabela 2.
Tabela 2: Exemplo de contagem em um contexto de um sistema para controle das vendas em uma loja de roupas
Função
Tipo
AL
RL
TDE
#AL
#RL
#TDE
Compl.
PFN
Cliente
ALI
Cliente
Nome, data nascimento, CPF, RG, estado civil, fone e e-mail.
1
7
Baixa
7
Produto
ALI
Produto
Código, descrição, valor e categoria.
1
4
Baixa
7
Venda
ALI
Venda,
itens da venda
Cliente, produto, valor unitário, qtd. Itens, data de venda, tipo do pagamento, número do cartão e dígito verificador.
2
8
Baixa
7
Operadora
AIE
Operadora
Nome, CPF, valor de venda, número do cartão,
Dígito verificador e status.
1
6
Baixa
5
Incluir
cliente
EE
Cliente
Nome, data nascimento, CPF, RG, estado civil, fone e e-mail.
1
7
Baixa
3
Excluir
cliente
EE
Cliente
Cpf.
1
1
Baixa
3
Alterar
cliente
EE
Cliente
Nome, data nascimento, CPF, RG, estado civil, fone e e-mail.
1
7
Baixa
3
Consultar cliente
CE
Cliente
Nome, data nascimento, CPF, RG, estado civil, fone e e-mail.
1
7
Baixa
3
Incluir produto
EE
Produto
Código, descrição, valor e categoria.
1
4
Baixa
3
Excluir produto
EE
Produto
Código.
1
1
Baixa
3
Alterar produto
EE
Produto
Código, descrição, valor e categoria.
1
4
Baixa
3
Consultar produto
CE
Produto
Código, descrição, valor e categoria.
1
4
Baixa
3
Registrar vendas
EE
Cliente, Produto,
Venda
Nome, produto, valor unitário, qtd. Itens, data venda, tipo pagamento, número do cartão e dígito verificador.
3
8
Alta
6
Validar operadora pagamento
SE
Cliente,
venda,
operadora
Nome, CPF, valor de venda, número do cartão, dígito verificador e status.
3
-
6
Média
5
Gerar relatório de Vendas
SE
Cliente,
produto,
vendas
Nome, CPF, fone, data venda, descrição do produto, valor unitário, qtd. Itens e valor de venda.
3
8
Média
5
TOTAL
66
A tabela apresenta um exemplo completo de contagem de PFN considerando os tipos de função identificados, os seus parâmetros (AL, RL e TDE) e a complexidade. Fonte: O autor (2021).
A Tabela 2 contém todas as funções de dados (ALI e AIE) e as funções transacionais (EE, SE, CE), que são possíveis de serem identificadas a partir da lista de requisitos funcionais identificados.
Para as funções de dados é necessário identificar os Registros Lógicos (RL, subconjuntos de dados) e os TDEs.
Já para as funções transacionais é necessário identificar os Arquivos Lógicos (AL, sejam internos ou externos) envolvidos na transação e os TDEs.
Após a identificação das funções de dados e funções transacionais, bem como os AL, RL e TDE, é possível identificar a complexidade de cada função (baixa, média e alta). Por fim, com as complexidades identificadas, obtém-se a quantidade de pontos de função não ajustados. A partir da soma desta pontuação, chega-se ao total de ponto não ajustados do sistema.
Assista a videoaula desta Unidade para acompanhar o passo a passo o preenchimento da Tabela 2.
Pontos de Função Ajustados (PFA)
A técnica de pontos de função sugere 14 fatores de ajuste técnico. Todos têm o mesmo peso, e a eles deve ser atribuída nota de zero a cinco, em que zero significa que o fator não tem nenhuma influência no projeto e cinco significa que o fator tem influência determinante no projeto.
As características do sistema podem influenciar na sua complexidade, variando em um intervalo de -35% a +35%, o que implica uma variação de 0,65 a 1,35. A Tabela 3 a seguir apresenta os 14 fatores e um exemplo de aplicação, em que se atribuiu o valor cinco para todos os itens, totalizando 70 pontos para os Fatores de Influência (FI).
A tabela apresenta os 14 fatores técnicos a serem considerados para ajustar a contagem de pontos de função. A tabela exemplifica uma situação em que todos os fatores foram atribuídos com valor 5, somando 70 pontos de influência técnica.
Tabela 3: Fatores técnicos e um exemplo de aplicação
Fator técnico
Ajuste
Comunicação de dados
5
Processamento distribuído
5
Performance
5
Configuração do equipamento
5
Volume de transações
5
Entrada de dados on-line
5
Interface com o usuário
5
Atualização on-line
5
Processamento complexo
5
Reusabilidade
5
Facilidade de implantação
5
Facilidade operacional
5
Múltiplos locais
5
Facilidade de mudanças (flexibilidade)
5
Σ FI
70
Fonte: O autor (2021).
Após a somatória dos fatores de influência é aplicada a fórmula para se chegar ao Fator de Complexidade Técnica (FCT).
FCT = 0,65 + (0,01 x Σ FI).
No exemplo demonstrado na Tabela 2, o FCT seria igual a:
FCT = 0,65+ (0,01 x 70).
FCT = 1,35.
Ou seja, neste caso, o ajuste dos pontos de função aumentará em 35% os pontos de PFN. Isso ocorre porque no exemplo da Tabela 3, atribuímos o valor máximo (cinco) para todos os fatores de influência.
Tendo como exemplo o caso de contagem da Tabela 2, em que o total de pontos de PFN foi de 66 pontos de função, se aplicado o FCT, o valor dos PFAs seria 89,1 pontos, em que:
PFA = PFN x FCT.
PFA = 66 x 1,35.
PFA = 89,1.
Até este passo, aprendemos a calcular os pontos de função e posteriormente aplicar o fator de complexidade técnica para chegar aos PFA. Na próxima seção, aprenderemos como a partir de um PFA calcular a duração e o custo de um projeto.
Duração e custo de um projeto
Uma vez calculado o PFA, basta multiplicá-lo pelo IP da equipe, que depende do contexto do projeto e da equipe envolvida e deve ser coletado a partir de bases históricas. Por exemplo, em um projeto em que quatro pessoas trabalharam em tempo integral em uma semana de 40 horas, o valor do esforço total da equipe é 160 horas semanais. Se naquela semana foram desenvolvidas funcionalidades referentes a 15 pontos de função, a equipe teve uma produtividade de 10,7 horas (160/15) por pontos de função. Se houver mais projetos, pode-se somar os APF do projeto e dividir pelo esforço despendido.
A coleta e a análise de uma base histórica seria o ideal para converter os APF em horas de trabalho e consequentemente o custo de desenvolvimento. Como nem sempre as empresas mantêm bases históricas de seus projetos, há algumas referências de produtividade, a partir das quais os projetos podem converter seu APF em tempo e custo.
A Tabela 4 a seguir apresenta uma destas referências para as linguagens mais populares em 2018.
Tabela 4: Índices de produtividade por linguagem de programação
Linguagem
Índice de produtividade em horas por pontos de função
Baixa
Média
Alta
Java
14
10
6
C
24
18
12
C++
18
12
6
Python
18
14
8
Visual Basic
12
8
6
C#
17
12
7
PHP
15
10
5
JavaScript
16
12
8
A tabela apresenta valores de referência para índices de produtividade, de acordo com a linguagem de programação utilizada no projeto. Fonte: O autor (2021).
Exemplo de cálculo do tempo considerando a Tabela 4 como referência.
Considere um projeto em que foram contados 10.000 pontos de função, trata-se de uma aplicação a ser desenvolvida em Java e espera-se uma alta produtividade da equipe. Segundo a Tabela 4, neste caso, 1 ponto de função equivale a seis horas de trabalho. Logo, seriam necessárias 60.000 horas de projeto.Em média, um mês corresponde a 160 horas de trabalho, logo, seriam necessários 375 desenvolvedores para realizar o trabalho em um mês.
Mas se, por exemplo, o projeto contar com 20 desenvolvedores (160 x 20 = 3.200 horas mensais), logo são necessários (60.000/3.200) 18,75 meses para a entrega do projeto.
A variação do tempo dependerá da quantidade de pessoas atuando no projeto ou o tempo necessário para a entrega. No exemplo citado anteriormente, se houvesse a necessidade de entregar o projeto em 12 meses, o cálculo para a quantidade de desenvolvedores poderia ser este:
60.000/(12 meses*160 horas mensais).
60.000/1.920 = 31,25.
Ou seja, seriam necessárias quase 32 pessoas dedicadas ao projeto para que fosse entregue em 12 meses.
Por fim, o custo médio do projeto pode ser obtido por meio da multiplicação do total de horas do projeto pelo custo médio da hora do desenvolvedor. Supondo, no caso do exemplo do projeto a ser desenvolvido em Java, que o custo médio da hora de um desenvolvedor é R$ 50,00 e o total de horas do projeto é 60.000 horas, o custo total do projeto será de aproximadamente R$ 3.000.00,00.
É importante ressaltar que estas estimativas devem ser testadas e ajustadas ao longo do tempo. Quanto maior a base histórica dos projetos desenvolvidos pela equipe, maior a assertividade dos índices de produtividade.
Conclusão
Nesta Unidade, aprendemos detalhadamente como aplicar a técnica de estimativas que utiliza como base pontos por função. Entendemos todos os elementos e os parâmetros que devem ser considerados para identificar a quantidade de pontos. Também aprendemos que esta primeira contagem não considera fatores técnicos e, portanto, em um segundo momento, estes fatores devem ser considerados para realizar o ajuste do total de pontos de função. Ao total, são 14 fatores técnicos, cujos valores atribuídos podem variar de 0 a 70, o que pode fazer com que o total de pontos finais variem de 0,65 a 1,35.
Por fim, entendemos que para calcular o tempo e o custo de desenvolvimento, deve-se multiplicar o total de pontos de função pela produtividade em horas da equipe e o custo médio da hora do desenvolvedor. A forma mais efetiva de obter a produtividade de uma equipe é manter registros históricos dos projetos desenvolvidos pela equipe. Caso a empresa não tenha esta base histórica, é possível utilizar referências que consideram a produtividade de acordo com o nível esperado de produtividade da equipe e a linguagem de programação utilizada no projeto.
Também é importante ressaltar que a contagem de pontos pode ser impactada pelo nível de detalhamento dos requisitos. No início do projeto, os requisitos podem não estar muito claros e muito menos as informações envolvidas. À medida que o projeto avança e os requisitos se tornam mais claros, é possível que a contagem precise ser ajustada.
Referências bibliográficas
ABREU, A. Análise de pontos de função na prática. Devmedia, 2011. Disponível em: https://www.devmedia.com.br/analise-de-pontos-de-funcao-na-pratica/22792. Acesso em: 15 fev. 2021.
IFPUG. IFPUG – International Function Point Group, 2021. Página inicial. Disponível em: https://www.ifpug.org/?lang=pt. Acesso em: 15 fev. 2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. Disponível em: https://integrada.minhabiblioteca.com.br/#/books/9788580555349/. Acesso em: 15 fev. 2021.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. 2. ed. Rio de Janeiro: Elsevier, 2019.
© PUCPR - Todos os direitos reservados.
Créditos | Privacidade e Proteção de Dados
Fundamentos Engenharia de Software
UNIDADE 04
Estimativas de pontos de caso de uso
Esta Unidade apresenta em detalhes os passos necessários para a aplicação da técnica estimativa pontos de caso de uso. A Unidade tem início com uma breve introdução da técnica e na sequência são apresentados os passos para a aplicação da técnica. No final da Unidade, há um exemplo completo envolvendo todos os passos, incluindo o cálculo do custo e do prazo de um projeto.
Pontos de caso de uso
A técnica de estimativa pontos de caso de uso foi proposta em 1993, por Gustav Karner. Ela foi baseada na técnica Análise por Pontos de Função (APF).
Trata-se de uma técnica para estimar o tamanho de um sistema de acordo com:
· O modo como os usuários o utilizarão.
· A complexidade de ações requeridas por cada tipo de usuário.
· Análise em alto nível dos passos necessários para a realização de cada tarefa.
A técnica permite estimar o tamanho de um sistema já na fase de levantamento de casos de uso. A aplicação da técnica é composta pelos seguintes passos:
1. Contar atores e atribuir grau de complexidade.
2. Contar casos de uso e atribuir grau de complexidade.
3. Somar total de atores com o total de casos de uso para obter PCU não ajustado.
4. Determinar complexidade do fator técnico.
5. Determinar complexidade do fator ambiental.
6. Calcular o total de PCU ajustado.
A seguir, confira detalhadamente cada passo da aplicação da técnica.
Contagem de atores
Neste passo devem ser contados os atores identificados em um contexto e os pesos atribuídos de acordo com o tipo de ator. A Tabela 1 apresenta os três tipos de atores possíveis, o peso que deve ser atribuído e uma descrição referente ao que caracteriza cada um dos tipos.
Tabela 1: Pesos para os tipos de atores
Tipo de ator
Peso
Descrição
Simples
1
Um sistema externo com API programável. Ator com interface bem definida e reação previsível de entrada (software).
Médio
2
Atores interagindo com o sistema por meio de algum protocolo. Um sistema externo que se comunica por um protocolo (TCP/IP etc.) (hardware).
Complexo
3
Ator humano que interage com o sistema por meio de interface gráfica (GUI) ou página web. Esse tipo de ator é difícil de controlar e imprevisível (humano).
A tabela representa os tipos de atores possíveis e os pesos que devem ser atribuídos a cada um. O peso representa o grau de complexidade do tipo de ator. Fonte: O autor (2021).
Um ator do tipo simples é do tipo software. Ele é uma aplicação externa à aplicação. Para cada um, deve ser atribuído o peso um, que representa a complexidade do ator.
Já o ator do tipo médio é normalmente do tipo hardware. Ele geralmente é uma aplicação que se comunica com equipamentos externos e precisa do uso de protocolos específicos. A conexão com sensores para captação de dados externos pode ser classificada como sendo deste tipo. Para cada um, deve ser atribuído o peso dois.
Por fim, o ator do tipo complexo é humano. Ele é tido como o mais complexo, pois suas ações podem ser imprevisíveis. Para cada um, deve ser atribuído o peso três.
Após a contagem dos atores e a sua atribuição de complexidade, obtém-se o Total de Pontos Não Ajustados para Atores (TPNAA).
Contagem de casos de uso
Assim como na contagem dos atores, na contagem dos casos de uso é necessário realizar a atribuição de peso para representar a complexidade do tipo de caso de uso. A Tabela 2 apresenta os três tipos de casos de uso possíveis, o peso que deve ser atribuído e uma descrição referente ao que caracteriza cada um dos três tipos de casos de uso.
Tabela 2: Pesos para os tipos de casos de uso
Tipo de caso de uso
Peso
Descrição
Simples
5
Até três cenários ou caminhos, incluindo os passos alternativos, e envolve menos de cinco classes.
Médio
10
De quatro a sete cenários, incluindo os passos alternativos, e envolve de cinco a dez classes.
Complexo
15
Oito cenários ou mais, incluindo os passos alternativos, e envolve pelo menos dez classes.
A tabela representa os tipos de casos de uso possíveis e os pesos que devem ser atribuídos a cada um. O peso representa o grau de complexidade do tipo de caso de uso. Fonte: O autor (2021).
Um caso de uso simples é caracterizado por não envolver mais do que três passos na descrição do seu respectivo cenário, incluindo os passos alternativos. Também é utilizado como parâmetro para a classificação o número de classes envolvidas na transação, que neste casosão menos de cinco classes. Para cada caso de uso deste tipo deve ser atribuído o peso cinco, que representa a complexidade do caso de uso.
Já o caso de uso médio é caracterizado por envolver entre quatro e sete passos na descrição do seu respectivo cenário, incluindo os passos alternativos. Com relação às classes, caracterizam-se como casos de uso médio o envolvimento entre cinco e dez classes. Para cada caso de uso deste tipo deve ser atribuído o peso dez, que representa a complexidade do caso de uso.
Por fim, o caso de uso complexo é caracterizado por envolver oito ou mais passos na descrição do seu respectivo cenário, incluindo os passos alternativos. Com relação às classes, caracterizam-se como casos de uso complexo o envolvimento de 11 ou mais classes. Para cada caso de uso deste tipo deve ser atribuído o peso 15, que representa a sua complexidade.
Após a contagem dos casos de uso e a sua atribuição de complexidade, obtém-se o Total de Pontos Não Ajustados para Casos de Uso (TPNAC).
Total dos Pontos Não Ajustados (TPNA)
Neste passo, é realizada a soma dos pontos obtidos na contagem dos atores e na contagem dos casos de uso.
· TPNAA +
· TPNAC =
· TPNA
Fator de Complexidade Técnica (FCT)
Até este passo, foram realizadas as contagens sem considerar fatores de ajuste.
Neste e no próximo passo serão calculados os fatores técnicos e os fatores de ambiente para posterior ajuste do total de pontos identificados até o momento.
O cálculo de fatores técnicos cobre uma série de requisitos não funcionais do sistema, enquanto o cálculo de fatores de ambiente envolve aspectos comportamentais que indicam a eficiência do projeto e estão relacionados ao nível de experiência dos profissionais.
O cálculo do fator de complexidade técnica é realizado mediante o preenchimento da Tabela 3, colunas influência e resultado. Ao total, são 13 fatores que possuem pesos fixos. Para cada um deles, a coluna influência deve ser preenchida com valores variando de 0 a 5, em que:
· 0 = irrelevante.
· 1 = mínima.
· 2 = moderada.
· 3 = média.
· 4 = significativa.
· 5 = essencial.
Tabela 3: Fatores de complexidade técnica
Fator
Descrição
Peso
Influência
Resultado
T1
Sistema distribuído
2
T2
Tempo de resposta
1
T3
Eficiência do usuário final (on-line)
1
T4
Processamento interno complexo
1
T5
Reusabilidade do código em outras aplicações
1
T6
Facilidade de instalação
0,5
T7
Usabilidade
0,5
T8
Portabilidade
2
T9
Facilidade de manutenção
1
T10
Concorrência
1
T11
Características especiais de segurança
1
T12
Acesso direto para terceiros
1
T13
Facilidades especiais de treinamento
1
TFactor
A tabela apresenta os 13 fatores e seus respectivos pesos a serem considerados no cálculo da complexidade técnica. Fonte: O autor (2021).
Para obter o valor da coluna resultado, deve-se multiplicar o valor da coluna peso com o valor da coluna influência.
A somatória da coluna resultado representa o TFactor, a partir do qual é possível calcular o FCT, obtido por meio da seguinte fórmula:
A Tabela 4 apresenta um exemplo em que foram preenchidos valores para a coluna influência e realizado o cálculo da coluna resultado. Posteriormente, foi obtido o valor TFator = 19,5 (soma da coluna resultado).
Tabela 4: Exemplo do cálculo do TFator
Fator
Descrição
Peso
Influência
Resultado
T1
Sistema distribuído
2
1
2
T2
Tempo de resposta
1
3
3
T3
Eficiência do usuário final (on-line)
1
3
3
T4
Processamento interno complexo
1
3
3
T5
Reusabilidade do código em outras aplicações
1
3
3
T6
Facilidade de instalação
0,5
0
0
T7
Usabilidade
0,5
5
2,5
T8
Portabilidade
2
0
0
T9
Facilidade de manutenção
1
3
3
T10
Concorrência
1
0
0
T11
Características especiais de segurança
1
0
0
T12
Acesso direto para terceiros
1
0
0
T13
Facilidades especiais de treinamento
1
0
0
TFactor
19,5
A tabela apresenta um exemplo de preenchimento dos fatores de complexidade técnica e o resultado obtido para TFator. Fonte: O autor (2021).
Neste exemplo, ao aplicar o valor de TFator, temos o seguinte resultado para o fator de complexidade técnica:
FCT = 0.6 + (0.01 × 19,5).
FCT = 0,795.
Este exemplo representa uma situação em que os fatores técnicos não apresentam influências majoritariamente essenciais, portanto, se fosse considerar apenas este fator de ajuste, a contagem de pontos poderia ser reduzida a 79,5% do seu valor inicial. É importante observar que conforme os valores de influência aumentam, o total da contagem de pontos também. Assim, a contagem inicial dos pontos pode variar de 60% a 130%, após a aplicação do fator de ajuste.
Será apresentado na próxima seção o fator de complexidade de ambiente.
Após o cálculo destes dois fatores, é possível ajustar definitivamente o TPNA identificado nos passos anteriores.
Fator de complexidade de ambiente (FCA)
O cálculo do fator de complexidade de ambiente é realizado mediante o preenchimento da Tabela 5, colunas influência e resultado. Ao total, são oito fatores que possuem pesos fixos. O preenchimento da coluna influência segue a mesma graduação dos fatores de complexidade técnica (0-5).
Tabela 5: Fatores de complexidade de ambiente
Fator
Descrição
Peso
Influência
Resultado
F1
Familiaridade com o processo de desenvolvimento
1,5
5
7,5
F2
Experiência na aplicação
0,5
5
2,5
F3
Experiência com OO, na linguagem e na técnica de desenvolvimento
1
5
5
F4
Capacidade do líder de análise
0,5
5
2,5
F5
Motivação
1
5
5
F6
Requisitos estáveis
2
2
4
F7
Trabalhadores com dedicação parcial
-1
5
-5
F8
Dificuldade da linguagem de programação
-1
0
0
EFactor
21,5
A tabela apresenta os 13 fatores e seus respectivos pesos a serem considerados no cálculo da complexidade técnica. Fonte: O autor (2021).
Para obter o valor da coluna resultado, deve-se multiplicar o valor da coluna peso com o valor da coluna influência.
A somatória da coluna resultado representa o EFactor, a partir do qual é possível calcular o FCA, que resulta da seguinte fórmula:
A Tabela 6 apresenta um exemplo em que foram preenchidos valores para a coluna influência e realizado o cálculo da coluna resultado. Posteriormente, foi obtido o valor EFator = 21,05 (soma da coluna resultado).
Tabela 6: Exemplo do cálculo de complexidade de ambiente
Fator
Descrição
Peso
Influência
Resultado
F1
Familiaridade com o processo de desenvolvimento
1,5
5
7,5
F2
Experiência na aplicação
0,5
5
2,5
F3
Experiência com OO, na linguagem e na técnica de desenvolvimento
1
5
5
F4
Capacidade do líder de análise
0,5
5
2,5
F5
Motivação
1
5
5
F6
Requisitos estáveis
2
2
4
F7
Trabalhadores com dedicação parcial
-1
5
-5
F8
Dificuldade da linguagem de programação
-1
0
0
EFactor
21,5
A tabela apresenta um exemplo de preenchimento dos fatores de complexidade de ambiente e o resultado obtido para EFator. Fonte: O autor (2021).
Neste exemplo, ao aplicar o valor de EFator, temos o seguinte resultado para o FCA:
FCA = 1.4 + (-0.03 × 21,05).
FCA = 0,755.
Este exemplo representa uma situação em que os fatores de ambientes são favoráveis, portanto, se fosse considerar apenas este fator de ajuste, a contagem de pontos poderia ser reduzida a 75,5% do seu valor inicial. É importante observar que conforme os valores de influência, o total da contagem de pontos varia para cima ou para baixo. Neste sentido, a contagem inicial dos pontos pode variar de 42,5% a 170% após a aplicação do fator de ajuste.
Total dos pontos ajustados (TPA)
Agora que já calculamos os fatores técnicos e os fatores de ambiente, é possível realizar o ajuste dos pontos calculado no passo 3, TPNAMais conteúdos dessa disciplina
EXERCICIO 4 DGT0187 CIENCIAS E EDUCACAO AMBIENTAL- EXERCICIO 3 DGT0187 CIENCIAS E EDUCACAO AMBIENTAL
- EXERCICIO 2 DGT0187 CIENCIAS E EDUCACAO AMBIENTAL
- Projeto ágil
- Engenharia de Software Apostila 001
- ciclo_de_vida
- PS0056E0077
- tecnologia de informação
- Simulado2 GABARITO 2 1,0pontos DGT 0958 SEMINARIOS EM SAUDE, AMBIENTE E SOCIEDADE
- Livro
- Portfolio Individual - Projeto Integrado Inovação - Análise e Desenvolvimento de Sistemas
- gabarito prova av
- PERGUNTA 6 Para organizar O código JavaScript em projetos móveis multiplataforma, recomenda-se: a. Arquivos únicos gigantescos. b. Código em linha exc
- PERGUNTA 3 Qual ferramenta auxilia no gerenciamento das dependências em projetos JavaScript móveis? a. Maven. b. NuGet. C. Npm. d. Docker. e. Composer
- estando no começo mais relacionado à ideia de uma natureza intocada e alheia ao ser humano. Contudo, o conhecimento acerca dela foi sendo aprimorad...
- Ela está relacionada a forma com que o homem se relaciona com o meio ambiente rural.
Ela está relacionada somente aos impactos positivos que os ser...
- Nessa reportagem, podemos entender um pouco da importância de se mudar hábitos e transformar o nosso entorno com práticas mais sustentáveis.
Indiqu...
- Qual destes princípios foi definido na Conferência Internacional de Educação Ambiental em Tbilisi?
Formação de cidadão, interdisciplinaridade e vis...
- Esse projeto constitui uma determinação que vem sendo cumprida a partir dos direcionamentos de qual documento?
Política Nacional da Educação Ambien...
- A educação ambiental passou a ter maior visibilidade em 1983 com a criação de um órgão da ONU que trouxe maior clareza na ideia do desenvolvimento ...
- Que organização governamental brasileira foi responsável pela elaboração do Pangea?
Organização das Nações Unidas (ONU).
Instituto Brasileiro de Me...
- Sobre a integração entre métodos ágeis e tradicionais, a aula destaca que: a. Deve-se evitar qualquer mistura entre metodologias b. A melhoria contínu
- Sobre os defeitos da solda, é possível afirmar: Clique na sua resposta abaixo A inclusão de escória é um defeito oriundo das chapas com um alto grau d
- compreender o funcionamento tecnológico de sistema por meio da análise da função, estrutura e operação, realizando a manutenção ou desenvolvimento ...
- esquisa Operacional Um problema de árvore mínima consiste em interligar todos os nós de uma rede com O menor custo total possível. Considere O seguint
- (AS IV) ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES
- Apostila auto cad 3
