Qualidade de Software

Prévia do material em texto

Itens iniciais
Propósito
Compreender os principais modelos de processos de desenvolvimento de software (processo unificado, Extreme Programming, Scrum e processo unificado ágil), suas aplicações, etapas e atividades, conhecimentos indispensáveis ao engenheiro de software.
Objetivos
· Descrever os modelos prescritivos de processo de desenvolvimento de software
· Explicar o Processo Unificado para o desenvolvimento de software
· Explicar o processo de desenvolvimento ágil Extreme Programming (XP)
· Explicar o processo de desenvolvimento ágil SCRUM e o Processo Unificado Ágil (AUP)
Introdução
O software apresenta um destaque cada vez maior na vida moderna. Uma tendência que ratifica essa importância está no uso intensivo dos smartphones. O sucesso dessa tecnologia, não descartando a relevância do hardware, tem um forte respaldo na competência do software, isto é, interfaces com designs atraentes, responsivas, usabilidade intuitiva, entre outras características.
 
Por trás desta competência, temos vários especialistas, tais como: engenheiros de software, web designers, administradores de banco de dados, arquitetos de software e outros que trabalham arduamente para manutenção desse sucesso exponencial. Esta equipe tem uma composição multidisciplinar, refletindo uma característica do software: a complexidade. O trato dessa complexidade requer a aplicação da Engenharia de Software que, por sua vez, tem como base a camada de processos. Dito isso, podemos afirmar que não existe engenharia sem processo.
 
Nesse contexto, é essencial conhecermos os principais modelos de processos de desenvolvimento de software, cuja escolha depende de forma significativa da sua complexidade, pois quanto mais complexo, mais formalismo deve estar embutido no modelo adotado.
Modelos prescritivos de processo de desenvolvimento de software
Engenharia de software
Os modelos de Processo de Desenvolvimento de Software têm este como principal produto no contexto da Engenharia de Software.
Diferentemente de produtos de outras engenharias, o software possui alta volatilidade em função dos requisitos, visto que é constantemente impactado pelas evoluções na tecnologia, fatores estes que agregam a ele uma complexidade adicional.
A melhor tratativa para a complexidade é a aplicação de metodologia que permita a decomposição do problema em outros menores e de forma sistemática, cabendo à Engenharia de Software tal sistematização.
 
A Engenharia de Software é uma tecnologia em camadas, então vejamos as descrições de tais camadas:
Camada de qualidade
Garante o cumprimento dos requisitos que atendem às expectativas dos usuários.
Camada de processo
Determina as etapas de desenvolvimento do software.
Camada de métodos
Define, por exemplo, as técnicas de levantamento de requisitos, os artefatos gerados em função da técnica de modelagem adotada, tais como modelos de casos de uso ou de classes.
Camada de ferramentas
Estimula a utilização de ferramentas “CASE” (Computer-Aided Software Engineering) no desenho dos diversos artefatos ou mesmo na geração automática de código, entre outras aplicações.
Vale destacar que a base da Engenharia de Software é a camada de processo.
Processo de desenvolvimento de software
O processo de desenvolvimento de software é iniciado com especificações e modelos com alto nível de abstração e, à medida que o desenvolvimento de software se aproxima da codificação, o nível de abstração diminui, de modo que o código representa o nível mais baixo da abstração ou de maior detalhamento na especificação do software.
 
As atividades típicas que compõem o processo de desenvolvimento de software, descritas por Pressman (2016), estão representadas na Figura 1. O objetivo é ilustrar as atividades mais comuns que compõem os processos de desenvolvimento de software, ou seja, as atividades genéricas incorporadas por qualquer processo, sendo uma notória diferença entre os modelos, a ênfase dada a cada atividade.
Figura 1 – Atividades Típicas de um Processo de Desenvolvimento de Software.
Vamos agora descrever cada uma das atividades comumente previstas em um processo de desenvolvimento de software:
Comunicação
As primeiras atividades de um processo de software requerem uma comunicação intensiva com os usuários, buscando o entendimento do problema, a definição de objetivos para o projeto, bem como a identificação de requisitos.
Planejamento
Destaca-se, nesta atividade, a área de conhecimento e gerenciamento de projeto, que permitirá a elaboração de um Plano de Gerenciamento do Projeto de forma sistemática, tendo como entrega importante, o cronograma que inclui as atividades a serem desenvolvidas nesse projeto.
Modelagem
A engenharia tem como melhor prática a geração de modelos, tal como a planta baixa de uma casa, e a maioria desses modelos gráficos, denominados de diagramas na Engenharia de Software, podendo ser complementados por descrições textuais, assim como o modelo de casos de uso.
Construção
A partir dos modelos gerados, é realizada a construção ou implementação do software, portanto, os modelos determinam o comportamento deste. Essa atividade inclui a codificação e os testes de software de acordo com o planejado.
Entrega
Ao final, ocorre o objetivo de um plano de projeto de software, i.e., a entrega do produto em produção de acordo com o planejado.
Modelos de processos prescritivos
A Engenharia de Software permite sistematizar o desenvolvimento de software por meio de processos. Nesse sentido, um modelo de processo identifica as atividades que serão desenvolvidas, sendo comumente utilizadas as atividades ilustradas na figura anterior.
 
Podemos, então, afirmar que um modelo de processo sistematiza o trabalho de engenharia de software, incluindo as atividades, fluxos de processos, artefatos gerados e outros, propiciando, também, estabilidade, controle e organização ao referido trabalho.
O que diferencia os modelos de processos? Embora todas as atividades típicas sejam utilizadas em todos os modelos, cada representação enfatiza de forma diferente cada atividade, e o encadeamento dessas ações — talvez o mais importante — é denominado de fluxo de processo.
O primeiro conjunto de modelos que abordaremos são os denominados modelos de processos prescritivos, por prescreverem metodologias, tarefas, artefatos, garantia da qualidade e mecanismos de controle de mudanças, ou seja, um conjunto de elementos de processo.
Modelo em cascata
O modelo em cascata sugere uma abordagem sequencial, isto é, a execução das atividades ilustradas na Figura 1 de forma encadeada. Este é o modelo de processo mais antigo da engenharia de software e utilizado de forma intensa à época em que o paradigma de desenvolvimento estruturado era dominante na indústria de software.
 
Podemos descrever algumas características negativas relativas a esse modelo, tais como:
 
· Projetos reais raramente seguem um fluxo sequencial, em função da volatilidade dos requisitos.
· Assume que é possível ao cliente explicitar detalhadamente todas as suas necessidades em forma de requisitos, antes do início das demais fases do desenvolvimento, aumentando a possibilidade de propagação de erros pelas fases do processo.
· Inflexibilidade na divisão do projeto em fases distintas, visto que uma versão do software somente estará disponível ao final do projeto.
Dica
Podemos aplicar o modelo em cascata em projetos com requisitos fixos e de forma que o fluxo de trabalho possa ser realizado sequencialmente até o seu encerramento.
Modelos de processo incremental e Modelos de processo evolucionário
Ambos os modelos dividem o desenvolvimento de um produto de software em ciclos, e cada ciclo de desenvolvimento inclui todas as atividades contidas na figura anterior.
 
Podemos observar na Figura 2 a repetição, a cada incremento e de forma iterativa, das atividades típicas de um processo de software. Cada iteração considera um subconjunto de requisitos, ocorrendo uma entrega a cada final de ciclo, isto é, a cada novo incremento um novo conjunto de funcionalidades é disponibilizado ao usuário final.Tais custos podem ser denominados de custos de falhas internas, ou seja, erros identificados antes da entrega do software ao cliente, e custos de falhas externas, associados aos erros identificados após a referida entrega.
Quanto mais cedo ocorrer a identificação de um defeito, menor o custo.
Resumindo
Neste módulo, destacamos a importância da qualidade no contexto da engenharia de software. Vimos que a qualidade de software possui duas dimensões: processo e produto.
A qualidade do processo exige a definição prévia de um processo de desenvolvimento de software que viabilize a sua aplicação.
Nessa dimensão, são aplicados os testes de verificação nos artefatos gerados nas diversas etapas do processo de software, com o objetivo de impedir a propagação de defeitos nas etapas posteriores do referido processo.
A qualidade do produto é aplicada ao software na etapa de codificação do processo de software. A partir de um plano de testes, são aplicados os testes de validação ou testes de software, que validam desde a estrutura interna de uma unidade de software até as funcionalidades por parte dos usuários.
Atenção
Lembre-se de que um sistema de qualidade tem um custo associado à conformidade, ou seja, à obtenção da garantia da qualidade do software, tendo, também, um custo associado à não conformidade, ou seja, à falta de qualidade do software.
Agora é com você! Vamos verificar se atingimos o objetivo deste módulo? Você está convidado a realizar as atividades a seguir.
Verificando o aprendizado
Parte superior do formulário
1. Considerando os conceitos relacionados com a qualidade de software, preencha as lacunas nas afirmações abaixo.
1) ______________ é um lapso humano que resulta em um software incorreto.
2) ______________ é uma anomalia no produto.
3) ______________ ocorre quando uma unidade funcional de um sistema relacionado a um software não mais consegue desempenhar as funções necessárias ou deixa de operar dentro dos limites especificados.
As lacunas estão correta e respectivamente preenchidas em:
Erro - Falha - Defeito
Erro - Defeito - Falha
Defeito - Erro - Falha
Defeito - Falha - Erro
Falha - Erro - Defeito
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
Um erro é uma diferença detectada entre o resultado de uma computação e o resultado correto ou esperado, ou seja, um problema introduzido no software pelo programador. Defeito é uma manifestação de um erro no software e pode acarretar uma falha. Uma falha é o resultado errado provocado por um defeito ou condição inesperada, causando a suspensão da execução normal do software.
Parte superior do formulário
2. (Petrobras Transporte SA ‒Transpetro ‒ Analista de Sistemas ‒ Negócios ‒ CESGRANRIO ‒ 2018). O custo da qualidade inclui todos os custos feitos na busca da qualidade, dividindo-se em custos de prevenção, de avaliação e de falha, interna e externa. Entre os custos de prevenção está o das atividades de:
Testes e depuração
Coleta de dados e métricas de avaliação
Retrabalho necessárias para corrigir o erro
Condução de revisões técnicas para os produtos de engenharia de software
Gerência para planejar e coordenar todas as atividades de controle e garantia de qualidade
Parte inferior do formulário
Comentário
Parabéns! A alternativa "E" está correta.
Os custos de prevenção são caracterizados pelos esforços que a equipe de qualidade aplica na tentativa de evitar que o processo de desenvolvimento de software ou o software não apresentem defeitos, incluindo os custos relacionados com o planejamento da qualidade.
Avalie este módulo:
 
    
MÓDULO 2
Explicar o processo da garantia de qualidade de software
Processo de garantia da qualidade
Um sistema de garantia da qualidade de software, também denominado SQA (Software Quality Assurance), pode ser definido como a estrutura organizacional com responsabilidades, procedimentos, processos e recursos para implementação da gestão da qualidade, garantindo que os produtos e serviços de uma determinada organização satisfaçam às expectativas do cliente por meio do atendimento às suas especificações.
O processo de garantia de qualidade de software, parte do referido sistema, inclui a definição e seleção de padrões que devem ser aplicados ao processo de desenvolvimento de software ou ao produto de software, podendo ocorrer a seleção de ferramentas e métodos, como apoio a esses padrões.
Atenção
A equipe de qualidade deve examinar o software sob o ponto de vista do cliente, assertiva alinhada com a máxima de que “A qualidade é conformidade aos requisitos”, ou seja, o software deve atender às necessidades do cliente.
A garantia da qualidade de software é composta pelas atividades que se concentram na gestão da qualidade de software. Vejamos algumas:
Clique nas barras para ver as informações.
Padrões
Os padrões, tal como os estabelecidos pela ISO, podem ser adotados pela equipe de Engenharia de Software ou determinados pelo cliente, cabendo à equipe de qualidade garantir que esses padrões sejam aplicados e que todas as entregas estejam em conformidade aos mesmos.
Revisões e auditorias
As revisões técnicas permitem a identificação de erros nos diversos artefatos gerados, sendo as auditorias usualmente aplicadas na verificação da conformidade de processos com os respectivos procedimentos, tal como a verificação do processo de revisão, a fim de garantir que as revisões estejam sendo eficazes na descoberta de erros.
Testes
Os testes de software têm como finalidade a descoberta de erros, cabendo à equipe de qualidade garantir que os planos de testes sejam implementados e executados na consecução do citado objetivo básico.
Coleta e análise de erros/defeitos
Considerando a máxima de que “Não se controla o que não se mede”, a equipe de qualidade deverá realizar a análise de erros e defeitos, propondo melhorias de procedimentos.
Gerenciamento de mudanças
Considerando a alta volatilidade de requisitos e as evoluções tecnológicas constantes, cabe à equipe de qualidade o estabelecimento de procedimentos relacionados com a gestão de mudanças.
Educação
A equipe de qualidade deverá realizar a gestão de programas educacionais a fim de permitir o aperfeiçoamento da equipe de desenvolvimento.
Gerência dos fornecedores
Cabe à equipe de qualidade, no caso de aquisição de software, incorporar exigências de qualidade como parte de qualquer contrato com um fornecedor externo.
Administração da segurança
Inclui, entre outros, a proteção de dados em todos os níveis, a implantação de firewalls e a garantia de que o software não tenha sido alterado internamente, sem autorização, cabendo à equipe de qualidade o emprego de processos e tecnologias apropriadas.
Proteção
O impacto de defeitos ocultos pode ser catastrófico, tal como no nosso exemplo da aeronave com 500 pessoas, cabendo à equipe de qualidade avaliar o impacto de falhas de software e as respectivas tratativas em relação à redução de riscos.
Administração de riscos
A gestão de riscos é responsabilidade da equipe de desenvolvimento, cabendo à equipe de qualidade garantir que essa gestão seja conduzida de forma apropriada e que planos de contingência estejam estabelecidos.
Padrões de software
Vamos entender os tipos de padrões de software que podem ser estabelecidos pela equipe de qualidade:
Inclui padrões de documentação, tal como um cabeçalho de comentário padronizado para uma definição de uma classe que permitirá instanciar objetos, e padrões de codificação, que definem como uma linguagem de programação deve ser usada.
Definem os processos que devem ser seguidos durante o desenvolvimento de software, tal como o processo da engenharia de requisitos, e uma descrição dos documentos que devem ser escritos ao longo desses processos.
Você se lembra da Figura 3, apresentada no módulo 1? Reveja:
Figura 3 novamente – Gerenciamento de qualidade versus processo de desenvolvimento.
Fonte: O Autor.
Ela ilustra o relacionamento entre os padrões de produto e de processo. Os padrões de produto aplicam-se à saída do processo de software e, em muitos casos, ospadrões de processo incluem atividades de processo específicas que asseguram que os padrões de produto sejam seguidos.
Podemos destacar alguns aspectos relacionados aos padrões de software:
Incluem melhores práticas, evitando a repetição de erros
Provêm um framework para a implementação do processo de garantia de qualidade, assegurando que essas melhores práticas sejam cumpridas
Permitem a continuidade quando da ocorrência de substituições na equipe
A equipe de qualidade deve gerar, podendo ter como base modelos de padrões nacionais e internacionais, os padrões necessários para sua organização. Recomenda-se que esse trabalho inclua o envolvimento da equipe de desenvolvimento, uma sistemática revisão dos padrões e a disponibilização de ferramentas CASE de apoio aos padrões.
A aplicação de um determinado processo de desenvolvimento de software depende fortemente da complexidade do escopo do problema, de modo que poderão ser utilizados diferentes tipos de processos de software em uma organização, impactando o processo de garantia da qualidade. Do exposto, a equipe de desenvolvimento deve ter a autoridade de modificar os padrões de processo de acordo com as circunstâncias de cada projeto em comum acordo com a equipe de qualidade; importante ressaltar a possibilidade de alterações nos padrões existentes, ou até mesmo a inclusão de novos padrões.
Padrões ISO 9000
Vejamos agora um exemplo de padrão de processo internacional e vamos entender de forma simplificada como pode ocorrer a sua adoção por parte de uma empresa.
ISO 9000 é um conjunto internacional de padrões aplicados a um sistema de gerenciamento de qualidade genérico, podendo ser aplicado na indústria de manufatura, na indústria de serviço e outros.
O padrão ISO 9001 não é especificamente voltado para desenvolvimento de software, mas possui uma interpretação denominada ISO 9000-3 que estabelece princípios gerais que podem ser aplicados ao software.
As necessidades delineadas pelos tópicos da ISO 9001 são:
· Responsabilidade administrativa.
· Um sistema de qualidade.
· Revisão contratada.
· Controle de projeto.
· Controle de dados e documentos.
· Identificação e rastreabilidade de produtos.
· Controle de processos.
· Inspeções e testes.
· Ações preventivas e corretivas.
· Registros de controle de qualidade.
· Auditorias de qualidade internas.
· Treinamento.
· Manutenção.
· Técnicas estatísticas.
Atenção
Uma organização de software que busque uma certificação ISO 9001 tem de estabelecer políticas e procedimentos para atender a cada uma das necessidades citadas, bem como ser capaz de demonstrar que tais políticas e procedimentos estão sendo seguidos. A certificação é um indicador da seriedade de como uma organização trata a qualidade.
Os relacionamentos entre o padrão ISO 9000, o manual de qualidade e os planos de qualidade de projeto individual, de acordo com Sommerville (2019), são mostrados na Figura 6. O manual de qualidade, ou Plano SQA, aplica os elementos básicos do padrão ISO 9000. Cada projeto instancia um plano de qualidade a partir do referido manual e de acordo com o processo de desenvolvimento de software adotado. O manual determina o processo de qualidade da organização, que devidamente adaptado a cada novo projeto, permite a implantação do gerenciamento de qualidade de cada projeto instanciado.
Figura 6 – ISO 9000 versus gerenciamento da qualidade.
Fonte: O Autor.
Agora, assista ao vídeo sobre o padrão ISO 9000 e sua aplicabilidade à qualidade de software:
Padrão ISO 9126
Vejamos agora um exemplo de padrão de produto disponível para adoção em um projeto de software. O padrão ISO 9126 foi desenvolvido como uma tentativa de identificar os atributos fundamentais de qualidade para software. O padrão identifica seis atributos fundamentais de qualidade:
Clique nas barras para ver as informações.
Funcionalidade
O grau com que o software satisfaz às necessidades declaradas conforme indicado pelos subatributos adequabilidade, exatidão, interoperabilidade, conformidade e segurança.
Confiabilidade
Quantidade de tempo que o software fica disponível para uso conforme indicado pelos subatributos maturidade, tolerância a falhas, facilidade de recuperação.
Usabilidade
Grau de facilidade de utilização do software conforme indicado pelos subatributos facilidade de compreensão, facilidade de aprendizagem, operabilidade.
Eficiência
O grau de otimização do uso, pelo software, dos recursos do sistema conforme indicado pelos subatributos comportamento em relação ao tempo, comportamento em relação aos recursos.
Facilidade de manutenção
A facilidade com a qual uma correção pode ser realizada no software conforme indicado pelos subatributos facilidade de análise, facilidade de realização de mudanças, estabilidade, testabilidade.
Portabilidade
A facilidade com a qual um software pode ser transposto de um ambiente a outro conforme indicado pelos subatributos adaptabilidade, facilidade de instalação, conformidade, facilidade de substituição.
Gerenciamento da qualidade de acordo com o PMBOK
Vamos agora entender o gerenciamento da qualidade segundo o PMBOK (2017).
Uma das dez áreas de conhecimento do PMBOK é o Gerenciamento da Qualidade do Projeto que inclui os processos para incorporação da política de qualidade da organização com relação ao planejamento, gerenciamento e controle dos requisitos de qualidade do projeto e do produto para atender às expectativas dos clientes. A referida área possui três processos que serão descritos a seguir:
	Planejamento
	Execução
	Monitoramento e Controle
	Gerenciar a Qualidade
	Controlar a Qualidade
	Planejar o Gerenciamento da Qualidade
	Processo do grupo de processo planejamento que permite identificar os requisitos e/ou padrões da qualidade do projeto e suas entregas, e documentar como o projeto demonstrará a conformidade com os requisitos e/ou padrões de qualidade, tendo como principal entrega o plano de gerenciamento da qualidade.
	Processo do grupo de processo execução que transforma o plano de gerenciamento da qualidade em atividades da qualidade executáveis que incorporam no projeto as políticas de qualidade da organização.
	Processo do grupo de processo planejamento que monitora e registra resultados da execução de atividades de gerenciamento da qualidade para avaliar o desempenho e garantir que as saídas do projeto sejam completas, corretas e atendam às expectativas do cliente.
Tabela 1 – Processos do Gerenciamento da Qualidade do Projeto.
Atenção
O Gerenciamento da Qualidade do Projeto trata do gerenciamento do projeto e das entregas do projeto, adotando, entre outras, a premissa de que a prevenção é preferível à inspeção, pois é melhor obter a qualidade nas entregas, em vez de identificar não conformidades em uma determinada inspeção. Nesse caso, o custo de prevenção é geralmente muito menor do que o custo de corrigir os erros identificados.
Existem cinco níveis de gerenciamento da qualidade cada vez mais eficaz, conforme a seguir:
1. Deixar que o cliente encontre os defeitos é uma abordagem que pode gerar problemas de garantia, recalls, retrabalho e outros, sendo em geral uma abordagem mais cara.
2. Detectar e corrigir os defeitos antes que as entregas sejam enviadas para o cliente como parte do processo de controlar a qualidade, pois esse processo tem custos relacionados, que são principalmente os custos de avaliação e os custos internos de falhas.
3. Usar a garantia da qualidade para examinar e corrigir o processo em si e não apenas defeitos especiais.
4. Incorporar a qualidade no planejamento e design do projeto e do produto.
5. Criar uma cultura na organização que esteja ciente e comprometida com a qualidade em processos e produtos.
Resumindo
Neste módulo, avaliamos a importância da garantia da qualidade no desenvolvimento de software.
Incialmente, destacamos que um sistema de garantia da qualidade define a estrutura organizacional responsável pela gestão da qualidade, garantindo o atendimento às expectativas do cliente.
Vimos que o processo de garantia de qualidade de software, parte do referido sistema,enfatiza a adoção de padrões que devem ser aplicados ao processo de desenvolvimento de software, bem como garantir que esses sejam cumpridos; os padrões devem ser aplicados nos processos e produtos.
A adoção de um padrão, tal como os especificados pela ISO, permite a geração de manuais de qualidade da organização, que por sua vez define o processo de qualidade da organização, sendo o mesmo customizado para cada projeto em função de sua complexidade e processo de desenvolvimento de software adotado.
Vimos, também, que o PMBOK possui três processos na área de conhecimento e gerenciamento da qualidade de projetos em diferentes grupos de processos.
Agora é com você! Vamos verificar se atingimos o objetivo deste módulo? Você está convidado a realizar as atividades a seguir.
Verificando o aprendizado
Parte superior do formulário
1. (Defensoria Pública do Estado do Rio de Janeiro ‒ DPE-RJ ‒ Analista ‒ Tecnologia da Informação ‒ FGV-2019) A empresa “Armazéns do João”, com o propósito de adquirir um software de controle de estoque, solicitou a um analista de sua equipe de informática que verificasse a qualidade do software. A avaliação constatou que o software não possuía documentação técnica, não havia comentários no código, e suas classes e métodos possuíam nomes pouco significativos. Além disso, o software não garantia o acesso restrito a informações confidenciais de forma consistente.
Com base nessas informações, o software não foi considerado de qualidade, pois não atendia às características desejáveis para:
Manutenibilidade e confiabilidade
Confiabilidade e usabilidade
Usabilidade e segurança
Manutenibilidade e segurança
Portabilidade e manutenibilidade
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
A manutenibilidade é um aspecto da qualidade de software que se refere à facilidade de um software de ser modificado a fim de corrigir defeitos, adequar-se a novos requisitos, aumentar a suportabilidade ou se adequar a um ambiente novo. O desenvolvimento de software seguro exige o cumprimento das necessidades de segurança do cliente.
Parte superior do formulário
2. (Fundação Papa João XXIII ‒ FUNPAPA ‒ Analista de Sistemas ‒ AOCP ‒ 2018) O gerenciamento de qualidade de software para sistemas de software compreende melhorias significativas no nível organizacional e de projeto. Com relação aos conceitos de qualidade de software, é correto afirmar que:
No nível de projeto, o gerenciamento de qualidade está preocupado com o estabelecimento de um framework de processos organizacionais e padrões que levem a softwares de alta qualidade. Isso significa que a equipe de gerenciamento de qualidade deve assumir a responsabilidade de definir os processos de desenvolvimento do software que serão usados e os padrões que devem ser usados no software, bem como a documentação relacionada, incluindo os requisitos de sistema, projeto e código.
No nível de projeto, o gerenciamento de qualidade envolve a aplicação de processos específicos de codificação, verificando se os processos planejados foram seguidos, e a garantia de que as saídas de projeto estejam em conformidade com os padrões aplicáveis ao projeto.
No nível organizacional, o gerenciamento de qualidade está preocupado com o estabelecimento de um plano de qualidade. O plano de qualidade deve definir as metas de qualidade para o projeto e quais processos e padrões devem ser usados.
No nível organizacional, o gerenciamento de qualidade envolve a aplicação de processos específicos de qualidade, verificando se os processos planejados foram seguidos, e a garantia de que as saídas de projeto estejam em conformidade com os padrões aplicáveis ao projeto.
No nível organizacional, o gerenciamento de qualidade está preocupado com o estabelecimento de um framework de processos organizacionais e padrões que levem a softwares de alta qualidade. Isso significa que a equipe de gerenciamento de qualidade deve assumir a responsabilidade de definir os processos de desenvolvimento do software que serão usados e os padrões que devem ser usados no software, bem como a documentação relacionada, incluindo os requisitos de sistema, projeto e código.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "E" está correta.
De acordo com Sommerville (2011), o gerenciamento de qualidade de software para sistemas de software tem três principais preocupações: 1. No nível organizacional, o gerenciamento de qualidade está preocupado com o estabelecimento de um framework de processos organizacionais e padrões que levem a softwares de alta qualidade. Isso significa que a equipe de gerenciamento de qualidade deve assumir a responsabilidade de definir os processos de desenvolvimento do software que serão usados e os padrões que devem ser usados no software, bem como a documentação relacionada, incluindo os requisitos de sistema, projeto e código. 2. No nível de projeto, o gerenciamento de qualidade envolve a aplicação de processos específicos de qualidade, verificando que os processos planejados foram seguidos, e a garantia de que as saídas de projeto estejam em conformidade com os padrões aplicáveis ao projeto. 3. No nível de projeto, o gerenciamento de qualidade também está preocupado com o estabelecimento de um plano de qualidade. O plano de qualidade deve definir as metas de qualidade para o projeto e quais processos e padrões devem ser usados.
Avalie este módulo:
 
    
MÓDULO 3
Explicar o planejamento da qualidade e o controle da qualidade de software
Planejamento da qualidade
A equipe de SQA, ou equipe de garantia da qualidade, tem como atribuição auxiliar a equipe de software a obter um produto final de alta qualidade.
O SEI recomenda um conjunto de ações de garantia da qualidade que tratam do planejamento, da supervisão, da manutenção de registros, da análise e de relatórios relativos à referida garantia.
Comentário
Essas ações deverão ser realizadas pela equipe de qualidade, sempre que possível independente, que, entre outras atividades, prepara um plano de qualidade de software para um projeto. O plano é desenvolvido como parte do planejamento de projeto, sendo revisado por todos os interessados.
As ações de garantia da qualidade realizadas pela equipe de Engenharia de Software e equipe de qualidade são orientadas pelo plano, que identifica as avaliações, auditorias e revisões a serem realizadas, padrões que serão aplicados no projeto, procedimentos para relatório e acompanhamento de erros, produtos resultantes produzidos pelo grupo de SQA e o feedback que será fornecido à equipe de software.
O plano de qualidade de software fornece um roteiro para instituir a garantia da qualidade de software, devendo ser desenvolvido pela equipe SQA ou pela equipe de desenvolvimento, no caso da inexistência da equipe SQA. O plano serve como um gabarito para atividades de garantia da qualidade de software que serão instituídas para cada projeto de software.
Imagino um questionamento: Cada projeto de software tem um plano?
Resposta
Respondemos ao questionamento nos reportando à Figura 6, na qual podemos identificar que a organização elabora um manual de qualidade, ou uma política com procedimentos padrões, sendo instanciado para cada projeto, a partir desse manual, um plano de qualidade de software primariamente em função da complexidade e do processo de desenvolvimento do software em questão.
Reveja:
Figura 6 novamente – ISO 9000 versus gerenciamento da qualidade.
Fonte: O Autor.
Foi publicado pelo IEEE um padrão para planos de qualidade de software. O padrão recomenda uma estrutura que identifique:
· O propósito e o escopo do plano.
· Uma descrição de todos os artefatos resultantes de engenharia de software (por exemplo, modelos, documentos, código-fonte).
· Todos os padrões e práticas que são aplicados durante a gestão de qualidade.
· As ações e tarefas da garantia da qualidade (incluindo revisões e auditorias) e sua aplicação na gestão de qualidade.
· As ferramentas e os métodos que dão suporte às ações e tarefas da garantia da qualidade.
· Procedimentosde softwares e hardwares; a ideia é garantir que a solução tecnológica seja executada adequadamente sobre os mais variados ambientes de produção previstos nas fases de levantamento dos requisitos, tal como simular um saque com impressoras dos fornecedores X, Y e Z.
Controle de qualidade
Controlar a qualidade é o processo de monitorar e registrar resultados da execução das atividades de gerenciamento da qualidade verificando se as entregas e o trabalho do projeto cumprem os requisitos especificados. O processo Controlar a Qualidade é realizado para medir a integridade, conformidade e adequação para uso de um produto ou serviço antes da aceitação do usuário e entrega final. Isso é feito medindo todos os passos, atributos e variáveis usados para verificar a conformidade com ou o cumprimento das especificações definidas no planejamento.
	Entradas
	Técnicas e Ferramentas
	Saídas
	Plano de gerenciamento do projeto
- Plano de gerenciamento da qualidade
	Coleta de dados
- Listas de verificação
- Folhas de verificação
- Amostragem estatística
- Questionário e pesquisas
	Medições de controle da qualidade
	Documentos do projeto
- Registro das lições apreendidas
- Métricas da qualidade
- Documentos de teste e avaliação
	Análises de dados
- Análises de desempenho
- Análise de causa-raiz
	Entregas verificadas
	Solicitações de mudança aprovadas
	Inspeção
	Informações sobre o desempenho do trabalho
	Entregas
	Testes/avaliação de produtos
	Solicitações de mudança
	Dados de desempenho do trabalho
	Representação de dados
- Diagramas de causa e efeito
- Gráficos de controle
- Histograma
- Diagramas de dispersão
	Atualizações do plano de gerenciamento do projeto
- Plano de gerenciamento da qualidade
	Fatores ambientais da empresa
	Reuniões
	Atualizações de documentos do projeto
- Registro das questões
- Registro das lições apreendidas
- Registro dos riscos
- Documentos de teste e Avaliação
	Ativos de processos organizacionais
	
	
Tabela 3 – Controlar a Qualidade.
Fonte: O Autor.
Atenção
• Devemos destacar que a entrada do processo “Documentos de testes e avaliação”, na coluna Entradas, incluem os testes aplicados na garantia do processo e do produto descritos anteriormente.
• Um segundo destaque, na coluna Saídas, são as “Solicitações de mudança”, pois uma não conformidade observada poderá gerar uma atualização no registro de mudanças do projeto, sendo que as solicitações de mudança aprovadas podem incluir modificações, como reparos de defeitos, revisão dos métodos de trabalho e revisão dos cronogramas.
Resumindo
Neste módulo, compreendemos o Planejamento da Qualidade com destaque ao trabalho realizado pela equipe de garantia da qualidade, que tem como atribuição auxiliar a equipe de software a obter um produto final de alta qualidade.
O plano de qualidade de software, elaborado pela referida equipe, fornece um roteiro para instituir a garantia da qualidade de software, servindo como um gabarito para as atividades de garantia da qualidade de software que serão instituídas para cada projeto de software.
Existem padrões para os referidos planos propostos pelo IEEE, PMBOK, entre outros.
Vimos também os testes de verificação que estão relacionados com a qualidade do processo de desenvolvimento de software e os testes de validação, relacionados com a qualidade do produto software.
O processo Controlar a qualidade permite atender à máxima “Não se controla o que não se mede”, permitindo monitorar e registrar resultados da execução das atividades de gerenciamento da qualidade, verificando se as entregas e o trabalho do projeto cumprem os requisitos especificados.
Agora é com você! Vamos verificar se atingimos o objetivo deste módulo? Você está convidado a realizar as atividades a seguir.
Verificando o aprendizado
Parte superior do formulário
1. (Universidade Federal de Pernambuco ‒ UFPE ‒ Analista de Tecnologia da Informação ‒ Sistemas ‒ COVEST-COPSET ‒ 2019) O engenheiro de software avalia que na sua equipe, em datas próximas da data de entrega de uma versão do sistema, a produtividade e o nível de estresse da equipe são impactados. Ele deseja automatizar o processo, de forma a mitigar esses efeitos. Para tanto:
Como parte da implantação contínua, ele automatiza o processo de forma que impeça que a nova versão do sistema entre em produção, caso o teste falhe.
Como parte da entrega contínua, ele automatiza uma série de rotinas para que o sistema seja automaticamente posto em produção.
Como parte da implantação contínua, ele elabora uma série de testes para garantir que, ao implementar uma nova rotina ou funcionalidade, as outras partes do sistema continuem operando normalmente.
Como parte da integração contínua, ele automatiza o processo de agregar novas mudanças na forma de recursos e funcionalidades, em uma nova versão.
Como parte da entrega contínua, ele elabora smoke tests para garantir o funcionamento do sistema, antes de enviá-lo para produção.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Sempre que ocorre uma falha no teste de software, esse não deverá migrar do ambiente de desenvolvimento para o ambiente de produção.
Parte superior do formulário
2. (Ministério Público do Estado de Alagoas ‒ MPE-AL ‒ Analista ‒ Desenvolvimento de Sistemas ‒ FGV ‒ 2018) Eduardo é o líder técnico do sistema de vendas de uma rede de farmácias. O sistema deve ser utilizado em mais de 40 unidades espalhadas por vários estados. O sistema entrou em produção e, já na primeira semana de uso, ficou muito lento e diversas vezes indisponível para os operadores das lojas. Diante desse cenário, assinale a opção que indica a técnica de teste que foi negligenciada.
De fumaça
Funcional de limite
De desempenho
Caixa-branca
De análise de valor-limite
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
Teste de desempenho é similar ao teste de carga, mas com o intuito de testar o software a fim de encontrar o seu limite de processamento de dados no seu melhor desempenho. No teste, normalmente é avaliada a capacidade de resposta em determinados cenários e configurações.
Avalie este módulo:
 
    
MÓDULO 4
Descrever as medições e métricas do software
Medição
Um elemento-chave de qualquer processo de engenharia é a medição, pois podemos aplicar a máxima “Não se controla o que não se mede”.
Vamos entender o conceito de medição por meio dos termos medida, medição e métricas. No contexto de engenharia de software, uma medida proporciona uma indicação quantitativa da extensão, quantidade, capacidade ou tamanho de algum atributo de um produto ou processo, sendo a medição ato de determinar uma medida.
A métrica é uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo.
Exemplo
Exemplificando, uma medida é estabelecida quando ocorre a coleta do número de erros descobertos em um componente de software. A medição ocorre como resultado de um conjunto de revisões de componentes e testes de unidade investigados na coleta de medidas do número de erros para cada um. A métrica de software relaciona as medidas individuais, ou seja, o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade.
A medição de software está preocupada com a quantificação de algum atributo de um sistema de software, como a sua complexidade ou a sua confiabilidade. Comparando os valores medidos uns com os outros e com os padrões que se aplicam a uma organização, deve ser possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia de processos de software, de ferramentas e de métodos, ou seja, o gerenciamento da qualidade pode contar com medições de atributos que afetam a qualidade do software.
Processo de medição
O fluxo abaixo ilustra um processo de medição proposto por Sommerville (2019), que pode ser parte de um processo de avaliação da qualidade de software, no qual cada componente do sistema pode ser analisado separadamente usando uma variedade de métricas. Os valores dessas métricas podem, então,ser comparados com diferentes componentes e, talvez, com dados de medição históricos, coletados em projetos anteriores. Medições anômalas, que se desviam significativamente da norma, em geral indicam problemas com a qualidade desses componentes.
Clique nas barras para ver as informações.
Escolher as medições a serem feitas
Inclui a formulação das questões às quais a medida se destina a responder, bem como a definição das medições necessárias para respondê-las.
Selecionar os componentes a serem avaliados
Selecionar um conjunto representativo de componentes para medição, a fim de permitir uma avaliação geral da qualidade do sistema.
Mediar as características dos componentes
Os componentes selecionados são medidos, e os valores de métricas associados são calculados, sendo sugerido o uso de uma ferramenta de coleta automática de dados.
Identificar medições anômalas
Depois que as medições do componente foram feitas, é possível compará-las umas com as outras e com as medições anteriores registradas em um banco de dados de medição, devendo-se procurar valores atipicamente altos ou baixos para cada métrica, pois eles sugerem que pode haver problemas com o componente que está exibindo esses valores.
Analisar componentes anômalos
Ao identificar componentes que têm valores anômalos, é preciso examiná-los para decidir se esses valores de métricas anormais significam que a qualidade do componente está comprometida ou não, pois um valor de métrica anormal, e.g., para a complexidade, não significa necessariamente um componente de má qualidade, pois pode haver algum outro motivo para o alto valor, ou seja, pode não haver problema de qualidade com o componente.
Uma boa prática inclui a manutenção dos dados coletados como um recurso organizacional e guardar registros históricos de todos os projetos, pois o estabelecimento de um banco de dados de medição robusto permitirá realizar comparações de qualidade de software em projetos e validar as relações entre atributos de componentes internos e características de qualidade.
Método GQM
O método GQM (Goal – Question – Metric) é uma técnica aplicada no planejamento do trabalho de medição, ou seja, permite a identificação de métricas significativas para qualquer parte do processo de software. O GQM organiza o planejamento de uma medição de software em etapas de acordo com as descrições a seguir:
Clique nas informações a seguir.
Objetivo
Questões
Métricas
Conheça as métricas utilizadas no processo de garantia da qualidade de software:
Métricas
Relembrando
Como afirmado anteriormente, uma métrica é uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo, tal como o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade.
A Engenharia de Software é uma área de conhecimento quantitativa, portanto, uma métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software por meio de atributos específicos e mensuráveis permitindo aos mesmos criar um software de alta qualidade.
Vamos entender como são utilizadas as métricas.
No contexto do processo de definição e após a definição das métricas, coletam-se os dados necessários para derivar as métricas formuladas, sendo as mesmas analisadas com base em diretrizes preestabelecidas e dados do passado; os resultados das análises são interpretados para obter informações sobre a qualidade do software e os dados da interpretação podem gerar alterações nos requisitos, modelos de projeto, código-fonte ou processo de software.
Saiba mais
Uma melhor prática é descrever um conjunto de atributos a serem aplicados às métricas, tais como: Fácil aprendizado em relação à sua derivação e com uma computação sem demanda de esforço; deverá satisfazer as ideias do engenheiro sobre o atributo do produto considerado (por exemplo, uma métrica que mede coesão de módulo deverá crescer em valor na medida em que aumenta o nível de coesão); sempre produzir resultados que não sejam ambíguos; a computação matemática da métrica deverá usar medidas que não resultem em combinações incomuns de unidades, e.g., multiplicar o número de pessoas nas equipes de projeto pelas variáveis da linguagem de programação no programa resulta em uma mistura duvidosa de unidades que não é claramente convincente; baseadas no modelo de requisitos, modelo de projeto ou na própria estrutura do programa; fornecer informações que podem levar a um produto final de melhor qualidade.
Podemos afirmar que uma métrica de software é uma característica de um sistema de software, da documentação do sistema ou do processo de desenvolvimento, que pode ser medida objetivamente. De acordo com Sommerville (2019), as métricas de software podem ser:
Clique nas barras para ver as informações.
MÉTRICAS DE CONTROLE OU DE PROCESSO
Apoiam o gerenciamento de processos, ou seja, geralmente estão associadas aos processos de software, tais como o esforço médio ou o tempo necessário para reparar defeitos relatados. Podem ser usados três tipos de métricas de processo:
1. O tempo que um determinado processo leva para ser concluído.
2. Os recursos necessários para um determinado processo, tais como o esforço total, em pessoas-dia, custos de viagens ou recursos de computadores.
3. O número de ocorrências de um determinado evento, tais como o número de defeitos detectados durante a inspeção de código, o número de alterações de requisitos solicitadas, o número de relatórios de defeitos em um sistema entregue e o número médio de linhas de código modificadas em resposta a uma mudança de requisitos.
MÉTRICAS DE PREVISÃO OU DE PRODUTO
Também denominadas de métricas de produto, estão associadas ao produto software e permitem quantificar atributos internos de um sistema de software, tais como o tamanho do sistema, medido em linhas de código, ou o número de métodos associados a cada classe.
As métricas de produtos enquadram-se em duas classes:
1. Métricas dinâmicas, cujas medições são realizadas no software em execução durante um teste de sistema ou em operação.
2. Métricas estáticas, cujas medições são feitas a partir de representações do sistema, como o projeto, o programa ou a documentação.
As métricas estáticas ajudam a avaliar a complexidade, a compreensibilidade e a manutenibilidade de um sistema ou de seus componentes. A tabela a seguir exemplifica algumas métricas estáticas de produto software.
	Métrica
	Descrição
	Fan-in / fan-out
	· Fan-in: Número de funções ou métodos que chamam outra função ou método (por exemplo, x).
· Fan-out: Número de funções que são chamadas pela função x.
· Um valor elevado para o fan-in significa que x está fortemente acoplado ao resto do projeto e as mudanças em x terão um amplo efeito dominó.
· Um valor elevado para fan-out sugere que a complexidade geral de x pode ser alta por causa da complexidade da lógica de controle necessária para coordenar os componentes chamados.
	Comprimento do código
	· Medida do tamanho de um programa.
· Geralmente, quanto maior o tamanho do código de um componente, mais complexo e propenso a erros ele tende a ser.
	Complexidade ciclomática
	· Visa a analisar a estrutura do código-fonte.
Tabela 4 – Métricas estáticas de produto.
As métricas dinâmicas ajudam a avaliar a eficiência e a confiabilidade de um sistema.
Exemplo
A confiabilidade é uma característica de qualidade de software a ser avaliada, pois, de forma simplificada, um software é confiável quando não falha (ver Figura 4. Fatores de qualidade de software de McCall). Nesse caso, podemos aplicar algumas métricas dinâmicas: Total de falhas relatadas durante o teste, número de falhas corrigidas, tempo médio entre as falhas, porcentagem de falhas corrigidas, entre outras.
As métricas de controle e de previsão podem influenciar a tomada de decisões de gerenciamento, como mostrado na Figura 9. Os gerentes usam as medições de processo para decidir se as alterações desse processo devem ser feitas e as métricas de previsão para decidir se as alterações de software são necessáriase se o software está pronto para entrar em produção.
Figura 9 – Medições de previsão e controle.
Fonte: O Autor.
Resumindo
Neste módulo, destacamos a importância das medições e métricas para a qualidade do software.
A medição de software tem como objetivo a quantificação de algum atributo de um sistema de software, como a sua complexidade ou a sua confiabilidade. Comparando os valores medidos uns com os outros e com os padrões que se aplicam a uma organização, deve ser possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia de processos de software, de ferramentas e de métodos. Um processo de medição pode ser parte de um processo de avaliação da qualidade de software, onde cada componente do sistema pode ser analisado separadamente usando uma variedade de métricas.
A Engenharia de Software é uma área de conhecimento quantitativa, portanto, uma métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software por meio de atributos específicos e mensuráveis permitindo aos mesmos criar um software de alta qualidade.
As métricas de controle geralmente estão associadas aos processos de software e as métricas de previsão associadas ao produto software, permitindo quantificar atributos de um sistema de software.
Agora é com você! Vamos verificar se atingimos o objetivo deste módulo? Você está convidado a realizar as atividades a seguir.
Verificando o aprendizado
Parte superior do formulário
1. Ministério Público de Contas do Estado do Pará ‒ MPC-PA ‒Analista ‒ Tecnologia da Informação ‒ CESPE ‒ 2019) A métrica de qualidade de código que mede a complexidade estrutural de um programa computando o número de caminhos linearmente independentes ao longo do código-fonte é denominada:
Complexidade ciclomática
Complexidade de Halstead
Contagem de pontos de microfunção ponderados
Índice de manutenibilidade
Extensibilidade
Parte inferior do formulário
Comentário
Parabéns! A alternativa "A" está correta.
Complexidade ciclomática é uma métrica de software usada para indicar a complexidade de um programa de computador, por meio da medição da quantidade de caminhos de execução independentes a partir de um código-fonte.
Parte superior do formulário
2. (Assembleia Legislativa do Estado do Rio de Janeiro ‒ ALERJ ‒ Analista ‒ Tecnologia da Informação‒ FGV ‒ 2017) Um sistema está sendo desenvolvido por uma empresa terceirizada para apoiar as vendas de um mercado varejista da Grande São Paulo denominado “Mendes Sá Colão”. Após o desenvolvimento do sistema, a empresa terceirizada deverá passar o código-fonte para a área de TI da “Mendes Sá Colão”, que passará a ser responsável pela continuidade do sistema. Foi ressaltada, também, a necessidade de que o sistema, caso ocorra uma falha, recupere-se de forma automática e rapidamente.
Nesse caso, os atributos de qualidade do sistema com maior peso são:
Portabilidade e confiabilidade
Manutenibilidade e confiabilidade
Portabilidade e eficiência
Confiabilidade e usabilidade
Manutenibilidade e eficiência
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
A medição atributo da manutenibilidade irá possibilitar reduzir o esforço na alteração do software após o recebimento do código-fonte do mesmo e a medição da confiabilidade permitirá uma rápida resposta a uma falha, caso ocorra.
Conclusão
Considerações Finais
A qualidade no contexto da Engenharia de Software possui duas dimensões: Processo e produto. A produção de software com qualidade exige a garantia da qualidade em todas as etapas do processo de desenvolvimento do software, bem como do produto software.
Destacamos que um sistema de garantia da qualidade define a estrutura organizacional responsável pela gestão da qualidade, garantindo o atendimento às expectativas do cliente. O processo de garantia de qualidade de software, parte do referido sistema, enfatiza a adoção de padrões que devem ser aplicados ao processo de desenvolvimento de software.
O plano de qualidade de software, elaborado pela equipe de garantia da qualidade, fornece um roteiro para instituir a garantia da qualidade de software, servindo como um gabarito para atividades de garantia da qualidade de software que são instituídas para cada projeto de software.
A medição de software tem como objetivo a quantificação de algum atributo de um sistema de software, como a sua complexidade ou a sua confiabilidade. Comparando os valores medidos uns com os outros e com os padrões que se aplicam a uma organização, deve ser possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia de processos de software, de ferramentas e de métodos. Um processo de medição pode ser parte de um processo de avaliação da qualidade de software.
No contexto da medição de software, as métricas ajudam os engenheiros de software a visualizar o projeto e a construção do software por meio de atributos específicos e mensuráveis, permitindo aos mesmos criar um software de alta qualidade.
Descrição
A definição e aplicação de métricas de software e medidas no gerenciamento de projetos de software, na melhoria de processos de software e na qualidade do produto.
PROPÓSITO
O entendimento das métricas de software capacita os profissionais de Tecnologia da Informação (TI) a fazer estimativas de tamanho, esforço, duração e custos de um projeto. A aplicação das métricas durante a realização do projeto ajuda a equipe a identificar cada vez mais cedo os problemas e a propor soluções, apoiando o gerenciamento de riscos. As métricas também são essenciais para a definição das relações de contratação entre as organizações.
OBJETIVOS
Módulo 1
Reconhecer a importância de métricas e medidas
Módulo 2
Analisar as características gerais de uma métrica
Módulo 3
Classificar as métricas de software apresentando os métodos utilizados
Módulo 4
Empregar métricas de software no acompanhamento da evolução de um projeto
Introdução
Neste conteúdo, aprenderemos os principais fundamentos de métricas e medidas de software. Veremos como identificar, classificar, analisar e aplicar métricas de software como ferramenta essencial no gerenciamento de projetos. Relacionaremos os principais fundamentos com a apresentação de exemplos práticos presentes no cotidiano dos profissionais de Tecnologia da Informação (TI), como medidas de controle de produtividade e qualidade.
Também apresentaremos as técnicas utilizadas para fazer a análise de requisitos de um projeto e, dessa forma, quantificar o tamanho de um software, que representa a entrada principal para a realização de estimativas de esforço, custos e duração de um projeto. Por fim, será demonstrado o processo de medição de software para o acompanhamento da execução de um projeto.
MÓDULO 1
Reconhecer a importância de métricas e medidas
Motivação
As primeiras perguntas que nos deparamos antes de iniciarmos um projeto de software são:
Quanto tempo o projeto irá durar?
Qual é o custo deste projeto?
Diferentemente das áreas de Engenharia e Arquitetura, em que podemos prever todas as características da construção de uma casa, por exemplo, antes mesmo de levantarmos um único tijolo, na área de Ciência da Computação os requisitos tendem a aumentar com o tempo. Na medida em que o projeto vai se desenvolvendo, os usuários passam a vislumbrar novas características que inicialmente não eram percebidas ou não eram importantes nas primeiras versões do projeto. Essa natureza expansiva dos requisitos é uma realidade que ocorre em quase todos os projetos de software e influencia diretamente o tempo em que o projeto será entregue e o seu custo final.
Atender aos requisitos que tendem à expansão envolve um aumento no esforço para realizar o projeto, e a disputa por recursos tende à escassez, como recursos humanos, materiais, financeiros e o próprio tempo, que é limitado. Manter essa situação sob controle é o maior desafio do gerenciamento de projetos de software, que busca atender ao máximo às expectativas dos clientes com a utilização mínima de recursos.
Conforme poderemos observar no relatório ChaosManifesto (THE STANDISH GROUP, 2013), continuamente atualizado, projetos fracassados continuam acontecendo na indústria de software: 39% dos projetos foram bem-sucedidos, ou seja, foram entregues no tempo, no orçamento, com as características e funções requisitadas; 18% dos projetos fracassaram, ou seja, foram cancelados antes do término ou entregues e nunca usados; e 43 % dos projetos foram contestados, ou seja, entregues com atraso, com estouro do orçamento e/ou com menos características e funções requisitadas.
Gráfico: Chaos Report 2013
Extraído de: Standish Group, adaptado por Gian Corapi.
Por outro lado, analisando os relatórios publicados anteriormente pelo Standish Group desde 1994, constatamos que o número de projetos fracassados vem diminuindo ao longo dos anos e o número de projetos bem-sucedidos vem aumentando, conforme tabela a seguir.
	
	2012
	2010
	2008
	2006
	2004
	2002
	2000
	1998
	1996
	1994
	Sucesso
	39%
	37%
	32%
	35%
	29%
	34%
	28%
	26%
	27%
	16%
	Contestado
	43%
	42%
	44%
	19%
	53%
	15%
	23%
	28%
	40%
	31%
	Fracasso
	18%
	21%
	24%
	46%
	18%
	51%
	49%
	46%
	33%
	53%
Tabela: Chaos Report de 1994 até 2012.
Adaptada de: Standish Group
Embora a série histórica do Standish Group seja atualizada todos os anos, o relatório de 2012 demonstra como a adoção de novas metodologias de desenvolvimento de software, assim como a adoção das métricas no gerenciamento de projetos, afetaram positivamente o mercado de TI. Os dados após aquele relatório não variaram muito, justamente pelas medidas tomadas a partir daquele ano, de modo que essa melhoria não seria percebida com a série histórica atualizada.
Agora, vamos analisar o que mudou nesse período?
Primeiro, a mudança nos processos de desenvolvimento de software nas empresas que antes utilizavam processos em cascata (waterfall) ou sequenciais, em que, por exemplo, era necessário conhecer detalhadamente todos os requisitos do projeto desde as suas fases iniciais antes da sua implementação, o que gerava estimativas imprecisas.
Esse fato impulsionou vários avanços: a mudança para uma abordagem de desenvolvimento ágil, como o Extreme Programming (XP) e o Scrum; a popularização do gerenciamento de projetos através do Project Management Institute (PMI) e publicação do Guia PMBOK; os modelos de maturidade tais como o CMMI (Capability Maturity Software Integration ou Modelo Integrado de Maturidade em Capacitação) e MPS-BR (Melhoria de Processo de Software Brasileiro); técnicas de medição de software como a APF – Análise de Pontos de Função; tecnologias orientadas a objetos; linguagens de quarta geração; componentização; uso intensivo de pacotes de software, em especial os ERPs; ambientes integrados de desenvolvimento, entre outras mudanças.
Saiba mais
Antigamente, as medições eram encaradas por muitas empresas de software apenas como uma tarefa ou um trabalho adicional sem muito entusiasmo, enquanto hoje é uma disciplina proativa e a informação gerada pela medição é considerada como um recurso competitivo e estratégico. Atualmente, muitas empresas utilizam tecnologias como Business Intelligence (BI) e Big Data para fazer a análise desses dados e gerar informações valiosas de modo a apoiá-las na tomada de decisões.
Por que medir?
O Software Engineering Institute (SEI) responde a dois questionamentos que vêm à tona após as nossas explanações iniciais:
Por que medir? Porque sem dados você tem somente opiniões.
Por que analisar? Porque os dados que você coleta não podem te ajudar se você não os entende e os usa para tomar suas decisões.
Tom DeMarco, consultor e pesquisador norte-americano reconhecido na área de Engenharia de Software, responde ao primeiro questionamento da seguinte forma:
“Não se pode gerenciar o que não se pode medir”.
Roger Pressman (2016, p. 136), autor do livro Engenharia de Software: uma abordagem profissional, considerado a maior referência na área de Engenharia de Software, responde aos dois questionamentos da seguinte forma:
Se você não sabe para onde quer ir, qualquer caminho você pode seguir. Se você não sabe onde você está, um mapa não vai te ajudar!
Comparando as respostas anteriores, podemos identificar um benefício importante da medição, que é a visibilidade. Com ela, é possível saber para onde ir antes de iniciar a caminhada, assim como saber se o caminho em curso é o correto. Dessa forma, é possível definir objetivos realistas e adotar medidas necessárias à prevenção e correção dos desvios que causam impacto negativo no cumprimento desses objetivos.
A imagem a seguir ilustra um cenário clássico de problemas que podem ocorrer durante o desenvolvimento de um software, que se não identificados e solucionados desde cedo, comprometem a entrega final do produto.
Clique na imagem para visualização full-screen.
Cenário com as etapas de desenvolvimento de um projeto
Como podemos observar confrontando o primeiro e o último quadro, o cliente não conseguiu comunicar o que o produto deveria ser, ou seja, quais as suas características principais e o que ele esperava que fosse entregue. Utilizando métricas e medições, essa falha na comunicação seria percebida e corrigida desde o início do projeto.
No penúltimo quadro, verificamos também que o projeto foi concluído com atraso, pois a figura do boneco de neve sinaliza que a estação do ano em que o produto foi entregue foi o inverno, diferentemente das dos demais quadros.
No sétimo quadro, também verificamos que houve um estouro no orçamento do projeto, demonstrado pela poltrona. Um dos objetivos do uso das métricas, conforme explicamos no início deste módulo, é possibilitar o acompanhamento do projeto mantendo a situação sob controle, ou seja, tentando cumprir o que foi planejado no início do projeto, durante a sua realização, evitando dessa forma o estouro no prazo e nos custos do projeto.
Portanto, verificamos que as métricas são um artefato essencial para o gerenciamento de projetos.
O Project Management Institute (PMI), em seu Guia do conjunto de conhecimentos em gerenciamento de projetos (PMBOK), agrupa os processos que visam permitir o gerenciamento de projetos em cinco grandes grupos, dos quais iremos destacar três:
· Planejamento
· Execução
· Monitoramento e controle
Durante o planejamento, são definidos os planos de projeto que são refinados ao longo do seu curso, e neles são definidas as linhas de base (baselines) que irão nortear a execução e o monitoramento e controle do projeto. A linha de base de cada um desses planos é criada por meio de técnicas de estimativas utilizando métricas.
No plano de gerenciamento de tempo, criamos um cronograma, com os prazos estimados para a realização de cada uma das atividades e o recurso (profissional) que irá executá-las, e durante a execução e o monitoramento e controle do projeto é que efetivamente ocorrem as medições, quando confrontamos o que foi planejado com o que está sendo realizado e analisamos o progresso do projeto.
As métricas também:
1
São utilizadas para avaliar a aquisição de pacotes (make-or-buy), apoiando a organização na tomada da decisão de fazer ou comprar um software no mercado.
Suportam análises de produtividade e qualidade, medindo o desempenho da equipe no curso do projeto e oferecendo indicadores de quantidade de defeitos/PF, por exemplo, que são úteis na avaliação da qualidade do software.
2
3
Auxiliam na remuneração de fornecedores, na medida em que se pode quantificar a funcionalidade que foi entregue pelo fornecedor em determinado período e, dessa forma, calcular quanto se deve pagar por aquilo que lhe foi entregue.
Apoiam a realização de estudos de Benchmarking, que são importantes para as organizações compararem os seus produtos e/ou serviços com os do concorrente e, assim, traçarem o seu planejamento estratégico.
4
5
Ajudam, ainda, a justificar as solicitações de novas ferramentas ou treinamentos, observando os indicadores de produtividade do time do projeto.
Reduzem frustrações e pressões de cronograma, pois as informações ficam transparentes para o cliente e são “quantificáveis”, fato que, inclusive,ajuda a melhorar o relacionamento.
6
7
Ajudam a entender e aperfeiçoar o processo de desenvolvimento de software, fazendo com que, nos últimos anos, as empresas procurassem se certificar com os modelos propostos pelo CMMI e MPS-BR, por exemplo, para atestarem a qualidade dos seus processos de desenvolvimento e, assim, atraírem mais clientes e investidores no mercado.
Em seu guia sobre medições de software, Park, Goethert e Florac observam as razões por que medimos:
(1) caracterizar, para obter um entendimento de processos, produtos, recursos e ambientes, e estabelecer referenciais para comparações com futuras avaliações.
(2) avaliar para determinar o status com relação aos planos.
(3) prever, entendendo as relações entre os processos e produtos, criando modelos dessas relações.
(4) melhorar, identificando etapas, causas-raiz de problemas, ineficiências e outras oportunidades de melhoria da qualidade do produto e do desempenho do processo.
Métricas e medidas em Engenharia de Software
O especialista apresentará conceitos sobre métricas e medidas em sistemas de software, ressaltando a sua importância para o ciclo de vida dos sistemas.
Verificando o aprendizado
Parte superior do formulário
1. Ao longo dos últimos vinte anos, houve uma evolução significativa na indústria de Tecnologia da Informação, fato que levou as empresas a investirem mais na adoção de novas metodologias de desenvolvimento de software e de gerenciamento de projetos. Com base nessa declaração, podemos afirmar que
As empresas passaram a adotar a metodologia de desenvolvimento de software em cascata a fim de obter estimativas mais acertadas desde o início do projeto.
Técnicas de medição de software como a Análise de Pontos de Função passaram a ser cada vez mais utilizadas pelas empresas, o que contribuiu para que ao longo desses anos houvesse um aumento no número de projetos bem-sucedidos.
Antigamente as empresas de software utilizavam as medições como um recurso competitivo e estratégico, e o trabalho de medição sempre foi encarado com entusiasmo, o que justifica o aumento do número de projetos bem-sucedidos ao longo dos anos.
A maioria dos requisitos dos projetos de software é conhecida desde o início do projeto e não tende à expansão.
Projetos de software entregues com atraso, com estouro no orçamento, ou com menos características e funções do que as requisitadas não ocorrem com frequência.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
A fim de atender à tendência dos requisitos propensos à expansão na maioria dos projetos de software e manter essa situação sob controle, ou seja, entregar cada vez mais os projetos com os requisitos solicitados, no prazo e com o custo estimado, ao longo dos últimos anos as empresas passaram a adotar técnicas de medição de software como a Análise de Pontos de Função, o que pode ser observado no relatório do Chaos Report de 2013, publicado pelo Standish Group, que mostra o aumento no número de projetos bem-sucedidos com relação aos anos anteriores.
Parte superior do formulário
2. A adoção das métricas de software provê uma série de benefícios às organizações. Sobre esses benefícios, podemos afirmar:
A adoção de métricas de software aumenta as frustrações e pressões no cronograma porque o desempenho da equipe do projeto diminui quando as entregas passam a ocorrer no prazo.
A remuneração de fornecedores normalmente é contratada pelas empresas utilizando a forma de contratação homens-hora, sendo a adoção das métricas de software desnecessária para esse fim.
Os estudos de benchmarking, que comparam os produtos de uma empresa com os das empresas concorrentes, não utilizam métricas de software, pois não são relevantes para o planejamento estratégico de uma empresa.
As métricas de software podem ser utilizadas para avaliar a aquisição de pacotes de software, ajudando a empresa na tomada de decisão de fazer ou comprar um software no mercado.
As solicitações de novas ferramentas e treinamento são feitas com base nas opiniões do gerente de projetos, que é responsável por monitorar o cronograma e o desempenho da equipe do projeto.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "D" está correta.
As métricas de software geram indicadores que auxiliam as empresas na avaliação da aquisição de pacotes de software. Por exemplo, uma empresa que deseja desenvolver um aplicativo móvel, e que não possui uma equipe de desenvolvimento especialista nessa área, pode avaliar, com base nos indicadores dos seus registros históricos, se é mais lucrativo pagar pelo treinamento dos seus profissionais e obter no médio e longo prazo o retorno desse investimento, ou se é melhor contratar no mercado uma fábrica de software que possua o know-how na tecnologia e possa entregar em um prazo mais curto o produto final, ou seja, o aplicativo móvel.
Avalie este módulo:
 
    
MÓDULO 2
Analisar as características gerais de uma métrica
O que medir?
Quando um arquiteto faz a planta de uma casa, ele define as suas dimensões e qual o tamanho da área a ser construída em dado terreno utilizando o m² (metro quadrado) como unidade de medida. Por exemplo, o arquiteto faz o projeto com uma área construída de 100m² dentro de um terreno de 500m², e os seus ambientes internos como sala, quarto, banheiro e cozinha são divididos utilizando a mesma unidade de medida, que é o m² (metro quadrado).
Fazendo uma analogia com o mundo do software, para se construir um software, devemos definir também quais são as suas dimensões e as suas características utilizando uma unidade de medida. As duas principais unidades de medida utilizadas pela indústria de TI para dimensionar o tamanho de um software são LOC (Lines of Code ou Linhas de Código) e PF (Pontos de Função).
Medidas diretas, tangíveis e verificáveis, como as citadas, que possuem uma grandeza numérica e que são quantificáveis, nem sempre são possíveis no mundo do software, e como medidas e métricas são muitas vezes indiretas, ou seja, derivadas de outras medidas, como confiabilidade, eficiência e segurança, e possuem um maior grau de subjetividade com base em critérios e regras qualitativas, elas estão abertas ao debate.
No contexto da Engenharia de Software, de acordo com Pressman (2016, p. 654), “embora os termos medida, medição e métricas sejam, com frequência, usados indistintamente, existem diferenças sutis entre eles”. Uma medida fornece uma indicação quantitativa da extensão, quantidade, capacidade ou do tamanho de algum atributo de um produto ou processo.
Medição é o ato de determinar uma medida.
O IEEE Standard Glossary of Software Engineering Terminology (PRESSMAN, 2016, p. 654) define métrica como
“uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo”.
Para entendermos melhor cada um desses conceitos, vamos a um exemplo prático observando a tabela a seguir, que possui três projetos de desenvolvimento de software já concluídos de uma empresa fictícia. Nesse caso, as medidas estabelecidas foram LOC, esforço, custo ― representado pelo símbolo $(000) ―, erros, defeitos e pessoas. A medição, conforme vimos, é o ato de determinar uma medida e ocorre como resultado da coleta de um ou mais pontos de dados, ou seja, no projeto Alfa foram registrados 134 erros durante os testes, por exemplo, enquanto no projeto Beta 27.200 LOC (linhas de código) foram criadas por 62 pessoas-mês de trabalho, a um custo de $440.000. Por fim, a partir desses dados, podemos determinar um conjunto de métricas que relaciona as medidas individuais de alguma maneira como: a quantidade média de erros por KLOC (mil linhas de código); defeitos por KLOC; erros por pessoa-mês; e custo ($) por página de documentação. Outras métricas podem ser obtidas a partir dos dados coletados, sendo derivadas a partir de objetivos definidos pela empresa a fim de obter um melhor entendimento dos seus projetos.
]
	Projeto
	LOC
	Esforço
	$(000)
	Pág. doc.
	Erros
	Defeitos
	Pessoas
	alfa
	12.100
	24
	168
	365
	134
	29
	3
	beta
	27.200
	62
	4401224
	321
	86
	5
	gama
	20.200
	43
	314
	1050
	256
	64
	6
Tabela: Métricas de software
Extraída de: PRESSMAN, 2016, p. 709
No exemplo da tabela acima, foram apresentadas métricas de projeto de software, que são usadas para fins táticos ou gerenciais, baseadas em metas operacionais, e atividades técnicas, diferentemente das métricas de processo de software, que são baseadas nas metas da empresa e possuem objetivos estratégicos, como estudos de mercado e análise competitiva.
Dentre as propriedades desejáveis de uma métrica, destacam-se as seguintes:
· Deve ser simples o suficiente para ser facilmente calculada, entendida e testada;
· Deve ser passível de estudos estatísticos;
· Deve ser expressa em alguma unidade (tempo, pessoas, $);
· Deve ser obtida o mais cedo possível durante o ciclo de vida do software;
· Deve ser passível de automação;
· Deve ser repetível e independente do observador;
· Deve ser comprometida com uma estratégia de melhoria;
· Deve ser válida, quantificando o que se quer medir;
· Deve ser confiável, produzindo os mesmos resultados nas mesmas condições;
· Deve ser prática, ou seja, barata, fácil de calcular e fácil de interpretar.
Agora que já conhecemos a sutil diferença entre medida, medição e métrica, surgem os seguintes questionamentos:
Por que obter métricas de software?
O que fazer com esses dados?
Respondendo ao primeiro questionamento, obtemos métricas ou um conjunto de métricas para extrair indicadores a partir delas, que nos proporcionam uma compreensão e uma visão mais aprofundada do processo, do projeto ou do produto de software. Os indicadores podem ser obtidos a partir de bases de dados históricas de projetos que já foram concluídos, por exemplo, para ajudar na tomada de decisões em um projeto corrente, fato que nos ajuda a responder o segundo questionamento.
Por meio dos indicadores, alguém pode descobrir, por exemplo, que a inclusão de revisões técnicas formais no processo de desenvolvimento ocasiona uma redução de 40% na taxa de erros encontrados nos testes.
No exemplo visto, o uso do indicador “taxa de redução percentual de erros na etapa de teste”, que foi utilizado em projetos passados e obtido por intermédio das bases históricas de projetos, poderá ser utilizado em um projeto corrente a fim de se obter o benefício da redução de 40% na taxa de erros encontrados nos testes, visando, dessa forma, melhorar a qualidade e o desempenho do projeto.
Outros exemplos de indicadores úteis são: retorno do investimento, economia média líquida de esforço (pessoas x hora) por quantidade de código desenvolvido e quantidade média de erros por linha de código. Por fim, indicadores são instrumentos valiosos para orientar ações no sentido de melhorar um produto, um projeto ou um processo.
Para empresas que desejam começar a investir em métricas de software e que não possuem uma base de dados histórica de processos, projetos ou produtos, ou até para as empresas que já usam métricas de software e desejam comparar os seus indicadores com indicadores de mercado, há uma organização sem fins lucrativos conhecida como ISBSG (International Software Benchmarking Standards Group), que mantém um repositório público de dados de aproximadamente 9.502 projetos que são alimentados continuamente por organizações de todo o mundo e de diferentes áreas de negócio. Esse repositório possibilita que sejam feitas diversas análises e pesquisas abordando questões como estimativa, produtividade, boas práticas, dentre outras. Periodicamente, o ISBSG publica diversos relatórios, oferecendo análises detalhadas do seu repositório sob diversos aspectos.
Veja um dos relatórios na tabela a seguir.
	Linguagem de Programação
	N
	Min
	P10
	P25
	Mediana
	P75
	P90
	Max
	ABAP
	5
	8.0
	-
	13.3
	13.8
	18.0
	-
	24.3
	C
	27
	2.8
	6.4
	8.5
	14.9
	19.8
	27.4
	41.4
	C++
	20
	1.2
	5.9
	9.3
	17.4
	24.4
	42.3
	69.3
	CLIPPER
	4
	8.6
	-
	8.6
	8.8
	11.4
	-
	18.7
	COBOL
	64
	1.2
	5.2
	9.4
	16.0
	26.0
	42.4
	69.7
	JAVA
	10
	5.3
	6.6
	14.7
	19.6
	26.7
	67.8
	68.2
	ORACLE
	49
	1.2
	3.0
	6.0
	9.6
	15.9
	28.1
	78.1
	SQL
	56
	0.5
	3.4
	8.2
	13.6
	19.3
	35.3
	60.7
	VISUAL BASIC
	54
	0.4
	2.7
	3.8
	7.5
	14.0
	37.2
	68.0
Tabela: Produtividade (Horas/PF) por linguagem de programação.
Extraída de: Vazquez, Simões, Albert, 2013, p. 39.
Utilizando os indicadores da tabela acima, é possível que uma empresa tome a decisão de desenvolver um novo projeto utilizando a linguagem de programação Visual Basic ao invés da linguagem ABAP, pois, observando a mediana exposta na tabela, conclui-se que fazer um desenvolvimento utilizando Visual Basic demanda quase a metade do esforço do que utilizando a linguagem ABAP, visto que um programador desenvolvendo em Visual Basic faz um esforço de 7,5 horas para entregar 1 Ponto de Função, enquanto um programador desenvolvendo em ABAP faz um esforço de 13,8 horas para entregar 1 Ponto de Função.
Como definir as medidas?
O primeiro passo para o estabelecimento de uma política de medidas é a identificação adequada das medidas a serem coletadas. Essa definição deve ser feita com base em critérios bem fundamentados, devido ao grande número de opções possíveis e ao custo envolvido na coleta de cada informação.
Com o intuito de guiar o processo de definição das medidas, vários métodos foram propostos, como Balanced Scorecard (BSC), Goal-Question-Metric (GQM), Goal-Driven Software Measurement (GDSM) e Pratical Software and System Measurement (PSM). Dentre esses modelos propostos, iremos dar enfoque ao GQM e ao PSM.
No artigo intitulado Software modeling and measurement: The Goal/Question/Metric paradigm, publicado pelo Departamento de Ciência da Computação da Universidade de Maryland, Victor R. Basili propôs um modelo para guiar a escolha das medidas mais adequadas para um processo de mensuração. Esse método ficou conhecido como GQM (Goal/Question/Metric). A ideia básica desse método é derivar métricas de software a partir de perguntas e objetivos.
O modelo é composto por três níveis que visam definir se uma métrica atenderá ou não aos objetivos da empresa e se ela será coletada e utilizada. O primeiro nível, conhecido como Conceitual (Goal), busca definir os objetivos da organização, ou seja, as metas a serem atingidas pelo programa de medição. O segundo nível, conhecido como Operacional (Question), consiste em um conjunto de perguntas que é elaborado com relação a cada objetivo identificado no nível anterior. Por fim, no terceiro nível, conhecido como Quantitativo (Metrics), um conjunto de métricas é estabelecido, de maneira a responder cada pergunta elaborada no nível anterior.
Para entendermos melhor o GQM, observe a situação a seguir.
Exemplo
Suponhamos que uma organização possua um projeto de software em desenvolvimento rodando no ambiente de produção dos clientes, e que a cada atualização de versão ocorra a introdução de muitos defeitos, gerando uma insatisfação por parte dos clientes. Para reverter essa situação, a organização resolveu definir algumas métricas de qualidade, bem como a meta (Goal) de assegurar que todos os defeitos fossem corrigidos antes da liberação das versões para o ambiente de produção.
Com base nessa meta, a organização respondeu a três perguntas (Question):
· Quantos defeitos temos atualmente?
· Qual o status de cada defeito?
· Qual a cobertura dos testes?
Após a obtenção das respostas, definiu as seguintes métricas (Metrics): números de defeitos, números de defeitos por status e número de casos de testes planejados x executados.
Exemplo de aplicação do método QGM para definição de métrica
Outra abordagem para a definição de métricas foi publicada no guia PSM (Pratical Software and System Measurement), patrocinado pelo Departamento de Defesa dos Estados Unidos. O PSM focaliza as medições no nível de projetos e utiliza dois modelos integrados que são: o modelo de informação para medição (measurement information model) e o modelo do processo de medição (measurement process model).
O primeiro modelo fornece um caminho para a seleção das medidas a serem utilizadas, enquanto o segundoO desenvolvimento atual do software comumente tem restrições de prazos e uma alta volatilidade dos requisitos, limitando a geração de um produto abrangente. Esse modelo permite a geração de uma versão limitada que imediatamente agrega valor ao usuário.
 
Qual é a diferença entre o modelo incremental e evolucionário?
Modelo incremental
No modelo incremental, ocorre a entrega de um produto essencial, estando as demais iterações bem definidas.
Modelo evolucionário
No modelo evolucionário, uma parte dos requisitos está bem entendida, ocorrendo o versionamento em função desse entendimento. A cada nova iteração ocorre um melhor entendimento do problema por meio da definição de novos requisitos e novas versões são geradas.
Figura 2 – O modelo incremental.
O modelo incremental de processo de desenvolvimento de software
Veja, a seguir, as atividades típicas de desenvolvimento incremental que ocorrem em cada iteração do modelo:
O modelo incremental de processo de desenvolvimento de software
Prototipação
Imagine a construção de uma grande barragem onde, em uma fase inicial, é construído um protótipo em escala reduzida para numericamente avaliar os esforços existentes. Depois dos testes, a maquete serve como peça de museu ou vai para um laboratório de uma universidade para estudos de caso.
 
Você poderia questionar: como faço isso no software? A abstração é a mesma, porém o produto software tem suas peculiaridades.
Vamos imaginar que um requisito não funcional determina que a replicação de dados ocorrerá por meio de uma tecnologia desconhecida da equipe de desenvolvimento. Seria razoável aguardar o momento do desenvolvimento para realizar a tratativa desse requisito?
 
Na prototipação, o desenvolvedor interage diretamente com o usuário, escutando seus pedidos e desenvolvendo, imediatamente, um protótipo do produto desejado, isso de forma iterativa e evolucionária, como um “projeto rápido” apresentado a seguir.
Saiba Mais
Podemos descartar esse software gerado? Depende, normalmente essa primeira versão do protótipo serve apenas para validar um requisito e necessita ser reconstruída, mas, considerando as peculiaridades do software, essa mesma versão pode ser refinada e integrada ao sistema em desenvolvimento.
Atenção, a prototipação pode ser utilizada como modelo de processo na solução de problemas de baixa complexidade.
Figura 3 – O paradigma prototipação
Modelo Espiral
O Modelo Espiral foi originalmente proposto por Barry Boehm em 1988. De acordo com a Figura 4, cada quadrante da espiral corresponde a uma etapa do desenvolvimento e cada loop na espiral representa uma fase do processo de software. O loop mais interno pode estar relacionado com a viabilidade do sistema, o próximo, ao levantamento de requisitos e assim sucessivamente.
Primeira etapa
A primeira etapa (Analysis) inclui a determinação de objetivos, alternativas, riscos e restrições, em que ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos.
Segunda etapa
Na segunda etapa (Evaluation), avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco, sendo a prototipação uma boa ferramenta para tratar de ameaças.
Terceira etapa
Na terceira etapa (Development) ocorre o desenvolvimento do produto.
Quarta etapa
Na quarta etapa (Planning) o produto é avaliado, sendo realizado o planejamento para início de um novo ciclo.
Figura 4 – O modelo espiral. Fonte: Wikimedia Commons
Podemos fazer uso da abstração de forma a visualizarmos o modelo espiral como um metamodelo, tendo como exemplo o proposto por Pressman (2016), apresentado na Figura 5, na qual a espiral do modelo é dividida nas atividades genéricas ilustradas na Figura 1.
Figura 5 – O modelo espiral.
Resumindo
Neste módulo, pudemos destacar a importância dos modelos dos processos prescritivos para a Engenharia de Software. Vale lembrar que a camada base dessa engenharia é a referente a processos. Os modelos de processos permitem definir as atividades que serão executadas durante o projeto de software, bem como o fluxo de processos que define o encadeamento relativo a essas mesmas atividades.
 
Os modelos de processos prescritivos incluem a definição de metodologias, tarefas, artefatos, garantia da qualidade e mecanismos de controle de mudanças, isto é, um conjunto de elementos de processo.
 
O modelo em cascata determina a realização das tarefas de forma sequencial. Já os modelos de processo incremental e os modelos de processo evolucionário permitem um versionamento do software de forma iterativa e incremental.
 
O paradigma da prototipação é aplicado primariamente na validação de requisitos. O modelo espiral permite um desenvolvimento evolucionário do software.
Questão 1
(FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas) O Modelo Espiral, segundo Pressman (1995), incorpora as melhores características do Ciclo de Vida Clássico e da Prototipação e acrescenta o seguinte elemento:
A
Análise dos riscos.
B
Análise de projetos.
C
Avaliação de usuários.
D
Refinamento de requisitos.
E
Refinamento de protótipos.
Responder
Parabéns! A alternativa A está correta.
O modelo espiral é um modelo de processo de software evolucionário que une a natureza iterativa da prototipação aos aspectos sistemáticos e controlados do modelo cascata, enfatizando no segundo quadrante da espiral a análise de riscos.
Questão 2
Um gerente de projeto, junto à sua equipe de engenheiros de software, está definindo o modelo de processo de software a ser adotado em determinado projeto de software. Os requisitos do software são complexos e parcialmente identificados, o cliente impôs restrições de prazo para que o software agregue valor no seu negócio. Nesse contexto, qual o modelo de processo mais adequado?
A
Modelo de processo incremental.
B
Modelo de processo evolucionário.
C
Modelo espiral.
D
Modelo em cascata.
E
Modelo de processo iterativo.
Responder
Parabéns! A alternativa B está correta.
O modelo de processo evolucionário é o mais adequado em função da complexidade dos requisitos, estando eles parcialmente identificados. Esse modelo permite que os requisitos parcialmente identificados sejam considerados em um primeiro incremento, permitindo um melhor entendimento do domínio do problema e a identificação de novos requisitos para incrementos posteriores. O modelo possibilita, também, a disponibilização de versões de software agregando valor ao negócio do cliente.
Unified Modeling Language (UML)
A compreensão do Processo Unificado exige que tenhamos o entendimento da Unified Modeling Language, comumente denominada de UML, que é uma linguagem de modelagem padrão para a elaboração de artefatos no contexto do paradigma de desenvolvimento orientado a objetos.
Saiba Mais
Até meados da década de 1990, o paradigma de desenvolvimento estruturado era o padrão mais utilizado na indústria de software, ou seja, os métodos vigentes aplicavam os conceitos estruturados nos artefatos gerados, tal como o diagrama de fluxo de dados na etapa de análise. Importante destacar que a unidade básica do software era a função.
Considerando a evolução da complexidade do software, alguns metodologistas perceberam que os conceitos da orientação a objetos permitiam um melhor trato da complexidade, particularmente nos requisitos reuso e manutenibilidade. Esses metodologistas começaram a propor métodos com artefatos direcionados ao referido paradigma. A unidade básica do software passou a ser o objeto, que inclui dados ou atributos, e funções ou métodos, encapsulados.
Em algum momento, percebeu-se a necessidade de um padrão para a modelagem de sistemas que fosse aceito e utilizado amplamente, surgindo a UML em 1996 como a linguagem “unificadora” das diversas propostas de métodos orientados a objetos. Em 1997, a UML foi aprovada pelo Object Management Group (OMG), tornando-se um padrão de modelagem orientada a objeto na indústria do software.
A UML é uma linguagem visual, independente de linguagem de programação e de processo de desenvolvimento.modelo serve de guia para a implementação do PSM. O PSM inclui um conjunto de medidas já utilizadas com sucesso pela indústria, distribuídas em categorias previamente definidas como: prazo e progresso, recursos e custo, tamanho e estabilidade do produto, qualidade do produto, performance do processo, eficácia da tecnologia e satisfação do cliente. Conforme observado a seguir, temos um exemplo da obtenção de uma métrica de produtividade utilizando o modelo de informação do PSM.
Exemplo de produtividade utilizando o Modelo de Informação do PSM
No exemplo da imagem anterior, buscou-se extrair um indicador visando a uma estimativa de produtividade. Como resultado, obteve-se o indicador Horas/PF (Ponto de função), ou seja, quantas horas em média (esforço) um profissional levará para entregar 1 ponto de função (tamanho).
Independentemente do modelo utilizado para implementar um programa de métricas, a coleta de métricas é apenas um dos requisitos envolvidos, e o processo de medição de software envolve mais etapas além desta, as quais veremos posteriormente.
Características de métricas em software
O especialista apresentará as principais características das métricas em sistemas de software.
Verificando o aprendizado
Parte superior do formulário
1. Sobre os conceitos de medida, medição e métricas, é correto afirmar:
Uma medida fornece uma indicação qualitativa sobre um projeto de software baseada em opiniões dos especialistas do projeto.
As duas principais unidades de medida utilizadas pela indústria de TI são eficiência e confiabilidade.
Todas as medidas de software são quantificáveis, baseadas em critérios técnicos, regras bem definidas e em uma grandeza matemática.
As métricas de projeto de software são utilizadas para fins estratégicos, visando às metas da empresa.
As duas principais unidades de medida utilizadas pela indústria de TI para dimensionar o tamanho de um software são LOC (linhas de código) e PF (pontos de função).
Parte inferior do formulário
Comentário
Parabéns! A alternativa "E" está correta.
As duas principais unidades de medida utilizadas para dimensionar o tamanho de um software são LOC (linhas de código) e PF (pontos de função), pois a partir delas são extraídos os indicadores necessários para se fazer as estimativas de esforço, tempo e custo dos projetos.
Parte superior do formulário
2. Sobre o processo de definição de medidas, que visa definir as medidas mais adequadas a serem coletadas pela organização, podemos afirmar:
O modelo GQM (Goal/Question/Metric) se guia por unidades de medida padrão, e não derivadas, para orientar a empresa na definição de suas melhores métricas.
Para se definir boas métricas na empresa, é necessário conhecer todos os modelos propostos para a definição de métricas como o Balanced Scorecard (BSC), Goal-Question-Metric (GQM), Goal-Driven Software Measurement (GDSM) e Pratical Software and System Measurement (PSM).
O modelo GQM (Goal/Question/Metric) deriva métricas de software a partir de perguntas e objetivos.
O modelo proposto pelo PSM (Pratical Software and System Measurement) focaliza as medições no nível de processos.
O PSM (Pratical Software and System Measurement) visa propor um conjunto de novas medidas que sejam melhores do que as já existentes no mercado, e que não foram utilizadas ainda pela indústria, e focaliza as medições no nível de projetos.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
O modelo GQM (Goal/Question/Metric) é composto por três níveis, sendo que o primeiro nível, conhecido como Conceitual (Goal), busca definir as metas da organização, enquanto o segundo nível, conhecido como Operacional (Question), consiste em um conjunto de perguntas elaboradas para cada uma das metas definidas no nível anterior, e o terceiro nível, conhecido como Quantitativo (Metrics), deriva um conjunto de métricas baseado nas respostas do nível anterior.
Avalie este módulo:
 
    
MÓDULO 3
Classificar as métricas de software apresentando os métodos utilizados
Métricas diretas e indiretas
No mundo físico, as medições podem ser classificadas de duas maneiras: medidas diretas, como tensão elétrica, massa, velocidade ou temperatura, e medidas indiretas, como a velocidade média de um carro, sabendo que ele percorreu um espaço x em um intervalo de tempo y.
Como podemos observar, as medidas diretas são mais fáceis de serem obtidas, pois podem ser mensuradas a partir da observação direta dos atributos envolvidos, enquanto as medidas indiretas são obtidas a partir da derivação de outras métricas. Inspiradas no mundo físico, as métricas de software são medidas de maneira similar.
No mundo do software, as métricas diretas são a quantidade de linhas de código produzida, o número de defeitos relatados durante o desenvolvimento do software, o custo do software, o esforço aplicado durante seu desenvolvimento e sua manutenção, o número de diagramas, a complexidade ciclomática ou complexidade condicional, que mede a quantidade de caminhos de execução independentes a partir de um código fonte, dentre outras.
Já as métricas indiretas como qualidade, funcionalidade do software, ou a sua capacidade de manutenção, confiabilidade, eficiência, dentre outras, são mais difíceis de serem obtidas e só podem ser medidas de forma indireta.
Para entendermos melhor uma métrica indireta, vamos a um exemplo de uma métrica para manutenção utilizada para medir o grau de estabilidade de um produto. Essa métrica conhecida como SMI (Software Maturity Index ou Índice de Maturidade de Software) se baseia nas alterações ocorridas em cada versão do produto, e é determinada com as seguintes informações:
MT = número de módulos da versão atual
Fc = número de módulos na versão atual que foram alterados
Fa = número de módulos na versão atual que foram acrescentados
Fd = número de módulos da versão anterior que foram excluídos na versão atual
Considerando as informações anteriores, podemos calcular o índice de maturidade do software por meio da seguinte fórmula:
SMI=[MT-(Fa+Fc+Fd)]MT
À medida que o SMI se aproxima de 1, o produto começa a estabilizar.
Métricas de processo, projetos e produto
No contexto da Engenharia de Software, o domínio das métricas de software é dividido em três grupos distintos que visam objetivos diferentes durante o ciclo de vida do software, que são: métricas de processo, métricas de projeto e métricas de produto.
Segundo Pressman:
as métricas de processo são coletadas em todos os projetos, no decorrer de longos períodos, e têm por finalidade gerar um conjunto de indicadores de processo que levam à melhoria do processo de software no longo prazo.
Clique na barra para ver as informações.
Métricas de PROCESSO
As métricas de processo são usadas com finalidade estratégica, ou seja, visam benefícios para projetos futuros, e não para o projeto que está sendo medido; têm como objetivo melhorar o processo de forma contínua e medir características do processo de desenvolvimento como um todo.
Essas métricas objetivam criar um padrão dentro da organização, que possa ser estendido para todos os projetos de software, independentemente do contexto em que ele seja aplicado. Um exemplo de uma métrica de processo é o número de defeitos encontrados ao longo do processo para diferentes metodologias de teste e de revisão.
Modelos como o CMMI e o MPS-BR apresentam um conjunto de boas práticas de melhoria de processo de software, as quais se tornaram uma referência para a indústria de TI.
De acordo com Pressman (2016),
as métricas de projeto permitem ao gerente de projetos de software:
(1) avaliar o estado de um projeto em andamento;
(2) rastrear os riscos em potencial;
(3) descobrir áreas problemáticas antes que se tornem “críticas”;
(4) ajustar o fluxo de trabalho ou tarefas;
(5) avaliar a habilidade da equipe de projeto para controlar a qualidade dos artefatos de software.
Clique na barra para ver as informações.
Métricas de PROJETO
As métricas de projeto são usadas com finalidade tática, ou seja, para adaptar o fluxo de trabalho e atividades técnicas deforma imediata, em benefício do próprio projeto que está sendo medido. Essas métricas têm como objetivo minimizar o cronograma e monitorar a qualidade do produto, e o seu primeiro emprego ocorre nas estimativas preliminares, e, à medida que o projeto evolui, os resultados são confrontados para monitorar e controlar o progresso. Taxa de produção, horas de revisão e tamanho (físico ou funcional) dos artefatos produzidos são exemplos de métricas de projetos.
Ainda de acordo com Pressman,
as métricas do produto são usadas para avaliar a qualidade do produto enquanto ele está sendo projetado. Essas medidas de atributos internos do produto fornecem uma indicação em tempo real da eficácia dos modelos de requisitos, do projeto e do código; da eficiência dos casos de teste; e da qualidade geral do software que será criado.
Clique na barra para ver as informações.
Métricas de PRODUTO
As métricas de produto têm por objetivo analisar as características físicas do software, e podem ser subdivididas em:
· métricas para o modelo de requisitos;
· métricas para o modelo de projeto;
· métricas de projeto para webapps e aplicativos móveis;
· métricas para código-fonte;
· métricas para teste;
· métricas para manutenção.
Como exemplo de métricas de produtos, temos pontos de função e linhas de código, que objetivam determinar o tamanho de um software e que serão derivadas nas estimativas de esforço, tempo, custos e recursos (pessoas).
Métricas orientadas a tamanho
O tamanho de um software é a sua dimensão mais importante, pois é a partir dele que são derivados os principais indicadores que serão utilizados desde as estimativas iniciais do projeto até a entrega final do produto. Durante muito tempo, a comunidade de Engenharia de Software vem discutindo qual é a melhor medida para representar o tamanho de um software, e a unidade mais intuitiva é o número de linhas de código.
As métricas de software orientadas a tamanho consideram o tamanho físico do software que foi produzido (linhas de código), e referem-se a todas as atividades de engenharia (análise, projeto, código, teste). Essas métricas são derivadas de bases históricas de projetos e criadas pela normalização de medidas de qualidade e/ou produtividade.
Atenção
A partir de dados contidos nos registros históricos dos projetos, podemos derivar algumas métricas orientadas a tamanho como: Erros por KLOC (mil linhas de código), Defeitos por KLOC, $ (Custo) por KLOC e Páginas por KLOC. Além desses exemplos, podem ser calculadas outras métricas interessantes, que não necessariamente utilizem linhas de código como: Erros por pessoa-mês e $ (Custo) por página de documentação.
Apesar dos esforços feitos na tentativa de normatizar as linhas de código (LOC) como uma unidade de medida padrão, elas ainda não são universalmente aceitas como o melhor modo de medir, pois pode-se incorrer no risco de dois pesos e duas medidas, se alguns pontos não forem esclarecidos como:
· Inclusão na contagem da quantidade de linhas de comentários, linhas em branco ou comandos nulos;
· Inclusão na contagem de diretrizes de compilação;
· Contagem de múltiplos comandos ou declarações em uma única linha como várias linhas, uma para cada comando ou declaração;
· Contagem de uma única linha nos casos em que um único comando ou declaração é expresso em múltiplas linhas;
· Inclusão na contagem de delimitadores de blocos de comandos nos casos em que, de fato, haja mais de um comando;
· Desconsideração de blocos de comandos nos casos em que sua utilização seja opcional.
Um dos modelos baseados em LOC mais conhecidos é o COCOMO (COnstructive COst Model ou Modelo de Custo Construtivo), proposto em 1981 pelo Dr. Barry Boehm. Esse modelo utiliza LOC como subsídio para a geração de estimativas de esforço, prazo e custo. Com o surgimento de novas tecnologias como componentização e programação visual, um novo modelo foi proposto para contemplar esses aspectos e ficou conhecido como COCOMO II.
Os apoiadores das métricas do LOC argumentam que como as linhas de código são um artefato de todos os projetos de software, podem ser facilmente contadas, além de haver uma gama de literatura, dados e modelos baseados em LOC, como o COCOMO.
Por outro lado, os opositores argumentam que a dependência da linguagem de programação torna o LOC uma unidade de medida duvidosa ao se comparar projetos desenvolvidos em diferentes linguagens de programação, como, por exemplo, COBOL e JAVA, pois os números são penalizados devido às diferenças tecnológicas, como a tecnologia orientada a objetos que oferece recursos como reutilização, tornando o código em JAVA mais curto e eficiente. A dificuldade na obtenção de estimativas nas fases iniciais do projeto utilizando LOC é outro fator que motivou o surgimento de outras métricas no mercado.
Métricas orientadas a função
Em decorrência da urgência na solução dos reveses que aconteciam nos projetos que utilizavam o LOC (linhas de código) como unidade de medida padrão, em 1975, Allan Albrecht definiu os conceitos que serviriam de base para a métrica de ponto de função (FP, function point), e esta passou a ser a métrica funcional mais usada.
Saiba mais
As métricas orientadas a função, ou simplesmente, métricas funcionais, fornecem uma medida da funcionalidade oferecida pela aplicação como valor de normalização. A funcionalidade é medida indiretamente, a partir de outras medidas diretas, e o valor resultante é denominado tamanho funcional do sistema.
A métrica funcional tem como objetivos: medir a funcionalidade solicitada, reconhecível e recebida pelo usuário, e medir de forma independente da tecnologia utilizada, dentro de uma ótica de negócio e não técnica. Além disso, as métricas funcionais devem ser simples, para viabilizar o esforço de medição, e consistentes entre diferentes projetos, organizações e tecnologias.
Para entendermos melhor as diferenças entre as métricas de linhas de código (LOC) e pontos de função (PF), vamos observar o quadro comparativo a seguir.
	LOC
	PF
	Necessário que se esteja em um estágio adiantado do projeto.
	Estimativa de tamanho pode ser realizada na fase inicial do projeto.
	Atrasa na geração de indicadores úteis.
	Gera indicadores úteis desde a fase inicial do projeto.
	Definição da linguagem de programação nem sempre é realizada na fase inicial do projeto.
	Independente da tecnologia empregada.
	Indicadores penalizados devido às técnicas de engenharia utilizadas, como reutilização.
	Indicadores são independentes de requisitos não funcionais.
Quadro: LOC x PF.
Elaborado por: Bruno Freitas Braga
A relação entre linhas de código e pontos de função não é uma relação linear; no entanto, o QSM (Quantitative Software Management ou Gerenciamento Quantitativo de Software) elaborou um estudo relacionando essas duas unidades de medida, fornecendo estimativas aproximadas da média do número de linhas de código necessárias para criar um ponto de função em várias linguagens de programação.
O IFPUG (International Function Points Users Group) elaborou um manual de práticas de contagem conhecido como CPM (Counting Practices Manual) cuja última versão é a 4.3.1, para normatizar a medição do tamanho funcional utilizando pontos de função.
A técnica da APF (Análise de Pontos de Função) passou a ser a mais utilizada no Brasil desde os anos 1990, principalmente nas licitações públicas de projetos de desenvolvimento de software, e o Portal da Transparência do Governo Federal oferece uma gama de dados a respeito de projetos de software concluídos e em andamento utilizando essa métrica.
As principais métricas funcionais usadas no mercado são pontos de função e pontos de caso de uso; no entanto, o último ainda não está aderente ao padrão ISO, sendo relativamente novo e pouco utilizado.
Classificação das métricas em Engenharia de Software
O especialista apresentará os tipos de métricas utilizadas em sistemas de software, de acordo com diferentes critérios de classificação.
Verificando o aprendizado
Parte superior do formulário
1. Sobre as métricas diretas e indiretas, assinale a alternativacorreta.
As métricas diretas são derivadas a partir de outras métricas e são mais complexas de serem obtidas.
A quantidade de linhas de código, o número de defeitos e o custo do software são exemplos de métricas indiretas.
As medidas diretas são mais fáceis de serem obtidas, pois podem ser obtidas a partir da observação direta dos atributos envolvidos.
A complexidade ciclomática é um exemplo de uma métrica indireta e mede a quantidade de caminhos de execução dependentes a partir do código fonte.
Qualidade, confiabilidade, eficiência e capacidade de manutenção são exemplos de métricas diretas.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "C" está correta.
As métricas diretas são mais fáceis de serem obtidas, pois, assim como ocorrem com as métricas que são utilizadas para observar os fenômenos da natureza como massa, tensão elétrica, temperatura etc., são obtidas a partir da simples observação dos atributos envolvidos. Por exemplo, o número de linhas de código e o número de defeitos de um software são métricas obtidas a partir de uma simples observação.
Parte superior do formulário
2. No contexto da Engenharia de Software, as métricas de software são divididas em métricas de processo, métricas de projeto e métricas de produto. Sobre essas métricas, assinale a alternativa correta.
As métricas de processo são usadas com finalidade tática, visando obter o benefício de seu uso nos projetos correntes.
Modelos como o CMMI (Capability Maturity Software Integration ou Modelo Integrado de Maturidade em Capacitação) e o MPS-BR (Melhoria de Processo de Software Brasileiro) apresentam um conjunto de boas práticas de melhoria de processo de software.
As métricas de projeto são usadas com finalidade estratégica, visando obter os benefícios de seu uso em todos os projetos da organização.
As métricas de produto são usadas para avaliar se o projeto está seguindo o cronograma conforme foi estimado na etapa de planejamento e se está dentro do orçamento proposto no início do projeto.
Taxa de produção, horas de revisão e tamanho são exemplos de métricas de processo.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
Modelos como o CMMI e o MPS-BR vêm sendo adotados cada vez mais pelas empresas de Tecnologia da Informação com o objetivo de atestar a qualidade e o nível de maturidade dos seus processos de desenvolvimento de software
Avalie este módulo:
 
    
MÓDULO 4
Empregar métricas de software no acompanhamento da evolução de um projeto
O processo de medição de software
Para entendermos como fazer o acompanhamento das métricas durante o ciclo de vida do software, iremos abordar nesta seção os princípios e o funcionamento do processo de medição de software.
Um processo de medição é o conjunto de atividades repetitivas aplicadas a um processo existente, com o objetivo de extrair métricas e indicadores a partir dos resultados obtidos dos processos medidos.
Basicamente, a medição pode ser um conjunto de atividades de um processo existente ou ser um processo mais amplo que envolve medir outras atividades. Seu objetivo principal é prover informação relevante e confiável para permitir o gerenciamento do processo alvo.
Um processo de medição pode ser caracterizado por cinco atividades: formulação, coleta, análise, interpretação e feedback (realimentação).
Clique nas informações a seguir.
Formulação
A formulação consiste na derivação de medidas e métricas de software adequadas para a representação do software considerado.
Coleta
A coleta consiste no mecanismo usado para acumular os dados necessários.
Análise
A análise consiste no cálculo de métricas e aplicação das ferramentas matemáticas.
Interpretação
A interpretação consiste na avaliação das métricas em um esforço para ganhar profundidade na visão da qualidade de representação.
Feedback
O feedback (realimentação) consiste nas recomendações derivadas da interpretação das métricas de produto transmitidas à equipe de software.
O processo de medição de software é um processo cíclico e que envolve: planejar, medir, analisar os dados, tomar decisões baseadas na análise, implementar as decisões e voltar a planejar e medir.
Um processo de medição deve fornecer uma base para a melhoria contínua do processo, quantificar a qualidade e produtividade, estar integrado com o ciclo de vida de desenvolvimento e medir o impacto de vários métodos, ferramentas e técnicas de melhorias.
A figura abaixo ilustra como esse processo é realizado no PSM, à semelhança do clássico ciclo P-D-C-A (do inglês Plan – Do – Check – Act, ou seja, Planeje – Faça – Avalie – Aja).
Os princípios do processo de medição do software são:
1
Medições devem ter seu uso focado para medir processos.
O processo de medição deve ter propósitos bem definidos.
2
3
O processo de medição deve ser solidamente ligado ao processo de gerência da qualidade e integrado a planos e orçamentos.
O processo de coleta de dados deve ser simples e utilizar ferramentas automáticas para extração de dados.
4
5
As medições devem ser repetíveis independentemente do observador.
O processo de medição é contínuo e sujeito à melhoria.
6
7
Os resultados das métricas devem ser compartilhados com os desenvolvedores.
Os principais problemas encontrados durante o processo de medição de software são:
Clique nas informações a seguir.
Overkill
(exagero)
Consiste na coleta de muitos dados e em desperdício de esforço.
Measurement Dysfunction (disfunção de medição)
Ocorre quando as métricas de dados reais podem se tornar problemáticas por causa do seu uso indevido e da avaliação de pessoas, que pode variar de uma para outra.
Measurament Mismatch (medição incompatível)
Consiste na derivação de medidas erradas, ambíguas ou inconsistentes.
Proccess Mismatch (processos incompatíveis)
Consiste em medidas que reforçam os processos errados.
Características do processo de medição
Um processo de medição deve atender a todos os itens a seguir para se tornar eficiente e eficaz:
Melhorar a rapidez na obtenção de métricas e indicadores do processo medido, ou seja, deve promover um aumento na velocidade que levamos para recuperar, analisar e demonstrar os resultados das medições.
Garantir a confiabilidade dos resultados obtidos, prevendo etapas de verificação e validação dos dados obtidos, de forma a tentar eliminar possíveis distorções resultantes de dados “poluídos”.
Garantir que a coleta dos dados seja obtida da maneira mais direta possível, isto é, procure maneiras de automatizá-la usando ferramentas nas quais os dados são colhidos diretamente da execução dos processos.
Garantir que o armazenamento dos dados seja feito de maneira controlada, ou seja, é necessário controlar quem registrou, quando registrou, quando alterou e outras informações relevantes que permitam rastrear a origem do dado.
Garantir que os resultados sejam formatados e apresentados de maneira apropriada, usando gráficos, histogramas, linguagem do público-alvo e outros recursos que permitam a comparação dos resultados.
Garantir a correta contextualização e interpretação, de modo que as informações apresentadas possuam atributos que facilitem a comunicação com o público-alvo e que identifiquem sobre o que se está falando.
Garantir a segurança da informação, evitando que dados sensíveis da empresa caiam em mãos erradas, como, por exemplo, um cenário de corte de recursos que a empresa esteja planejando, com base nos resultados obtidos.
Promover a melhoria contínua do processo medido, ou seja, se os resultados obtidos e apresentados não são utilizados ou não permitem que possamos avaliar se o processo medido necessita ou não de mudanças, todo esforço de medição foi em vão.
Perspectivas
Para medir um processo de software, cinco perspectivas podem ser adotadas, como perguntas a serem respondidas, de maneira que se possa englobar tudo o que se pode medir:
Clique nas informações a seguir.
Performance
O que o processo está produzindo agora, de acordo com os atributos de qualidade, quantidade, custo e tempo?
Estabilidade
O processo que estamos medindoestá se comportando de maneira previsível?
Conformidade
O processo é suportado de maneira suficiente? Ele é executado de maneira fiel? A maturidade da empresa é adequada para a execução do processo?
Capacidade
O processo é capaz de entregar os produtos que atendem aos requisitos? A performance do processo atende às necessidades de negócio da empresa?
Melhoria
O que podemos fazer para melhorar a performance do processo? O que podemos fazer para reduzir a variabilidade? Como podemos elevar as médias para níveis mais rentáveis? Como podemos saber se as melhorias que implantamos estão funcionando?
As perspectivas são grupos de métricas utilizadas para responder a perguntas específicas, de um ponto de vista comum, relativas ao processo medido.
Indicadores de performance
A perspectiva de performance agrupa os indicadores para medir os resultados do processo, utilizando valores históricos para saber como o processo se comportou no passado, comparando os resultados atuais e podendo, em certas condições, indicar uma previsão de resultados futuros.
Os indicadores de performance devem satisfazer os seguintes critérios para serem considerados bem definidos:
Comunicação
As métricas de performance devem:
· estar fortemente relacionadas à questão estudada;
· ter alto conteúdo informativo;
· refletir a realidade;
· permitir e facilitar a coleta de dados;
· ter os dados coletados bem definidos;
· demonstrar variações mensuráveis;
· demonstrar um valor diagnóstico, indicando a causa do problema.
Repetição
Garantir que, se outra pessoa repetir a medição, obtenha os mesmos resultados.
Rastreabilidade
Garantir que os dados originais possuam atributos de rastreabilidade, como data, horário, atividade, sequência, produto, projeto, status, ambiente, ferramentas utilizadas, responsável pela coleta etc.
Exemplos de indicadores de performance são: estimativas de prazo, prazo real, estimativas de custo, custo real, número de defeitos previstos, tamanho do software e produtividade.
Mudança organizacional
A implantação do processo de medição de software envolve muitos desafios com os quais muitas empresas terão que aprender a lidar com a implantação do novo processo. Esses desafios envolvem mudança organizacional, ou seja, mudanças no comportamento da empresa.
A mudança organizacional geralmente ocorre em resposta a pressões externas ou internas. Conduzir uma boa mudança organizacional faz parte do que chamamos de gestão de mudanças.
Pequenas empresas comerciais precisam se adaptar para sobreviver contra concorrentes maiores. Elas também precisam aprender a prosperar nesse ambiente. Os grandes rivais precisam se adaptar rapidamente quando um concorrente menor e inovador entra em cena.
Para evitar ficar para trás, ou para permanecer um passo à frente de seus rivais, uma empresa deve buscar maneiras de operar com mais eficiência. Também deve se esforçar para operar de maneira mais econômica.
Os elementos da mudança são: visão, habilidades, incentivos, recursos e plano de ação.
Para entendermos como implementar a mudança organizacional, iremos dividir os tipos de medições em estratégicas e táticas. As medições estratégicas estão alinhadas com as metas da empresa, enquanto as medições táticas estão alinhadas com as metas operacionais e com as decisões técnicas.
Os tipos de dados que nos dão a sensibilidade sobre as medidas estratégicas e táticas são agrupados nas seguintes categorias: hard, soft e padronização. Os tipos de dados hard são quantitativos, empíricos e numéricos, enquanto os tipos de dados soft são qualitativos, baseados em julgamentos e opiniões, e, por fim, os tipos de dados padronização criam métricas padrões que podem ser calculadas para diferentes situações. A tabela a seguir mostra medidas eficazes que podem nos auxiliar a implementar a mudança organizacional.
	Tipo de dados
	Medidas estratégicas
	Medidas táticas
	Hard
	Estudos de mercado
	Número de profissionais por tarefa
	
	Estudos de lucratividade
	Esforço por atividade ou tarefa
	
	Custos anuais de software
	Custos por atividade ou tarefa
	
	Custos anuais de hardware
	Projetos entregues
	
	Custos anuais de pessoal
	Taxas de produção do staff
	Soft
	Objetivos executivos
	Efetividade de ferramentas
	
	Cultura corporativa
	Utilidade de métodos
	
	Análise competitiva
	Habilidades de profissionais
	Padronização
	Total de pontos de função
	Tamanho do projeto
Quadro: Medidas estratégicas e táticas do processo de medição de software
Elaborado por: Bruno Freitas Braga.
Métricas e medidas em Engenharia de Software
O especialista apresentará conceitos sobre métricas e medidas em sistemas de software, ressaltando a sua importância no ciclo de vida dos sistemas.
Verificando o aprendizado
Parte superior do formulário
1. Sobre o processo de medição de software, podemos afirmar:
Medições devem ter seu uso focado para medir projetos.
Pode ser caracterizado por cinco atividades: formulação, coleta, análise, interpretação e feedback.
No processo de medição, as métricas são definidas no início do projeto, não havendo a necessidade de reavaliá-las, pois a avaliação já foi realizada durante a definição das métricas.
Durante a atividade de feedback ou reavaliação, as métricas são compartilhadas apenas entre os profissionais envolvidos no gerenciamento de projetos.
O processo de medição deve avaliar somente os projetos concluídos a fim de determinar quais métricas serão utilizadas nos novos projetos.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
O processo de medição é caracterizado por cinco atividades, e na atividade de formulação são derivadas as medidas e métricas adequadas para o software, enquanto na coleta são criados os mecanismos para acumular os dados necessários. Já na análise ocorre o cálculo das métricas, e na interpretação é realizada a análise dos resultados, para dar o feedback à equipe.
Parte superior do formulário
2. A mudança organizacional é um dos principais desafios para implementar o processo de medição de software. Sobre essa afirmativa, assinale a alternativa correta.
A mudança organizacional está alinhada apenas com as metas operacionais e técnicas da empresa, como a medição da efetividade de ferramentas.
Para entendermos o processo de mudança organizacional, devemos primeiro classificar os tipos de dados em hard, soft e padronização e derivar medidas eficazes a partir deles.
O processo de mudança organizacional deve ser baseado nas opiniões dos especialistas que fazem uma avaliação da situação e determinam as mudanças eficazes.
As medições estratégicas estão alinhadas com as metas operacionais durante a implementação do processo de mudança organizacional.
Os dados qualitativos são suficientes para a definição das medidas estratégicas e táticas.
Parte inferior do formulário
Comentário
Parabéns! A alternativa "B" está correta.
A partir da classificação dos dados em hard (dados quantitativos), soft (dados qualitativos) e padronização (métricas padrões), as medidas estratégicas e táticas necessárias para o processo da mudança organizacional são definidas e implementadas durante o processo de medição de software. Durante o processo de medição, as medidas são avaliadas quanto à sua eficácia.
Avalie este módulo:
 
    
Conclusão
Considerações Finais
Como vimos, as métricas de software ajudam as empresas a compreenderem melhor os seus processos, projetos e produtos. Com um entendimento mais claro sobre os requisitos de seus projetos, os gerentes de projetos conseguem fazer estimativas de esforço, prazo e custos mais precisas.
Foram apresentados os conceitos de medida, medição e métrica, a fim de se obter um entendimento claro sobre o papel de cada um desses conceitos com o intuito de facilitar a análise dos dados obtidos nos registros históricos dos projetos e avaliá-los.
Verificamos que existem modelos para a definição de métricas, como o GQM (Goal/Question/Metrics) e o PSM (Practical Software Systems Measurement), que nos apoiam na determinação das melhores métricas a serem utilizadas na organização.
Analisamosas métricas de tamanho como LOC (linhas de código) e PF (pontos de função) e verificamos como derivar indicadores a partir delas com o objetivo de planejar e controlar melhor os nossos projetos.
Vimos que as métricas de processo permitem que a organização tenha uma visão estratégica, fornecendo informações sobre a eficiência de um processo de software, em conformidade com seus objetivos e suas metas.
Por fim, compreendemos como funciona o processo de medição de software para o acompanhamento das métricas durante o ciclo de vida de desenvolvimento do software.
image5.jpeg
image6.jpeg
image7.jpeg
image8.jpeg
image9.jpeg
image10.jpeg
image11.jpeg
image12.jpeg
image13.jpeg
image14.jpeg
image15.jpeg
image16.jpeg
image17.jpeg
image18.jpeg
image19.jpeg
image20.jpeg
image21.jpeg
image22.jpeg
image23.jpeg
image24.jpeg
image25.jpeg
image26.jpeg
image27.jpeg
image28.jpeg
image29.jpeg
image30.jpeg
image31.jpeg
image32.jpeg
image33.jpeg
image34.jpeg
image35.jpeg
image36.jpeg
image1.jpeg
image37.jpeg
image38.jpeg
image39.jpeg
image40.jpeg
image2.jpeg
image41.jpeg
image42.jpeg
image43.jpeg
image44.png
image45.png
image46.jpeg
image3.jpeg
image47.jpeg
image4.jpegUm processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação de artefatos de software gráficos, denominados de diagramas, que podem ser complementados por descrições textuais.
Por que é definida como linguagem?
 
Uma linguagem serve para a comunicação, possuindo uma sintaxe e uma semântica associada. A sintaxe determina o padrão de escrita, tal como, a estrutura de uma frase formada por “sujeito + verbo + predicado” e a semântica está associada ao significado da frase, tal como, “Carlos foi ao clube”. Fazendo uma analogia com a UML, a Figura 6 ilustra a estrutura de uma classe, cujo padrão inclui o nome da classe, atributos e métodos, ou seja, esse padrão de desenho, ou sintaxe do modelo, é definido pela UML.
	Nome da Classe
	+ atributoPublico: tipo
# atributoProtegido: tipo
- atributoPrivado: tipo
	+ operacao(argumento): tipoRetorno
E a semântica?
 
A partir do momento que construímos um diagrama com um conjunto de classes, assim como ilustrado na Figura 7, temos então a formação de uma rede semântica, na qual os objetos e associações representam uma abstração da estrutura estática de certo domínio do problema.
Figura 7 – Exemplo de Diagrama de Classes
E a comunicação?
 
Como já afirmado, uma linguagem serve para comunicação. No caso do desenvolvimento de software, um modelo permite a comunicação entre engenheiros de software, entre estes e os usuários para validação dos referidos modelos, entre estes e os gerentes de projeto ou programadores; enfim, caso você, como engenheiro de software, desenhe um diagrama de classes, a semântica será compreendida por qualquer outro engenheiro de software que faça uso do paradigma orientado a objetos.
Figura 8 – Diagramas da UML
A Figura 8 ilustra os diagramas especificados na UML, com destaque para as duas categorias: diagramas comportamentais e diagramas estruturais. Os diagramas comportamentais têm ênfase na abstração funcional do projeto de software e os diagramas estruturais, nas abstrações das estruturas de dados e de componentes.
Processo unificado
O Processo Unificado, também denominado de Rational Unified Process (RUP), é um processo de desenvolvimento de software criado pela Rational Software Corporation, empresa fundada pelos criadores da UML, posteriormente adquirida pela IBM.
O RUP é considerado um processo formal que permite ser utilizado na solução de problemas com alta complexidade, entretanto, pode ser customizado para projetos de qualquer escala.
O RUP possui três princípios:
Guiado por casos de uso
O planejamento do desenvolvimento é feito em função dos casos de uso, de modo que o processo é iniciado pela abstração funcional, ou seja, pelos serviços desejados pelos usuários.
Centrado em arquitetura
O RUP enfatiza o papel da arquitetura permitindo ao arquiteto de software manter o foco nas metas corretas, tais como, compreensibilidade, confiança em mudanças futuras e reutilização.
 
A arquitetura deve permitir a realização dos requisitos, abrangendo um conjunto de decisões estruturais e comportamentais, alinhado às duas categorias de diagramas ilustradas na Figura 8, com destaque para a modularização da solução.
Iterativo e incremental
O RUP aplica o modelo de processo de software iterativo e incremental. De forma evolucionária, novos requisitos são incorporados ocorrendo o versionamento das entregas de software ao usuário final, fundamental ao desenvolvimento de software moderno. Não necessariamente deve ocorrer uma entrega ao final de uma iteração.
A Figura 9 ilustra o aspecto bidimensional do RUP. Na horizontal, temos as fases que permitem capturar o aspecto temporal do projeto, que podem ser utilizadas como marcos durante esse projeto, e na vertical, as atividades iterativas. Vejamos as descrições dessas fases.
Figura 9 – O Processo Unificado
O Processo Unificado (Rational Unified Process)
Veja mais detalhes sobre as etapas do modelo unificado a seguir:
Iniciação
A fase de iniciação, também denominada de concepção, exige do engenheiro de software uma visão inicial e geral do sistema a ser desenvolvido, cabendo destacar a possibilidade da utilização dos modelos de estado ou de atividades no desenho dos processos de negócio, isto é, a aplicação da primeira atividade do fluxo de trabalho que é a modelagem de negócio. Tal modelagem permite aos engenheiros de software compreender o negócio e garantir que todas as partes interessadas tenham um entendimento comum do domínio do problema.
 
A partir dessa compreensão do negócio, pode-se obter os requisitos fundamentais do projeto, isto é, requisitos funcionais e não funcionais. Em seguida, realizar a modelagem dos casos de uso mais críticos, incluídos os principais serviços disponibilizados aos usuários, e a modelagem de classes, para entendimento da estrutura de dados a ser gerenciada pelo sistema.
 
A identificação dos principais requisitos, junto aos modelos de casos de uso e classes iniciais, permite o estabelecimento do escopo do projeto. Nessa fase, a arquitetura do sistema limita-se a um esquema provisório com os principais subsistemas e as funções e recursos que o compõem.
 
Temos agora dois grandes desafios aplicáveis a muitos projetos de software: verificar a viabilidade técnica e financeira do projeto, bem como garantir o seu financiamento, visto que ambos os desafios incluem também a análise de riscos.
 
Podemos avançar com o projeto? Caso positivo, vamos realizar o planejamento detalhado da fase de Elaboração e geral das demais fases. Caso negativo, encerramos nossas atividades.
Elaboração
Com o projeto de software aprovado, iniciamos a fase de elaboração, que é realizada de forma iterativa e incremental, de acordo com a Figura 9. Vamos reduzir o nível de abstração dos modelos de casos de uso e de classes iniciais, finalizando a atividade de análise do processo de software.
 
Na sequência, temos a atividade de projeto na qual ocorre o refinamento de alguns modelos da análise e a criação de novos, assim como o modelo de interação, que representa os aspectos dinâmicos do sistema, além de construir um protótipo da interface com o usuário. A representação arquitetural é expandida em cinco visões do software: modelo de casos de uso, modelo de análise, modelo de projeto, modelo de implementação e modelo de implantação. Cada visão inclui um conjunto de modelos com seus respectivos diagramas. Nessa fase, devemos, também, minimizar os riscos e realizar o planejamento da fase de construção.
Construção
A fase de construção segue o modelo de arquitetura gerando os componentes, ou aplica-se o reuso, que tornam os casos de uso operacionais para os usuários.
 
Os modelos gerados na fase de elaboração são concluídos para refletir a versão final do incremento de software. Com o avanço da codificação, são realizados os testes unitários, os testes de integração entre os componentes e os testes de validação, até o teste beta, em que os usuários realizam a validação em ambiente de desenvolvimento controlado.
Transição
A fase de transição tem como objetivo realizar a implantação do software no ambiente de produção. Inicialmente, o software é disponibilizado aos usuários para realização do teste beta em ambiente não controlado pelo desenvolvimento, tendo como foco a correção de defeitos e mudanças necessárias em função dos feedbacks dos usuários.
 
Nessa fase, podem ocorrer a elaboração dos manuais do usuário, treinamento dos usuários, procedimentos de instalação, montagem de estrutura de suporte ou definição do processo de manufatura. Na conclusão dessa fase, o incremento torna-se uma versão de produção utilizável pela comunidade de usuários.
Fluxo de Trabalho
Após o detalhamento das fases do RUP ilustradas na Figura 9, vamos entender as atividades transversais. Essas atividades, que correspondem às atividades genéricas de um processo de desenvolvimento de software, apresentadas anteriormente, compõem o denominado fluxo de trabalho, sendo as atividades distribuídas em todas as fases.
 
Como ocorre o relacionamento entre as dimensões fases do projeto X fluxos deprojeto da Figura 9?
 
Cada atividade do fluxo de trabalho se desenvolve de forma mais intensa em determinada fase. Por exemplo, os fluxos de trabalho da modelagem de negócio e requisitos são intensos na fase de concepção, justamente quando são definidos os requisitos de alto nível do negócio; a análise e design, i.e., projeto, tem uma intensidade na concepção em função dos modelos de análise e projeto, entretanto podemos observar alguma atividade na fase de construção, pois alguns modelos são refinados nesta fase do software.
 
Por que ocorre a atividade de implementação na fase de elaboração? Essa fase não é intensa em análise e projeto?
 
Lembra-se da prototipação? Podemos nessa fase validar algum requisito do software aplicando a prototipação que inclui atividade de codificação, i.e., implementação.
 
O RUP define três grupos de atividades de apoio ao desenvolvimento do software:
Ambiente
Inclui as atividades necessárias para configurar os processos e as ferramentas que darão suporte à equipe de desenvolvimento.
Gerenciamento de configuração e mudança
Permite a estruturação sistemática dos artefatos, tais como documentos e modelos, que precisam estar sob controle de versão, devendo essas alterações serem visíveis.
Gerência de projeto
Enfatiza a importância do gerenciamento de projetos; nessa atividade, sugerimos a utilização das melhores práticas contidas no PMBOK (o guia Project Management Body of Knowledge é um conjunto de práticas na gestão de projetos organizado pelo instituto PMI, sendo considerado a base do conhecimento sobre gestão de projetos por profissionais da área.
Resumindo
Neste módulo, pudemos avaliar a importância do Processo Unificado no contexto do desenvolvimento de software. Inicialmente, apresentamos a UML, linguagem de modelagem unificada, a qual define o padrão dos artefatos de software de acordo com o paradigma de desenvolvimento orientado a objetos a serem utilizados em dado modelo de processo de desenvolvimento de software.
 
Prioritariamente, o RUP é um modelo de processo de software para o desenvolvimento de acordo com o paradigma orientado a objetos. Esse processo tem um alto grau de formalismo, possuindo os seguintes princípios: baseado em casos de uso, centrado em arquitetura e iterativo e incremental. Enfim, se o problema for complexo, o RUP é um forte candidato a ser escolhido por algum engenheiro de software como requisito não funcional “modelo de processo de software”.
Atenção
Vale destacar que o RUP pode ser ajustado a qualquer escala de complexidade e a seleção do requisito não será tão simplista
Questão 1
(Referência: CESPE - 2010 - TRE-MT - Analista Judiciário - Tecnologia da Informação) O RUP (Rational Unified Process) é uma técnica usada na modelagem de sistemas. Com relação a esse assunto, assinale a opção correta:
A
Uma das principais características do RUP é o uso da iteração que, por meio de refinamentos sucessivos, melhora o entendimento do problema.
B
O RUP fornece uma metodologia que utiliza um conjunto de ferramentas, modelos e entregáveis que interage diretamente com o código do sistema desenvolvido, agilizando o processo de compilação.
C
Pelo fato de o RUP ser muito complexo, seu foco evita a redução dos riscos do projeto. Essa fase é tratada diretamente na UML.
D
O RUP reduz sensivelmente os requisitos de documentação de um projeto.
E
O RUP tem dois modelos de comunicação: um para ambientes fora da equipe de desenvolvimento e outro exclusivo para a equipe de desenvolvimento.
Responder
Parabéns! A alternativa A está correta.
O RUP possui como princípio, entre outros, ser iterativo e incremental. Iterativo porque as atividades se repetem a cada nova iteração, permitindo um melhor entendimento do negócio, ou seja, compreensão gradativa dos requisitos de software à medida que o desenvolvimento avança.
Questão 2
(Prefeitura Municipal de Jataí - Analista de Tecnologia da Informação (Quadrix - 2019).
 
Acerca da linguagem de modelagem unificada (UML), assinale a alternativa correta:
A
A UML é uma linguagem de código que tem a finalidade de criar, especificamente, o modelo físico de determinado sistema.
B
Sua sintaxe foi projetada apenas para atender às linguagens‐alvo mais recentes, como a JavaScript.
C
Apesar de ser uma ferramenta de modelagem muito poderosa, ela não é capaz de capturar conhecimento e expressá‐lo.
D
A UML tem a finalidade de documentar e visualizar os artefatos que são especificados e construídos na análise e no desenho de um sistema.
E
A melhor definição para a UML, de acordo com diversos analistas, é que ela é uma linguagem de programação visual.
Responder
Parabéns! A alternativa D está correta.
A UML é uma linguagem de modelagem que permite a especificação de artefatos de software gerados nas etapas de análise e projeto de um processo de software.
Desenvolvimento Ágil de Software
Até meados dos anos 1990, os processos de desenvolvimento de software prescritivos exigiam um detalhado planejamento de projeto, um sistema de garantia da qualidade estabelecido, a aplicação de métodos de análise e projeto, tal como a modelagem de caso de uso, apoiados por ferramentas CASE e controlados por um disciplinado e formal modelo de processo de desenvolvimento de software.
Essa visão era influenciada por equipes de engenheiros de software engajados em sistemas de software complexos que exigiam um esforço significativo de planejamento, projeto e documentação de sistema.
 
Mas esse esforço justifica-se em sistemas de menor grau de complexidade?
 
Em 2001, um grupo de 17 metodologistas e outros profissionais da indústria de software se reuniram no estado norte-americano de Utah para discutir e propor uma alternativa aos processos prescritivos dominantes à época. Ao final da reunião, esse grupo lançou as bases para um novo conceito de processo de software, as quais foram registradas em um documento que chamaram de Manifesto para o Desenvolvimento Ágil de Software, que inclui quatro valores:
 
· Indivíduos e interações, mais do que processos e ferramentas.
· Software em funcionamento, mais do que documentação abrangente.
· Colaboração com o cliente, mais do que negociação de contratos.
· Resposta a mudanças, mais do que seguir um plano.
 
A maioria dos métodos ágeis de desenvolvimento de software têm foco no próprio software, em vez de em seu projeto e documentação, assumem um fluxo de processo iterativo e incremental para entrega de software e apoiam aplicações de negócios nas quais os requisitos possuem alta volatilidade durante o desenvolvimento.
Um projeto de software ágil busca a capacidade de implantar uma nova versão a cada incremento, enfatizando o software funcional como uma medida primária de progresso.
A entrega de software rápida permite que os clientes validem de forma imediata o incremento, indicando possíveis erros ou alterações de requisitos, bem como descrevendo novos requisitos para as próximas iterações.
Atenção
Métodos ágeis também enfatizam comunicações em tempo real entre equipe de desenvolvimento e clientes.
Extreme programming - XP
A Extreme Programming, ou simplesmente XP, é considerada um processo de desenvolvimento de software ágil, tendo sido proposta por Kent Beck em 1999. A XP adota valores que servem como critérios que norteiam as partes interessadas de um projeto, incluindo: comunicação, simplicidade, feedback, coragem e respeito.
 
Vejamos uma breve descrição de cada valor:
Comunicação
A comunicação objetiva construir um entendimento dos requisitos com o mínimo de documentação formal e o máximo de interação entre equipe de desenvolvimento e clientes.
Simplicidade
A simplicidade sugere que a equipe adote soluções mais simples, criando um ambiente onde o custo de mudanças no futuro seja baixo.
Feedback
O feedback permite que os programadores também tenham feedback quando da execução dos testes e quando da validação funcional por parte dos clientes, permitindo a correção de erros e alterações nos requisitos.
Coragem
A coragem é necessária para lidar com o risco de erro, que deve ser considerado naturale se traduz em confiança nos seus mecanismos de prevenção e proteção.
Respeito
O respeito é o valor mais básico e que dá sustentação a todos os demais, e sem o qual não haverá nada que possa salvar um projeto de software do insucesso.
Saiba Mais
Assim como um segundo nível de abstração, a XP possui cinco princípios que servem para ajudar a equipe de software na escolha de alternativas de solução de problemas durante o projeto. Os princípios incluem: feedback rápido, assumir simplicidade, mudança incremental, abraçando mudanças e trabalho de qualidade.
A XP possui doze práticas que se enquadram nos valores e princípios descritos na tabela a seguir:
	TABELA 1 – Doze práticas enquadradas nos valores e princípios da XP
	Prática
	Descrição
	Jogo de Planejamento
	Os requisitos são registrados em cartões, ou fichas, denominados “história de usuários”, sendo a descrição e a priorização realizadas pelos clientes. A equipe de desenvolvimento estima a duração de cada release.
	Pequenas Releases
	Cada release deve ser a menor possível, incluindo os requisitos mais importantes para o negócio. As releases frequentes permitem um maior feedback para clientes e equipe de desenvolvimento, facilitando o aprendizado e a correção dos defeitos do software.
	Metáfora
	Facilita a comunicação com o cliente, entendendo a sua realidade, isto é, procura traduzir as palavras do usuário para o significado que ele espera dentro do projeto. Como exemplo, a metáfora “Estoque 4.0” para um subsistema de gestão virtual dos estoques no contexto de um sistema de logística.
	Projeto Simples
	Projeto simples inclui projetar somente as histórias de usuários, ou funcionalidades, previamente definidas, bem como se concentrar em soluções de projeto simples e bem estruturadas, tal como o menor número possível de classes e métodos.
	Cliente no local de Trabalho
	Incluir um cliente na equipe de desenvolvimento para responder perguntas, ou alguém da parte do cliente com conhecimento do negócio. O cliente é protagonista em um projeto XP.
	Semana de 40 horas
	Estimula a busca de um ritmo sustentado de trabalho, tal como 40 horas semanais. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto, devendo estar restringidas a duas semanas seguidas.
	Programação Pareada
	Todo código deve ser gerado por dois programadores trabalhando em um único computador. O programador codifica e o parceiro revisa e sugere. Dessa forma, o programa sempre é revisto por duas pessoas, evitando e diminuindo, assim, a possibilidade de defeitos. Com isso, busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.
	Propriedade Coletiva
	O código fonte pode ser alterado por qualquer membro da equipe de desenvolvimento, de modo que esta detém a propriedade do código. O objetivo com isso é fazer a equipe conhecer todas as partes do sistema. Os testes de unidade e integração garantem a estabilidade dessa prática.
	Padronização do Código
	A prática da propriedade coletiva de código exige o estabelecimento de regras para programar a serem seguidas por todos. O objetivo é facilitar o entendimento do código.
	Desenvolvimento Orientado a Testes
	Um framework automatizado é sugerido para a escrita dos testes unitários, antes que determinada funcionalidade seja implementada, técnica denominada “test first”.
Os testes de integração também são realizados sistematicamente.
Os testes de validação são especificados pelos clientes a partir das histórias de usuários.
	Refatoração
	A refatoração é um processo de modificar a estrutura interna do software sem alterar o seu comportamento externo, permitindo a melhoria contínua da programação com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente.
	Integração Contínua
	O sistema deverá ser integrado sempre que produzir uma nova funcionalidade. Essa continuidade permite a detecção imediata de erros de integração, evitando problemas de compatibilidade e interface.
Processo XP
A XP adota o paradigma orientado a objetos, aplicando seus valores, princípios e práticas em um processo com quatro atividades metodológicas: planejamento, projeto, codificação e testes. A Figura 10 ilustra essas atividades metodológicas propostas por Pressman (2016).
Figura 10 – O processo XP. 
O processo ágil Extreme Programming (XP)
Assista, a seguir, o processo XP e suas etapas de planejamento, projeto, codificação e teste:
O processo ágil eXtreme Programming (XP)
Veja mais detalhes sobre o processo XP e suas etapas:
Planejamento
A primeira atividade é ouvir o cliente, realizando um levantamento de requisitos que possibilite o entendimento do escopo do problema. Essa atividade gera um conjunto de histórias de usuários, escritas pelos clientes, juntamente à equipe de desenvolvimento que, de forma simplificada, compõem as necessidades destes. Cada história é colocada em uma ficha ou cartão, sendo priorizadas pelos clientes em função da agregação de valor ao negócio.
 
Após a elaboração dos cartões, a equipe de desenvolvimento avalia as histórias e as divide em tarefas, estimando o esforço e os recursos necessários à implementação. Caso o esforço exija mais do que três semanas de desenvolvimento, é preciso que o cliente fatore a história analisada em histórias menores.
 
As histórias que farão parte de cada incremento são selecionadas de forma conjunta por equipe de desenvolvimento e clientes, considerando os seguintes critérios: as histórias de maior risco serão priorizadas, em seguida, as que agregam maior valor ao negócio.
 
Após a implantação da primeira versão do software, é calculada a velocidade do projeto que é o número de histórias de usuários implementadas na primeira release. Essa velocidade serve para avaliar se o compromisso firmado está compatível e auxiliar na estimativa de prazos das versões seguintes.
Projeto
Aqui temos a máxima: “Não complique!”
 
A XP estimula a modelagem com cartões CRC (Classe-Responsabilidade-Colaborador), que permitem identificar as classes orientadas a objetos relevantes para a iteração corrente do software. Os cartões CRC são os únicos artefatos de projeto gerados durante o processo XP.
 
Caso algum requisito necessite ser validado em função de sua complexidade, é recomendada a prototipação, como solução pontual, a fim de reduzir o risco dessa especificação no projeto.
 
A refatoração também é estimulada, tendo em vista uma melhor organização do código interno do software sem impactar a sua funcionalidade, o que minimiza as possibilidades de erros.
Codificação
A XP sugere que dois programadores trabalhem juntos em um mesmo computador a fim de criarem código para uma história, fornecendo um mecanismo de solução de problemas em tempo real, cabendo a máxima de que duas cabeças pensam melhor que uma, além de garantir a qualidade do código, pois a sua revisão é imediata. Ambos desenvolvedores têm papéis distintos, tal como, uma pessoa implementa o código, outro verifica os padrões de codificação.
 
Quando da conclusão da codificação, esse código é integrado aos demais. A estratégia de integração contínua possibilita a identificação precoce de erros.
Teste
Como afirmado anteriormente, a equipe de desenvolvimento avalia cada história e a divide em tarefas, que representa uma característica discreta do sistema. Antes da codificação, a equipe de desenvolvimento elabora os testes de unidades a serem aplicados nas tarefas. A automação desses testes é fortemente recomendada, o que estimula a realização dos teste de regressão (é a reexecução de algum subconjunto de testes que já foram conduzidos para garantir que as modificações não propagaram efeitos colaterais indesejáveis) toda vez que o código for alterado.
 
A estratégia de integração contínua está vinculada aos testes de integração, realizados de forma sistemática a cada novo código gerado a ser integrado, o que permite lançar alertas logo no início, evitando propagações indesejadas.
 
Os testes de aceitação são elaborados pelos clientes com base nas histórias de usuários especificadasanteriormente e que serão implementadas na próxima release. O foco está nas funcionalidades externas visíveis aos clientes. Em outras palavras, os testes verificam se o sistema atende às reais necessidades dos usuários.
Resumindo
Neste módulo, compreendemos as principais características das metodologias ágeis e, em particular, da Extreme Programming – XP. A partir do questionamento do excesso de formalismo dos processos prescritivos dominantes em meados da década de 1990, foi redigido o Manifesto para o Desenvolvimento Ágil de Software, com quatro valores: Indivíduos e interações, mais do que processos e ferramentas; software em funcionamento, mais do que documentação abrangente; colaboração com o cliente, mais do que negociação de contratos; e resposta a mudanças, mais do que seguir um plano.
 
A maioria dos métodos ágeis de desenvolvimento de software tem como foco o software, em vez de formalismos de projeto e documentação, assumem um fluxo de processo iterativo e incremental e apoiam aplicações com requisitos altamente voláteis durante o desenvolvimento.
 
A XP possui um conjunto de valores, princípios e práticas como base aos que assumem a metodologia XP.
 
O processo XP possui quatro atividades metodológicas:
 
O planejamento está fundamentado nas histórias de usuários.
 
O projeto tem um mínimo de formalismo em função de gerar um único tipo de artefato, os cartões CRC, sendo sugeridas a prototipação e refatoração nessa etapa.
 
A codificação sugere o trabalho em par de programadores alocados em um único computador, permitindo uma revisão de código em tempo real.
 
Os testes têm uma característica peculiar, são escritos antes da codificação e aplicados de forma sistemática em ambiente automatizado; na sequência, temos os testes unitários, de integração e aceitação.
Questão 1
(Empresa Brasileira de Correios e Telégrafos (Correios) - FIP - 2009). Assinale a alternativa que não apresenta características dos métodos ágeis de desenvolvimento de software:
A
Entregas parciais do sistema em períodos curtos, que duram de semanas a meses, com preferência para intervalos menores.
B
Atribuição dos requisitos de maior complexidade funcional e não funcional nas primeiras interações com os clientes, de forma a priorizar os aspectos críticos do sistema.
C
Quantidade de código executável considerada a medida mais importante do progresso do desenvolvimento de um software.
D
Mudanças nos requisitos, mesmo quando ocorrem próximas ao final do desenvolvimento.
E
Processos de desenvolvimento e recursos tecnológicos disponíveis considerados mais importantes do que as interações entre os membros das equipes.
Responder
Parabéns! A alternativa A está correta.
Um dos valores dos métodos ágeis inclui “indivíduos e interações, mais do que processos e ferramentas”. Esse valor tem origem de uma rejeição dos proponentes dos modelos ágeis aos processos prescritivos com rigoroso formalismo, incluindo os respectivos métodos e ferramentas CASE sugeridas. Para esses proponentes, a comunicação entre membros da equipe, incluindo clientes, é mais importante.
Questão 2
Um engenheiro de software, no contexto de um projeto alinhado à metodologia ágil XP, está planejando as atividades relacionadas ao primeiro incremento, estabelecendo a seguinte sequência: detalhamento das histórias de usuários em tarefas, elaboração dos cartões CRC, codificação, elaboração dos testes unitários e execução dos testes. Assinale a opção correta relativa à sequência descrita:
A
A elaboração dos testes deve ocorrer antes da codificação.
B
A codificação deve ocorrer antes da elaboração dos cartões CRC.
C
A elaboração dos cartões CRC deve ocorrer antes do detalhamento das histórias de usuários em tarefas.
D
A codificação deve ser realizada antes da elaboração dos cartões CRC.
E
A sequência está correta.
Responder
Parabéns! A alternativa A está correta.
A prática de desenvolvimento orientada a testes determina que os testes unitários sejam escritos antes da codificação, técnica também conhecida como “test first”.
Metodologia ágil SCRUM
O termo Scrum, cujo significado se reporta a um método de reinício de jogada no esporte rugby, foi concebido fora da indústria de software como um estilo de gerenciamento de produtos. A partir de conceitos relacionados com este termo, Jeffrey Sutherland e Ken Schwaber, no início da década de 1990, desenvolveram o denominado Processo de Desenvolvimento SCRUM, publicado em 1995. Desde então, esse processo passou a ser aplicado no desenvolvimento de software em todo o mundo.
A metodologia Scrum sofreu, posteriormente, desenvolvimentos adicionais abrangendo o gerenciamento de projetos, não necessariamente relacionados a projetos de software. Entretanto, o Scrum é empregado de forma sistemática no gerenciamento de projetos de desenvolvimento de software, utilizando-se dos valores e princípios do manifesto ágil junto aos conceitos definidos em seu framework. Tal metodologia tem sua aplicação recomendada principalmente quando, em função da complexidade do projeto, não é possível estabelecer todos os requisitos nas fases iniciais do planejamento.
Importante destacar que alguns autores adotam uma abstração de aplicar ao Scrum uma denominação de processo ágil de desenvolvimento de software.
Transparência
A equipe de desenvolvedores deve dispor de um mesmo entendimento dos aspectos significativos do processo com base num padrão, tal como uma linguagem comum referente ao processo.
Inspeção
A máxima é “inspeção constante de todos os artefatos”, ou seja, a equipe de desenvolvedores deve sistematicamente inspecionar os artefatos Scrum e o progresso desses, de modo a detectar não conformidades; entretanto, a inspeção não deve ser um entrave à própria execução das tarefas.
Adaptação
Inclui a adaptação do produto software, que pode sofrer mudanças em função da volatilidade dos requisitos e/ou mudanças da tecnologia, bem como a adaptação do processo em função de alguma falha; os ajustes devem ser realizados o mais rápido possível de forma a evitar a propagação de desvios.
Papéis no Scrum
Uma equipe Scrum é composta pelo Product Owner (Dono de Produto), Scrum Master e Scrum team.
 
O Dono do Produto, ou Product Owner, faz o papel do cliente, determinando os requisitos e funcionalidades que deverão ser entregues, incluindo as suas mudanças, além de manter e comunicar às partes interessadas uma visão clara do projeto e estar disponível para esclarecer eventuais questionamentos.
O Scrum Master é o responsável por garantir que as regras do método Scrum estejam sendo seguidas, desempenhando, também, funções de um facilitador na resolução de problemas ou nas interferências externas. O Scrum Master é o mantenedor das regras e dos procedimentos do Scrum durante a execução do projeto, auxiliando a todos da equipe a entenderem seus papéis no processo.
A Scrum Team, ou equipe scrum, é multidisciplinar, incluindo os especialistas necessários para desenvolver o produto de forma a não depender de membros externos, tais como programadores, administradores de banco de dados, web designers etc.
Artefatos Scrum
Os Artefatos Scrum são concebidos com a finalidade de garantir que as equipes Scrum sejam bem-sucedidas na geração de um incremento.
 
Vejamos os principais artefatos:
Product Backlog
Lista incluindo todos os requisitos ou funcionalidades levantados para o produto, estando sob responsabilidade do product owner; no início do desenvolvimento, são estabelecidos os requisitos inicialmente conhecidos e mais bem compreendidos, evoluindo à medida que o produto e o ambiente em que ele será utilizado também evoluem, ou seja, o product backlog é dinâmico.
Sprint Backlog
Subconjunto de requisitos do product backlog selecionados para determinada iteração, denominada de Sprint; inclui, também, o plano para entregar um incremento do produto e atingir a meta da Sprint, isto é, estabelece quais funcionalidades estarão na próxima versão e o trabalho necessário para a referida entrega, também denominada de “Done”. A equipe de desenvolvimento é a responsável,quando necessário, pelas modificações no sprint backlog.
Eventos Scrum
Os eventos permitem otimizar a organização das inspeções e iterações, sendo por meio deles que os conceitos descritos são postos em prática de uma forma ágil e produtiva. Os eventos permitem, também, a minimização da necessidade de reuniões não contempladas no Scrum. Os eventos possuem um tempo pré-definido com uma duração máxima estipulada denominada de timebox, o que garante uma quantidade apropriada de tempo no planejamento.
 
Vejamos os eventos Scrum.
Sprint
O Sprint corresponde a uma unidade de iteração em Scrum, tendo uma duração (timebox) em torno de um mês, ao final do qual é gerado um incremento de produto em condições de uso pelos usuários finais. Ele possui duração consistente durante todo o desenvolvimento. Cada Sprint inclui as atividades típicas de um processo de desenvolvimento de software, tais como, levantamento de requisitos, análise, projeto etc.
Reunião de planejamento do Sprint
A Reunião de planejamento do Sprint permite planejar o trabalho a ser realizado em dado Sprint, sendo esse plano resultado de trabalho colaborativo da equipe scrum. A reunião é limitada a 8h para um Sprint de um mês, dividida em duas partes que, respectivamente, buscam respostas às seguintes perguntas: O que será entregue no incremento resultante do Sprint planejado? Como será alcançado o trabalho necessário para entregar o incremento?
Reunião diária do Sprint (Daily Scrum)
A Reunião diária do Sprint (Daily Scrum), como diz o próprio nome, é um evento diário limitado a 15 minutos, no qual a equipe scrum ajusta as atividades e cria um plano para as próximas 24 horas. Isso é feito inspecionando o trabalho desde a última daily scrum e pela previsão do trabalho a ser feito antes da próxima reunião diária.
Revisão do Sprint
A Revisão do Sprint é realizada no final do sprint para inspecionar o incremento e adaptar, se necessário, o product backlog. Essa é uma reunião informal, e a apresentação do incremento destina-se a obter feedback e a fomentar a colaboração na equipe, não devendo ultrapassar quatro horas para sprints de um mês.
Retrospectiva do Sprint
A Retrospectiva do Sprint é uma oportunidade formal para a equipe scrum inspecionar e criar um plano de melhorias a ser seguido durante o próximo Sprint, sendo uma reunião limitada a 3h para sprints de um mês. Os objetivos dessa retrospectiva incluem verificar como correu o último sprint no que diz respeito às pessoas, relações, processos e ferramentas; identificar e ordenar os itens que correram de forma satisfatória e potenciais ajustes; e criar um plano para implementar melhorias no modo como a equipe scrum faz o seu trabalho.
Fluxo de Processo do Scrum
Figura 11 – Fluxo de Processo Scrum
O fluxo de processo Scrum está ilustrado na Figura 11. Os requisitos que definem as funcionalidades a serem entregues são agrupadas pelo product owner no product backlog.
 
Veja mais detalhes sobre este fluxo, a seguir:
Reunião de planejamento de sprint
No início de cada sprint, é realizada a reunião de planejamento de sprint, com a participação do product owner, scrum master e scrum teams, a fim de que sejam priorizados e selecionados os requisitos do product backlog que serão implementados no sprint em planejamento. Esses requisitos são decompostos em tarefas, para cada tarefa é alocado um responsável que realiza a sua estimativa. Ao final da reunião, essas tarefas passam a compor o sprint backlog.
Desenvolvimento do sprint
Na sequência, a scrum team inicia o desenvolvimento do sprint de acordo com o planejado. No início de cada dia do sprint, a daily scrum permite o compartilhamento, entre os membros da equipe, do que foi concluído no dia anterior e quais as prioridades do dia atual. O scrum master conduz essa reunião.
Reunião de revisão de sprint
Ao final do sprint, ocorre a reunião de revisão de sprint que permite a geração de um product backlog revisto, sendo definidas as prováveis exigências para o próximo sprint; os requisitos podem ser ajustados em função de sua volatilidade ou de novas tecnologias. Participam dessa reunião o project owner, o scrum master e a scrum team.
Reunião de retrospectiva do sprint
A última atividade da iteração sprint é a reunião de retrospectiva do sprint com a finalidade de levantar as lições aprendidas nessa iteração, incluindo os pontos positivos e o que precisa ser aprimorado nas próximas reuniões.
Processo Unificado Ágil - AUP
O Processo Unificado Ágil, ou Agile Unified Process (AUP), é uma versão simplificada do Rational Unified Process (RUP). O AUP baseia-se nos seguintes princípios:
· A equipe sabe o que está fazendo. O AUP disponibiliza links de acesso à documentação com muitos detalhes, isso para os que estiverem interessados.
· Simplicidade. Tudo é descrito de forma concisa maximizando a simplicidade.
· Agilidade. O AUP está em conformidade com os valores e princípios da metodologia ágil de desenvolvimento de software.
· Concentre-se em atividades de alto valor. O foco está nas atividades que realmente agregam valor ao cliente.
· Independência de ferramenta. A recomendação é utilizar as ferramentas mais adequadas, que muitas vezes são ferramentas simples.
· Customização. O produto AUP é facilmente customizável às necessidades dos seus usuários.
 
O AUP adota uma natureza serial para o que é amplo, e iterativo para o que é particular. Vejamos a natureza serial do AUP que inclui as mesmas quatro fases adotadas pelo RUP:
ConcepçãoElaboraçãoConstruçãoTransição
Tem como objetivos a identificação do escopo do projeto, de uma arquitetura em potencial para o sistema e a viabilidade do projeto.
Vejamos a natureza iterativa do AUP. As atividades que são realizadas de forma iterativa pelos membros da equipe de desenvolvimento para construir, validar e entregar software operacional são as seguintes:
Modelagem
Inclui o entendimento do negócio em questão e do problema a ser resolvido pelo software, identificando uma solução; representações UML para os modelos são utilizadas, entretanto, devem ser suficientemente boas e adequadas, ou seja, o mínimo de formalismo.
Implementação
Transformação dos modelos em código executável, realizando os respectivos testes básicos, tais como testes unitários.
Testes
Realização de uma avaliação objetiva a fim de garantir a qualidade, incluindo a detecção de defeitos, a validação funcional e a verificação de que os requisitos são cumpridos.
Implantação
Planejar e executar a entrega do software operacional aos usuários finais e na obtenção de feedback dos usuários.
Gerenciamento de configuração
Garantir o acesso aos artefatos do projeto, incluindo o rastreamento das diversas versões, bem como o controle e gerenciamento de suas alterações.
Gestão de projetos
Planejar, monitorar e controlar as atividades do projeto a fim de que ele seja entregue no prazo, dentro do orçamento e atendendo as expectativas dos usuários.
Ambiente
Atua em apoio às demais atividades, garantindo a infraestrutura do processo que inclui padrões, ferramentas e outras tecnologias de suporte disponíveis à equipe.
Resumindo
Neste módulo, destacamos os processos de desenvolvimento ágil Scrum e Processo Unificado Ágil (AUP). O Scrum é uma metodologia que possui uma destacada aplicação em projetos de software. Existe a possibilidade de aplicarmos a metodologia Scrum no gerenciamento de projeto ágil de software ou como processo ágil de desenvolvimento de software. Como todo processo ágil, aplica o fluxo de processo iterativo, sendo cada iteração denominada de sprint e, ao final de cada um destes, é gerada uma entrega, isto é, um software operacional.
 
O método AUP tem suas origens no Processo Unificado (RUP), podendo ser considerado uma versão simplificada em função de sua adesão aos valores e princípios das metodologias ágeis. As fases do projeto permanecem as mesmas do RUP, tais como, concepção, elaboração, construção e transição. As mudanças significativas estão nas atividades iterativas compostas de modelagem, implementação, testes, implantação, gerenciamento de configurações,gestão de projetos e ambiente.
Questão 1
(Tribunal de Justiça do Estado do Rio Grande do Norte (TJ-RN) - COMPERVE - 2020) O Scrum é um framework dentro do qual as pessoas podem tratar e resolver problemas de forma ágil. O coração do Scrum está em suas sprints. Segundo o Scrum Guide, em um projeto que adota Scrum, a autoridade de cancelar uma sprint cabe ao
A
Time scrum.
B
Scrum Master.
C
Product Owner.
D
Team manager.
E
Gerente de projeto.
Responder
Parabéns! A alternativa C está correta.
Somente o product owner tem a autoridade para cancelar um Sprint antes do prazo estabelecido, embora o possa fazer sob influência das partes interessadas.
Questão 2
O Método AUP é considerado uma simplificação do RUP, em função de seu ajuste aos valores do manifesto ágil. Qual atividade iterativa do AUP melhor representa a adesão ao seguinte valor: “Software em funcionamento, mais do que documentação abrangente”?
A
Modelagem.
B
Implementação.
C
Testes
D
Implantação.
E
Análise.
Responder
Parabéns! A alternativa A está correta.
O RUP possui como atividades que exigem modelagem: modelagem de negócio, levantamento de requisitos, análise e projeto. Podemos destacar que essas atividades foram agregadas na atividade modelagem do processo ágil AUP.
Considerações finais
Apresentamos os principais modelos de processo de desenvolvimento de software prescritivos, bem como detalhamos o Processo Unificado (RUP) e os métodos ágeis, com seus valores, princípios e práticas, sendo detalhados o processo Extreme Programming (XP), o processo SCRUM e o Processo Unificado Ágil (APU).
 
Os modelos de processos prescritivos incluem um conjunto de elementos metodológicos de processo. A partir do questionamento do excesso de formalismo desses processos prescritivos, dominantes em meados da década de 90, foi redigido o Manifesto para o Desenvolvimento Ágil de Software, com um conjunto de valores, princípios e práticas que foram assimilados pelos processos ágeis, tais como, XP, SCRUM e AUP.
 
Entre os métodos ágeis, o XP está fundamentado nas histórias de usuários, tendo um único tipo de artefato de modelagem, que são os cartões CRC. O SCRUM tem como evento base o sprint, que corresponde a uma iteração com as tarefas que permitem a criação de incrementos de software operacional. Já o AUP, adota as etapas clássicas do RUP, aplicando uma significativa simplificação nas atividades iterativas, particularmente, na modelagem.
Definição
O planejamento, a garantia e o controle da qualidade como parte do processo de desenvolvimento de software.
PROPÓSITO
Compreender a importância do planejamento, garantia e controle da qualidade, através de técnicas adequadas de medições, seleção de métricas e realização de diferentes tipos de testes.
Preparação
Não existem pré-requisitos operacionais para o tema.
OBJETIVOS
Módulo 1
Descrever a qualidade de processo e de produto de software
Módulo 2
Explicar o processo da garantia de qualidade de software
Módulo 3
Explicar o planejamento da qualidade e o controle da qualidade de software
Módulo 4
Descrever as medições e métricas do software
Introdução
O software tem um destaque cada vez maior na vida moderna. Podemos imaginar a complexidade de um software embarcado em uma aeronave com 500 passageiros ou um software que gerencia o tráfego aéreo de uma grande cidade.
A construção de um software desta magnitude exige o envolvimento de vários especialistas, tais como engenheiros de software, web designers, administradores de banco de dados, arquitetos de software e outros que trabalham arduamente para o sucesso do produto software.
A referida equipe tem uma composição multidisciplinar, refletindo uma característica do software: A complexidade. O trato desta complexidade requer a aplicação da Engenharia de Software, que por sua vez tem como foco a camada qualidade. A referida camada garante que os requisitos que atendem às expectativas do usuário serão cumpridos.
Nesse contexto, o presente tema descreve o planejamento, a garantia e o controle da qualidade de software.
MÓDULO 1
Descrever a qualidade de processo e de produto de software
Engenharia de Software vs. Qualidade
Vamos iniciar nosso estudo sobre qualidade no contexto da área de conhecimento Engenharia de Software, que tem como principal produto o software.
A cada dia, o produto software está mais presente nas nossas vidas, quer por meio das redes sociais, em nossos veículos ou nas nossas residências.
No contexto da qualidade de software, podemos destacar a denominada “Crise do software” sintetizada pela afirmativa a seguir:
A maior causa da crise do software é que as máquinas se tornaram várias ordens de magnitude mais potentes! Em termos diretos, enquanto não havia máquinas, programar não era um problema; quando tivemos computadores fracos, isso se tornou um problema pequeno, e agora que temos computadores gigantescos, programar tornou-se um problema gigantesco.
DIJKSTRA, 1972
Importante destacar que o aprimoramento tecnológico do hardware nos últimos anos permitiu o desenvolvimento de softwares cada vez mais complexos, tendo um forte impacto na indústria de software.
Exemplo
Podemos apresentar a substituição do paradigma estruturado pelo paradigma orientado a objetos, que permite o reuso intensivo de especificação, bem como uma melhor manutenibilidade e, como consequência, o desenvolvimento de softwares mais complexos.
Podemos imaginar as sérias consequências na falha de um software embarcado em uma aeronave com 500 passageiros ou em um sistema de controle de tráfego aéreo de uma grande cidade. Uma falha seria algo bem trágico!
Ambos os exemplos possuem uma característica comum: A complexidade. A melhor tratativa para a complexidade é a aplicação de metodologia que permita a decomposição do problema em problemas menores de forma sistemática, cabendo à engenharia de software essa sistematização.
A engenharia de software é uma tecnologia em camadas . Veja:
Figura 1 – Camadas da Engenharia de Software.
Clique nas barras para ver as informações.
Qualidade
A camada qualidade garante que os requisitos que atendem às expectativas do usuário serão cumpridos.
Processo
A camada de processo determina as etapas de desenvolvimento do software.
Métodos
A camada de métodos define os artefatos gerados em função da técnica de modelagem adotada.
Ferramentas
A camada ferramentas estimula a utilização de ferramentas CASE.
Retornando aos nossos exemplos, qual camada evitaria uma falha?
Vejamos os seguintes argumentos e depois tire a sua conclusão.
Atenção
A camada base é a camada de processo, sendo a camada qualidade dependente da existência dessa, ou seja, a definição de um processo de desenvolvimento de software é condição para a implantação de um sistema de qualidade em um projeto de software.
Os métodos e ferramentas da engenharia de software servem, entre outras coisas, ao propósito de garantir, ou pelo menos facilitar, a obtenção do objetivo de garantir a qualidade no software.
Assista ao vídeo abaixo para saber um pouco mais sobre qualidade de software e as atividades de gerenciamento da qualidade no processo de desenvolvimento de software:
Qualidade de Software
De acordo com Pressman (2016), a qualidade de software é definida como 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.
Roger Pressman
Vamos a uma análise da citada definição:
Clique nas informações a seguir.
Gestão de qualidade
Produto útil
Valor mensurável
O gerenciamento de qualidade de software usualmente é estruturado em três atividades principais:
Figura 2 – Gerenciamento da qualidade.
Garantia de qualidade: Estabelece um conjunto de procedimentos e padrões organizacionais que permitem a geração de software com qualidade.
Planejamento de qualidade: Permite o ajuste dos procedimentos e padrões a um determinado projeto de software.
Controle de qualidade: Inclui a definição e aprovação de processos que assegurem que a equipe de desenvolvimento de software tenha seguido os procedimentose os padrões de qualidade de projeto.
A Figura 3 ilustra o relacionamento entre o processo de gerenciamento da qualidade e o processo de desenvolvimento de software proposta por Sommerville (2019). O primeiro permite uma verificação independente no segundo, verificando as entregas de artefatos do projeto. Uma melhor prática é que a equipe de garantia de qualidade seja independente da equipe de desenvolvimento, pois no caso de surgirem problemas, tal como atraso no projeto, poderia ocorrer um comprometimento da qualidade de modo a cumprir o cronograma.
Figura 3 – Gerenciamento de qualidade versus processo de desenvolvimento.
Fonte: O Autor.
Podemos visualizar a qualidade de software sob duas dimensões:
Clique nas barras para ver as informações.
Processo
Podemos destacar que o processo de desenvolvimento do software exige que diversas decisões sejam tomadas ao longo do mesmo. Portanto, se desejamos produzir software com qualidade, é necessário garantir a qualidade em todas as etapas do processo.
Produto
Destacamos que softwares mal testados provocam prejuízos enormes às empresas, pois um simples erro poderá, por exemplo, gerar requisições de compras desnecessárias, produzir indicadores falsos de produtividade, entre outros; podem, também, afetar o processo de tomada de decisão de gerentes e executivos que apoiam-se nas informações para minimizar riscos, direcionar esforços, promover investimentos, sempre na busca da excelência operacional, pois a qualidade das decisões está intimamente ligada à qualidade das informações disponibilizadas pelos softwares organizacionais.
Qualidade do processo
Processo é uma sequência de etapas que permitem a geração de um produto, no nosso caso, o software.
Atenção
O processo permite uma melhor tratativa em relação à complexidade de obtenção de um determinado produto, pois na maioria das vezes é um trabalho multidisciplinar realizado por analistas, programadores, gerentes de projeto, gerentes de teste e outros.
A Engenharia de Software possui uma diversidade de modelos para processos de desenvolvimento de software que atendem a diferentes problemas, sendo um requisito importante na seleção de um processo a complexidade.
Basicamente, quanto maior a complexidade de um sistema, mais formal deverá ser o processo adotado.
Uma metodologia de processo genérica, segundo Pressman (2016), compreende cinco atividades:
Comunicação
A comunicação permite o entendimento do problema, a definição de objetivos para o projeto, bem como a identificação de requisitos.
Planejamento
Inclui o gerenciamento de projeto.
Modelagem
Abrange a geração de modelos, tal como o modelo de casos de uso.
Construção
Inclui, a partir dos modelos gerados, a codificação e os testes de software de acordo com o planejado.
Entrega
Disponibiliza o produto em produção de acordo com o planejado.
A garantia da qualidade de um software inclui o estabelecimento de uma cultura de não tolerância a erros.
Os processos devem estar estruturados com mecanismos de detecção de defeitos nos diversos artefatos gerados durante o processo, com o objetivo de evitar a propagação de defeitos nas fases seguintes, refletindo na inserção de defeitos durante a codificação. Os artefatos incluem qualquer entrega gerada durante o processo de software, incluindo, entre outros, os documentos de requisitos, os modelos, bem como o produto software.
Comentário
Usualmente, os testes estão relacionados ao produto software, mas podemos aplicar testes em todas as tarefas do processo de desenvolvimento de software, sendo esses denominados de testes de verificação, conhecidos também como testes estáticos. Os objetivos desses testes são os artefatos gerados durante todo o processo de desenvolvimento do software, tal como o diagrama de classes ou o diagrama de casos de uso.
Atenção
A produção de software com qualidade exige o estabelecimento de um processo de desenvolvimento de software, pois não poderemos garantir a qualidade de algo que não existe.
Qualidade do produto
Pressman (2016) descreve os fatores de qualidade do produto software de McCall, sendo uma proposta de categorização dos fatores que afetam a qualidade de software. Esses fatores de qualidade de software, apresentados na Figura 4, focam em três etapas de um produto de software: revisão do produto, transição e operação.
Figura 4 – Fatores de qualidade de software de McCall.
Fonte: O Autor.
Vejamos uma descrição dos referidos fatores, cabendo destacar que a avaliação da qualidade de uma aplicação usando esses fatores possibilitará uma sólida indicação da qualidade de um software:
Correção - O quanto um programa satisfaz a sua especificação e atende às necessidades do cliente.
Confiabilidade - O quanto se pode esperar que um programa realize a função pretendida com a precisão exigida.
Eficiência - A quantidade de recursos computacionais e código exigidos por um programa para desempenhar sua função.
Integridade - O quanto o acesso ao software ou dados por pessoas não autorizadas pode ser controlado.
Usabilidade - Esforço necessário para aprender, operar, preparar a entrada de dados e interpretar a saída de um programa.
Facilidade de manutenção - Esforço necessário para localizar e corrigir um erro em um programa.
Flexibilidade - Esforço necessário para modificar um programa em operação.
Testabilidade - Esforço necessário para testar um programa de modo a garantir que ele desempenhe a função destinada.
Portabilidade - Esforço necessário para transferir o programa de um ambiente de hardware e/ou software para outro.
Reusabilidade - O quanto um programa, ou partes do mesmo, pode ser reutilizado em outras aplicações.
Interoperabilidade - Esforço necessário para integrar um sistema a outro.
A qualidade do produto pode ser garantida por meio de um sistemático plano de testes executado durante a etapa de codificação do processo de software, sendo esses testes denominados de testes de validação.
Inicialmente, ocorre a validação da estrutura interna da unidade de software, bem como sua aderência aos requisitos estabelecidos.
Em seguida, a validação da sua integração com as unidades de software desenvolvidas anteriormente, com destaque para as validações das interfaces dos componentes de software.
Finalmente, ocorre a validação funcional e não funcional do software como um todo, sendo os usuários envolvidos nessa etapa.
Os procedimentos de testes aplicados diretamente em softwares são também denominados de testes de software ou testes dinâmicos.
Os testes de software podem sofrer um alto nível de automação, o que possibilita a criação de complexos ambientes de testes que simulam diversos cenários de utilização. Quanto mais cenários simulados, maior o nível de validação que obtemos do produto, caracterizando maior nível de qualidade do software desenvolvido.
Custos da qualidade
Figura 5 – O custo da qualidade.
O custo da qualidade é composto pelo custo da conformidade e custo da não conformidade.
Clique nas barras para ver as informações.
Custo da conformidade
Agrega o custo da prevenção de defeitos e o custo da detecção de defeitos ou falhas. O custo de prevenção inclui os esforços do sistema de qualidade em evitar a ocorrência de defeitos, tais como detalhamento de metodologias, treinamentos, utilização de ferramentas, estabelecimento de procedimentos, entre outros. O custo de detecção de defeitos, também denominado de custo de avaliação, é composto pelos custos relacionados à atividade de avaliação, detecção ou inspeção da qualidade do processo ou do produto, tais como revisões de artefatos (requisitos, modelos, planos de testes etc), inspeções de código, testes de software, auditorias, entre outros.
Custo da não conformidade
O custo proveniente da falta de qualidade, que desapareceria caso não surgisse nenhum erro antes ou depois da entrega do produto ao cliente, soma-se aos custos relacionados às correções de defeitos originados no processo de desenvolvimento de software, tais como retrabalhos, ações corretivas, atrasos nos cronogramas, perdas financeiras e operacionais, entre outros.as métricas de tamanho como LOC (linhas de código) e PF (pontos de função) e verificamos como derivar indicadores a partir delas com o objetivo de planejar e controlar melhor os nossos projetos.
Vimos que as métricas de processo permitem que a organização tenha uma visão estratégica, fornecendo informações sobre a eficiência de um processo de software, em conformidade com seus objetivos e suas metas.
Por fim, compreendemos como funciona o processo de medição de software para o acompanhamento das métricas durante o ciclo de vida de desenvolvimento do software.
image5.jpeg
image6.jpeg
image7.jpeg
image8.jpeg
image9.jpeg
image10.jpeg
image11.jpeg
image12.jpeg
image13.jpeg
image14.jpeg
image15.jpeg
image16.jpeg
image17.jpeg
image18.jpeg
image19.jpeg
image20.jpeg
image21.jpeg
image22.jpeg
image23.jpeg
image24.jpeg
image25.jpeg
image26.jpeg
image27.jpeg
image28.jpeg
image29.jpeg
image30.jpeg
image31.jpeg
image32.jpeg
image33.jpeg
image34.jpeg
image35.jpeg
image36.jpeg
image1.jpeg
image37.jpeg
image38.jpeg
image39.jpeg
image40.jpeg
image2.jpeg
image41.jpeg
image42.jpeg
image43.jpeg
image44.png
image45.png
image46.jpeg
image3.jpeg
image47.jpeg
image4.jpeg