Gerência de software através de métrica

Sumário Capítulo 1 - Compreendendo a Dimensão do Software e de Sua Gestão 1.1 - A Dimensão do Software 1.2 - A Dimensão da Gestão do Software 1.3 - A Importância da Medição do Software Capítulo 2 - Conceitos Fundamentais da Qualidade 2.1 - Origens e Evolução Histórica da Qualidade 2.2 - Conceitos da Qualidade 2.3 - As Escolas da Qualidade 2.4 - Custos da Qualidade 2.5 - Sistemas da Qualidade Baseados na ISO 9000 2.6 - Os Prêmios Nacionais da Qualidade Capítulo 3 - Implicações dos Conceitos da Qualidade Para o Software 3.1 - O Paradigma da Qualidade do Software 3.2 - Interpretação dos Demais Conceitos da Qualidade Capítulo 4 - Classificação e Mecanismo das Medições em Software 4.1 - Classificação das Medições 4.2 - Mecanismo da Medição em Software Capítulo 5 - O Processo de Desenvolvimento de Software - Base Para Aplicação das Medições 5.1 - Conceitos Básicos do Processo de Software 5.2 - Níveis de Medição Conforme os Modelos de Processo Capítulo 6 - Aplicação das Medições no Planejamento de Projetos 6.1 - O Processo de Planejamento de Projetos 6.2 - Tipos e Técnicas de Estimativas 6.3 - Estimativas Utilizando a Análise Por Pontos de Função-FPA 6.4 - Estimativas Utilizando o COCOMO ( Constructive Cost Model) 6.5 - Estimativas Utilizando Regressão Linear Capítulo 7 - Aplicação das Medições no Processo de Desenvolvimento do Software 7.1 - O Processo de Gestão de Projetos 7.2 - O Processo de Inspeção Formal de Software 7.3 - Medições no Processo de Desenvolvimento de Software Capítulo 8 - Aplicação das Medições na Gestão do Produto 8.1 - O Processo de Gestão do Produto

8.2 - Medições Para a Gestão do Produto 8.3 - Medições Para o Aperfeiçoamento dos Processos de Planejamento de Projetos,de Desenvolvimento do Software e Gestão do Produto Capítulo 9 - Gestão do Ambiente de Software 9.1 - Medições Para o Monitoramento do Ambiente 9.2 - Medições Para a Gestão dos Recursos 9.3 - Análise de Tendências 9.4 - Análise de Impacto 9.5 - Análise de Atributos 9.6 - Modelagem do Ambiente de Desenvolvimento Capítulo 10 - Aplicação das Medições em Decisões Econômicas Relativas a Software 10.1- Decisão de Comprar/Desenvolver Internamente 10.2- Planejamento de Custos de Manutenção Anual de Software 10.3- Análise de Viabilidade da Utilização de Inspeções do Projeto 10.4- Análise de Viabilidade da Utilização de Análise Essencial 10.5- Análise de Viabilidade da Utilização de Projeto Estruturado 10.6- Análise de Viabilidade da Utilização da Análise de Complexidade 10.7- Análise de Viabilidade da Utilização da Inspeção de Código Capítulo 11 - Aplicação Estratégica das Medições 11.1- O Processo de Benchmarking 11.2- O Modelo SEI de Certificação da Qualidade em Software 11.3- O Modelo ISO de Certificação da Qualidade em Software 11.4- Melhoria Contínua da Qualidade do Software 11.5 - Avaliação do Acervo de Software Capítulo 12 - Vendendo e Implantando Um Programa de Qualidade de Software 12.1- Planejando a Venda do Programa de Qualidade de Software 12.2- Vendendo o Programa 12.3- Planejamento da Implantação 12.4- Gerenciando a Implantação do Programa 12.5- Manutenção e Melhoria do Programa da Qualidade de Software Capítulo 13 - Ética na Utilização dos Resultados das Medições 13.1- Níveis de Privacidade dos Resultados das Medições 13.2- Regras de Conduta Para a Utilização das Medições Capítulo 14 - As Novas Responsabilidades dos Gestores de Software 14.1- As Responsabilidades dos Gerentes de Projetos de Software 14.2- As Responsabilidades dos Gerentes de Desenvolvimento 14.3- As Responsabilidades dos Gerentes de Informática

Capítulo 15 - Auto-Avaliação do Estágio de Maturidade de Software 15.1- Auto-Avaliação Conforme o Modelo SEI 15.2- Auto-Avaliação Conforme o Modelo ISO 9000-3 15.3- Verificação das Condições Para a Mudança Capítulo 16 - Coletânea de Estatísticas Relativas ao Software

 1995 by EDITORA ATLAS S.A. Rua Conselheiro Nébias, 1384 ( Campos Elísios) 01203-904 São Paulo (SP) Tel.: (011) 221-9144 (PABX) ISBN 99-999-9999-9 Impresso no Brasil/Printed in Brazil Depósito legal na Biblioteca Nacional conforme Decreto no. 1.825, de 20 de dezembro de 1907.

TODOS OS DIRETOS RESERVADOS - É proibida a reprodução total ou parcial,de qualquer forma ou por qualquer meio. O Código Penal brasileiro determina, no artigo 184: DOS CRIMES CONTRA A PROPRIEDADE INTELECTUAL Violação de direito autoral ------------------------------------------------

Dados internacionais de Catalogação na Publicação (CI) ( Câmara Brasileira do Livreo,SP,Brasil)

Fernandes, Aguinaldo Aragon, 1954 Gerência Efetiva de Software Através de Métricas/ Aguinaldo Aragon Fernandes. São Paulo : Atlas, 1995.

Bibliografia.

ISBN 99-999-9999-9 1.Gerência 2. Software 3. Métricas I.Título 99-9999

CDD-999.9999

índices para catálogo sistemático:

Este livro dedico a um grupo especial de - amigos para sempre, são eles: Edison Hernandez Francisco Carlos da Rosa Ramos José Luiz Carlos Kugler Luiz Carlos Slavutzki Marco Antônio de Moraes Marco Aurélio Subtil Paulo José Mattos

PREFÁCIO Nos últimos dez anos, desde que me envolvi com as questões de gerenciamento de projetos de software e após a realização de mais de 60 seminários sobre o tema, constatei que a tão falada crise do software é eminentemente gerencial, com raízes culturais, característicamente brasileira, onde o pragmatismo e o comportamento imediatista não tem atingido os objetivos pretendidos . Continuamos sempre a reinventar “a roda” e a um custo que os clientes/usuários não estão mais dispostos a pagar.

Atualmente, com a dependência cada vez maior das organizações em relação à tecnologia da informação, a geração de produtos de software com qualidade e a um custo compensador, torna-se fator crítico de sucesso.

Produtos de software de qualidade são aqueles que efetivamente agregam valor para a empresa e para os clientes servidos por esta. Isto significa para a empresa, flexibilidade, redução de custos de seus processos empresariais, manutenção dos clientes atuais, criação de novos nichos de mercado, aumento na participação do mercado e lucratividade.

Este livro pretende estimular os gerentes e engenheiros de software a praticar a gerência de projetos e produtos com base em fatos e dados, visando atingir níveis de qualidade adequados às exigências dos atuais clientes/usuários a um custo também adequado, apoiando de forma efetiva os esforços da empresa para o aperfeiçoamento contínuo de suas operações.

Apesar de se constituir em uma modesta contribuição, já que o tema tratado é vastíssimo e intrigante, procuramos, a partir de um modelo genérico de gestão do software, mostrar como as métricas (ou medições) podem ser empregadas, explicitando os principais momentos das medições e seus objetivos.

Avançamos agora, desde nosso útlimo trabalho sobre Gerência de Projetos• , para retratar todas as nuances relativas ao gerenciamento do software conforme suas dimensões, ou seja, planejamento de projetos, processo de desenvolvimento, planejamento anual de atendimento ao produto, planejamento do atendimento específico ao produto (manutenções corretivas, adaptativas e projetos de melhoria), o monitoramento do próprio atendimento ao produto e a gestão da qualidade,produtividade e custo do produto enquanto em operação/utilização.

Adicionalmente introduzimos o conceito de que o ambiente de desenvolvimento de software (considerando o conjunto de projetos, serviços de atendimento e produtos da instalação), deve ser gerenciado por exceção, através de métricas que dão a indicação do que , a princípio, está “fora dos limites de controle”.

•

Fernandes ,Aguinaldo Aragon & Kugler, José Luiz Carlos . Gerência de Projetos de Sistemas: uma abordagem prática. Livros Técnicos e Científicos S.A. , Rio de Janeiro, 2a. edição,1990.

A estrutura lógica do livro foi construída com base na nossa experiência e observações das práticas de outras organizações (médias e grandes) no tocante ao desenvolvimento e gestão de produtos de software•.

A partir disso, estruturamos o livro partindo dos fundamentos básicos do que significa Qualidade e o que signfica medir processos para após, mostrarmos as possibilidades de aplicação para o gerenciamento operacional, tático e estratégico do software.

Apesar de também possuirmos acentuada bagagem acadêmica, utilizamos uma linguagem simples e objetiva, com amplo apoio bibliográfico, para que o leitor possa aprofundar-se posteriormente quanto aos temas tratados.

Estruturamos o livro em 16 capítulos os quais podem ser vistos conforme uma divisão de 4 partes fundamentais.

A primeira parte, que vai do capítulo 1 ao 5 é eminentemente conceitual. Apresenta as dimensões do software e a importância da sua medição, os conceitos básicos universais sobre a qualidade, o que significam estes conceitos para a realidade da gestão e desenvolvimento/manutenção do software, quais os níveis de medição necessários, quais as medições mais apropriadas, finalizando com o conceito de modelos de processo de software.

A segunda parte, que vai do capítulo 6 ao 11, apresenta a aplicação das medições ao software, considerando o planejamento de projetos, o desenvolvimento propriamente, o planejamento do atendimento ao produto, o monitoramento do atendimento ao produto, a gestão do produto, a gestão do ambiente de software no sentido mais amplo, a aplicação estratégica das medições e o apoio a processos de tomada de decisão econômicos relativos ao software.

A terceira parte, que compreende os capítulos 12 a 14, apresenta alguns pré-requisitos importantes para que as medições sejam aplicadas numa organização, ou seja, discutimos a forma como um programa de métricas e qualidade de software pode ser vendido e estruturado, discutimos sobre as questões éticas e comportamentais acerca do uso dos resultados das medições e, dentro de um contexto de qualidade, quais as responsabilidades esperadas dos gerentes de projetos e de desenvolvimento e do gerente de informática.

A quarta e última parte apresenta alguns auxílios para que o leitor avalie o estágio de maturidade que a sua organização de software se encontra, a fim de permitir o planejamento consistente de melhorias, bem como apresenta um elenco de “fatos e dados” ( estatísticas) extraídos da experiência de empresas de classe mundial, bem como de extensivas pesquisas realizadas em países que se encontram mais maduros tecnológicamente.

•

Produtos de software é um termo genérico que usamos ao longo deste livro. Para nós a finalidade do processo de desenvolvimento é a geração de um produto, independente se é para consumo interno, se é para terceiros sob contrato ou se é para comercialização em grande escala.

Esperamos que esta nossa pequena contribuição auxilie efetivamente o leitor a encontrar caminhos próprios para atingir níveis de excelência na produção e manutenção de produtos de software.

Por fim, estamos totalmente abertos para o recebimento de críticas e sugestões e para a troca de idéias e experiências. Para aqueles leitores que desejarem fazer contato eis a forma: Alameda Franca 386 apto 111, CEP: 01422-010 -São Paulo - SP, Telefax (011) 889-0387.

São Paulo,14/12/94 Aguinaldo Aragon Fernandes

Agradecimentos Este livro não seria possível sem a colaboração das seguintes pessoas e organização: Professor Antônio Loureiro Gil, cuja comunhão de idéias e abordagens validaram muitos dos conceitos introduzidos no texto; David Card, Diretor de Métricas e Processos da CSC, cujos ensinamentos constituiram-se no grande incentivo para o meu auto-aperfeiçoamento; Jaime Roberto Perez Herrera, Gerente Técnico de Projetos da UNPROJETOS SP da CTIS -Informática e Sistemas Ltda, cuja apurada capacidade de análise crítica e lógica foi decisiva para a organização final do texto; Murilo Maia Alves, Gerente de Garantia da Qualidade da CTIS - Informática e Sistemas Ltda, cujo conhecimento linguístico, que não é o meu forte, foi também decisivo para a arrumação semântica e gramatical do texto; Tereza Cristina Maia Fernandes, minha esposa, amiga , companheira e colaboradora, cujo profundo conhecimento matemático, avalizou muitos dos algoritmos colocados neste texto; CTIS-Informática e Sistemas Ltda pelo apoio material dado para a elaboração desta obra.

Capítulo

1 COMPREENDENDO A DIMENSÃO DO SOFTWARE E DE SUA GESTÃO Apesar da disciplina de software já contar com pelo menos cinquenta anos de progresso , a abordagem para o seu desenvolvimento ainda tem se fundamentado em métodos e práticas “artesanais” . Ao contrário dos que pregam que o desenvolvimento de software deve ser encarado como um esforço de engenharia, infelizmente não há correspondência com a realidade, talvez com raríssimas exceções e principalmente em organizações cuja finalidade ou negócio é o software.

No Brasil em especial, mesmo com o acesso ao que há de mais atual em termos de ferramentas de desenvolvimento , vivemos eternamente a “crise do software”, isto é: baixa qualidade, prazos e orçamentos ultrapassados e métodos gerenciais igualmente empíricos.

A nosso ver a “crise do software” é uma crise eminentemente gerencial, que muitas vezes transcende as responsabilidades dos gerentes de software, pois sem o patrocínio à mudanças, vindo da alta administração da empresa, dificilmente uma inovação ou implantação de métodos de gestão eficazes, é bem sucedida.

Entretanto com a importância econômica cada vez maior atribuída ao software pelas organizações, visto ser um dos principais insumos para a competitividade empresarial e até mesmo de nações, as condições para tratar seu desenvolvimento com um enfoque de engenharia, começam a ser estabelecidas. Outro aspecto a contribuir para isto é a rápida disseminação dos conceitos de qualidade, qualidade total e sistemas da qualidade que se observa pelo mundo , cuja filosofia preconiza o controle dos custos de não conformidade do processo e do produto.

De acordo com Arthur 1, na área de software, os custos da má qualidade podem atingir 50% dos custos totais do desenvolvimento.

Mesmo sem empregar abordagens mais científicas para o desenvolvimento de software temos tido sucesso? É óbvio que sim , mesmo com as imperfeições introduzidas e entregues aos usuários temos tido sucesso, porém com um processo cuja tônica é “apagar incêndios” , a um altíssimo custo ( infelizmente não mensurado), considerando todo o ciclo de vida do software , e a um “timing” inaceitável dada a dinâmica dos negócios e do mercado.

Toda e qualquer disciplina de engenharia é fundamentada em medições. É impossível imaginar como a Engenharia Civil, Elétrica, a Física, a Química teriam progredido sem medições. Elas são a base de qualquer ciência.

Há uma famosa frase de Tom de Marco 2 que diz: “You cannot control what you cannot measure” , ou seja, não gerenciamos nada sem as medições necessárias, até mesmo projetos de software.

Para começarmos a tratar o software sob uma abordagem de engenharia, é necessário entendermos as características de sua dimensão e a importância da medição para a sua gestão.

1.1 - A Dimensão do Software Todo e qualquer software é desenvolvido, independente de plataforma e tecnologia, segundo uma sequência básica de grandes atividades, denominada de Ciclo de Vida.

PROJETO Análise do Negócio

Definição dos Requisi-

Projeto Lógico do Sistema

PRODUTO

Projeto Físico do Sistema

Construção do Sistema

Teste e Implantação do Sistema

Manutenção /Melhoria/ Descarte

PROCESSO Figura 1-1

O desenvolvimento do software ocorre no contexto de um projeto , o qual é executado de acordo com um processo, gerando produtos intermediários e um produto final ( release do software ) , o qual deve ser mantido a fim de corrigir defeitos introduzidos durante o projeto, deve ser melhorado com a incorporação de novas “features” e por fim , deve ser desativado, substituído ou descartado, ao final de sua vida útil.

➲

Projetos de Software

Um projeto de software é um esforço no sentido de construir um produto , dentro de determinadas especificações, que atenda necessidades dos usuários (clientes) para que executem processos operacionais e gerenciais de negócios.

Na verdade, um projeto de software é a junção de Objetivos + Atividades + Prazos + Recursos Envolvidos + Riscos e Incertezas. É uma forma de organização do trabalho que apresenta as seguintes características: ➩

É um esforço finito, com início e fim e a cujo término pretende-se a entrega, geração ou finalização de um determinado produto, definido a priori;

➩

É um esforço que pode ser subdividido em unidades de trabalho ( fases,etapas, atividades ) que ocorrem em uma sequência prédeterminada;

➩

O objetivo, a alocação de recursos e o progresso realizado podem ser monitorados e avaliados.

Podemos considerar como projetos de software: ➨ ➨ ➨

Desenvolvimento de Software sob medida ou encomenda Desenvolvimento de Software - Produto Desenvolvimento de novas releases do software

Não consideramos serviços de manutenção esporádicos como remover defeitos , realizar pequenas adaptações e adicionar pequenas funcionalidades, projetos de software, apesar de que os mesmos também devem ser gerenciados.

➲

Processo de Software

O processo de software é um conjunto de atividades , (numa sequência prédeterminada ), métodos e práticas que são utilizados na produção e evolução do software.

O processo compreende: ➩ ➩ ➩ ➩

Políticas de desenvolvimento Procedimentos para o desenvolvimento Diversas técnicas e padrões para a construção de produtos Padrões de apresentação de produtos intermediários

O processo define a forma como o projeto é executado e, consequentemente, gerenciado.

O conjunto de atividades , numa sequência pré-determinada, compõem o que se denomina a arquitetura do processo de software.

A arquitetura do processo , no jargão mais comumente utilizado na área de informática, é o que chamamos de metodologia de desenvolvimento.

O processo de software existe em qualquer organização, independente de seu nível de organização e padronização. Pode ser um processo sem formalização ou altamente padronizado.

➲

Produto de Software

O processo de software tem como resultado um produto (release) que contém uma série de atributos derivados dos requisitos e especificações a fim de atender necessidades implícitas e explícitas dos usuários (clientes). Estes atributos definem as

características do produto em termos de desempenho, confiabilidade, eficiência, usabilidade, nível de manutenibilidade, nível de portabilidade e nível de reutilização.

O software enquanto produto sofre alterações, caracterizadas como: ➪

Manutenção corretiva, que compreende: ➽ ➽ ➽

➪

Manutenção adaptativa, que compreende: ➽

➪

remoção de defeitos introduzidos pelo projeto remoção de defeitos introduzidos por manutenções adaptativas remoção de defeitos introduzidos por melhorias

a alteração de determinadas funções do software visando adequá-lo a requisitos regulatórios ou de legislação

Melhorias no software, que compreendem: ➽ ➽

introdução de novas “features” no software em função de novos requisitos dos negócios introdução de novas “features” no software em função de mudança de tecnologia

Uma nova release do software é o somatório de manutenções adaptativas e de melhorias.

O desenvolvimento de uma nova release pode ser realizado sob a filosofia de projeto, ao passo que manutenções corretivas geralmente não.

1.2 - A Dimensão da Gestão do Software A gestão do software consiste nas ações necessárias para a gestão do projeto, do ambiente de desenvolvimento, e do produto (release) visando atingir objetivos previamente estabelecidos no que concerne a produtividade e qualidade e quanto ao atendimento das necessidades dos usuários ( clientes ).

➲

Gestão do Projeto

As ações necessárias para a gestão do projeto podem ser categorizadas em: ➩

Planejamento do Projeto, que compreende: ➨ ➨ ➨ ➨

Elaborar o escopo preliminar do produto a ser desenvolvido Elaborar estimativas de prazos, recursos, esforço, custos e tamanho do produto Definir o processo de desenvolvimento a ser adotado pelo projeto Definir a estrutura de organização do projeto

➨ ➩

Controle do Projeto, que compreende: ➨ ➨ ➨ ➨ ➨ ➨ ➨

➩

Controle da alocação dos recursos Verificação e validação dos produtos intermediários Controle de mudanças no escopo do projeto Refinamento do planejamento inicial do projeto Replanejamento do projeto Acompanhamento da realização das tarefas conforme planejado Acompanhamento da realização orçamentária do projeto

Monitoramento do Projeto, que compreende: ➨ ➨ ➨ ➨

➲

Definir os “pontos de controle “ do projeto

Verificar o progresso do projeto Verificar e avaliar a qualidade dos produtos intermediários Verificar e avaliar a produtividade da equipe Avaliar o projeto em termos financeiros

Gestão do Ambiente de Desenvolvimento de Software

A gestão do ambiente de software consiste em ações relativas a:

➩

Introduzir novos recursos para a gestão e desenvolvimento de software Avaliar comparativamente a produtividade dos projetos Avaliar a produtividade do desenvolvimento conforme distintas plataformas de hardware e software Avaliar comparativamente, a qualidade dos projetos e produtos Avaliar as tendências da produtividade e qualidade Aperfeiçoar o processo de desenvolvimento de software Avaliar o impacto de novos métodos e técnicas sobre a produtividade e qualidade do software Avaliar os aspectos financeiros do software

➲

Gestão do Produto

➩ ➩ ➩ ➩ ➩ ➩ ➩

A gestão do produto , por sua vez, refere-se a ações relativas a: ➩ ➩ ➩ ➩ ➩

Elaborar o planejamento anual das manutenções/melhorias Avaliar a produtividade das manutenções e melhorias Avaliar a qualidade do produto ao longo de sua vida útil Avaliar o nível de atendimento às solicitações de manutenção Avaliar os aspectos financeiros do produto

1.3 - A Importância da Medição do Software

O objetivo da aplicação da medição de software é fornecer aos gerentes e engenheiros de software um conjunto de informações tangíveis para planejar o projeto, realizar estimativas, gerenciar e controlar os projetos com maior precisão.

A realidade aponta para a necessidade de medições, visto que: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

As estimativas de prazos, recursos, esforço e custo são realizadas com base no julgamento pessoal do gerente de projeto A estimativa do tamanho do software não é realizada A produtividade da equipe de desenvolvimento não é mensurada A qualidade dos produtos intermediários do processo não é medida A qualidade do produto final (release) não é medida O aperfeiçoamento da qualidade do produto ao longo de sua vida útil não é medido Os fatores que impactam a produtividade e qualidade não são determinados A qualidade do planejamento dos projetos não é medida Os custos de não conformidade ou da má qualidade não são medidos A capacidade de detecção de defeitos introduzidos durante o processo não é medida Não há ações sistematizadas no sentido de aperfeiçoar continuamente o processo de desenvolvimento e de gestão do software Não há avaliação sistemática da satisfação dos usuários (clientes)

Na verdade, a maioria dos projetos e produtos de software são desenvolvidos e evoluídos em bases “artesanais” , cuja única preocupação é atingir o objetivo de prazo, negligenciando os atributos de qualidade e financeiro , ou de controle de custos.

Dessa forma, o que temos entregado aos nossos usuários e clientes é um conjunto de código, que executa determinadas funções e defeitos, e o que é pior, não aproveitamos as experiências passadas para aperfeiçoar o processo de desenvolvimento.

A adoção dos conceitos de engenharia para o desenvolvimento do software requer: ➩

Um processo de software definido em termos de desenvolvimento, procedimentos, padrões, métodos, ferramentas

políticas de técnicas e

➩

Medições relativas à atributos do projeto, tais como prazos, recursos, custos e esforço

➩

Medições relativas à atributos do processo, tais como cobertura de testes, nível de detecção e remoção de defeitos, nível de complexidade do projeto, produtividade

➩

Medições relativas à atributos do produto, tais como confiabilidade, nível de detecção de defeitos , índice de manutenção, tamanho do software

➩

Medições relativas à satisfação dos clientes

➩

Sistema de garantia da qualidade, incluindo gerência de configuração, planos da qualidade, inspeção formal de software, técnicas de testes de sistemas e assim sucessivamente

Com a adoção destes conceitos é possível medir a qualidade e produtividade dos projetos/processo e do produto, compará-los com metas pré-estabelecidas, verificar tendências e fundamentar o aperfeiçoamento contínuo do processo.

REFERÊNCIAS 1. ARTHUR,Jay Lowell. Improving Software Quality: an insider’s guide to TQM. Wiley & Sons, New York,1993.

2. DeMARCO, Tom. Controlling Software Projects: management, measurement & estimation.Yourdon Press, New York,1982.

Capítulo

2 CONCEITOS FUNDAMENTAIS DA QUALIDADE O objetivo primário de realizarmos medições no tocante ao desenvolvimento de software é o de obter níveis cada vez maiores de qualidade, considerando o projeto, o processo e o produto, visando a satisfação plena dos clientes ou usuários, a um custo economicamente compatível.

Nossa missão com este livro não estaria completa caso nos eximíssimos de apresentar os conceitos fundamentais da qualidade. Conceitos sobre os quais repousa todas as iniciativas para a qualidade do software e que permite um melhor entendimento dos assuntos tratados nos capítulos posteriores.

Apesar da qualidade ser um tema vastíssimo e excitante, procuramos apresentálo de forma sucinta , porém abrangente, discutindo as suas principais nuances e implicações para a área de software.

Antes de apresentarmos os conceitos da qualidade se faz necessário uma breve exposição sobre as origens e evolução histórica da qualidade 2.1 - Origens e Evolução Histórica da Qualidade A aplicação da qualidade data de alguns séculos atrás, quando a pessoa que produzia , inspecionava e vendia um bem, significava uma só. Geralmente era um artesão que , tendo contato direto com o cliente, especificava facilmente seus requisitos e media informalmente a satisfação dos mesmos.

Com o desenvolvimento do comércio, começaram a surgir os “intermediários”.

Nesta época o produtor já não podia determinar com clareza as expectativas e percepções dos consumidores. Ainda assim era o próprio artesão que realizava a inspeção da qualidade de seu trabalho.

Esta situação perdurou até o final do século 19, quando em função da revolução industrial, a produção em série e de massa começou a ser implementada. Neste momento surgiu o supervisor de equipes de produção, o qual coordenava pessoas que desenvolviam tarefas similares. O supervisor passou a ser então o principal elemento do controle da qualidade, inspecionando o trabalho dos operários.

Com o esforço de produção exigido pela primeira Guerra Mundial foram criadas as primeiras funções segregadas com a tarefa específica de realizar inspeção. A qualidade passava a ser responsabilidade dessas funções.

A segunda Guerra Mundial , com a produção em larga escala de material bélico, colocou na mão dos inspetores as primeiras ferramentas estatísticas de controle da

qualidade. Começou-se a realizar inspeções com base em técnicas de amostragem (era impraticável a inspeção 100% dos produtos) assim como o controle da conformidade dos produtos através de gráficos de controle.

Nesta ocasião as técnicas estatísticas da qualidade tiveram um grande desenvolvimento sendo responsável em parte, pelo esforço de guerra bem sucedido dos norte-americanos.

Porém a aplicação das técnicas de controle estatístico da qualidade encontrou no Japão do pós-guerra, um campo bastante fértil. As forças de ocupação americanas, visando auxiliar na reconstrução do país , designaram o Dr. Deming para transmitir o conhecimento dessas técnicas aos engenheiros japoneses. Deming é considerado como o pai do milagre japonês.

Foi no Japão, durante a década de 50, que o controle estatístico da qualidade experimentou seu maior desenvolvimento.

Na década de 60, com o início da globalização da economia, e o consequente aumento do nível de exigência por produtos com maior qualidade, introduziu-se a idéia de que a obtenção da qualidade nos produtos passava também pela qualidade do projeto.

Nascia então o Controle da Qualidade Total (CQT). Esta idéia também foi desenvolvida pelos japoneses.

A implementação do CQT e seu desenvolvimento pelos japoneses transformou, a partir da década de 70 , as bases da competição mundial.

Na década de 80, as idéias, métodos e práticas do CQT evoluiram para o que se denomina de Controle da Qualidade Por Toda a Empresa (Companywide Quality Control), abrangendo todas as funções da empresa, fornecedores e distribuidores a fim de garantir a qualidade de produtos e serviços conforme requisitos explícitos e implícitos dos consumidores bem como a Gestão da Qualidade Total (Total Quality Management -TQM).

Somente no início da década de 80 é que as principais economias ocidentais descobriram o motivo do sucesso japonês. • Culminando , ao final da década de 80, mais precisamente em 1987, foram criadas as primeiras normas internacionais sobre Sistema da Qualidade, as normas ISO 9000.

A Figura 2-1 mostra graficamente, a evolução da qualidade.

•

Deming foi descoberto pelos americanos em 24 de junho de 1980 através do programa de televisão exibido pela NBC entitulado “If Japan Can, Why Can’t We?” produzido por Clare Crawford-Mason.

Evolução da Qualidade

TQCCW TQM

TQC

Controle Estatístico 1980

Inspeção 1960 Supervisor 1937 Operador 1918

1900

Figura 2-1 Evolução Histórica da Qualidade

2.2 - Conceitos da Qualidade Apesar da qualidade como disciplina já ser relativamente madura, não existe um consenso sobre sua definição.

Para tanto apresentaremos o conceito sob a ótica de várias fontes, para que o leitor possa comparar e criar o seu próprio ou adotar um conceito.

Adicionalmente iremos avançar para tratar dos conceitos relativos à Controle da Qualidade,Garantia da Qualidade,Controle da Qualidade Total e Sistema da Qualidade. ⌦

Qualidade

“ Qualidade é a composição total das características de marketing, engenharia,fabricação e manutenção de um produto ou serviço, através das quais o

mesmo produto ou serviço, em uso, atenderá as expectativas do cliente. “ Armand V. Feigenbaum 5.

“Qualidade é a adequação ao uso do ponto de vista do cliente.” J.M. Juran  14.

“Qualidade é a totalidade de requisitos e características de um produto ou serviço que estabelecem a sua capacidade de satisfazer necessidades implícitas e explícitas .

“American Society for Quality Control 1.

“Interpretado de forma mais restrita, qualidade significa qualidade do produto.

Interpretado de forma mais ampla, qualidade significa qualidade de trabalho, qualidade de serviço, qualidade de informação, qualidade de processo, qualidade de pessoal, incluindo operários, engenheiros, gerentes e executivos, qualidade de sistema, qualidade de empresa, qualidade de objetivos” Kaoru Ishikawa 10.

“Um produto ou serviço de qualidade é aquele que atende perfeitamente, de forma confiável, de forma acessível, de forma segura e no tempo certo as necessidades do cliente” Vicente Falconi 4.

“Qualidade é conformidade com os requisitos” Philip B. Crosby 3.

Apesar de não haver uma única definição, podemos claramente perceber que quem define a qualidade em termos de necessidades e expectativas implícitas e explícitas é o CLIENTE. Essas necessidades e expectativas formam os requisitos a partir dos quais os produtos e serviços são projetados , os processos de fabricação, marketing ,entrega, instalação e assistência técnica também são projetados e realizados.

Entretanto esses requisitos podem evoluir com o tempo. Por isso é que nenhuma empresa pode afirmar que chegou no topo em termos da qualidade.É um processo dinâmico e evolutivo.

De acordo com James Teboul 19 na medida em que as expectativas do cliente são plenamente satisfeitas ou mesmo suplantadas, essas expectativas vão para um patamar superior e assim indefinidamente. A Figura 2-2 representa este mecanismo.•

Figura 2-2

Portanto, para qualquer empresa,a qualidade é uma busca contínua. ⌦ •

Controle da Qualidade

Para entendimento da figura, considere as formas circulares como as expectativas do cliente e as formas quadriláteras como o atendimento dessas expectativas pela empresa.

“O controle da qualidade é o conjunto de técnicas operacionais e atividades que sustentam a qualidade do produto e serviço que satisfará certas necessidades; também o uso de tais técnicas e atividades” American Society for Quality Control  1.

“Um sistema de métodos de produção que produzem economicamente bens ou serviços de boa qualidade atendendo aos requisitos do consumidor. O controle da qualidade moderno utiliza métodos estatísticos e é chamado frequentemente de controle estatístico da qualidade” Padrões Industriais Japoneses  .

“Praticar um bom controle de qualidade é desenvolver, projetar, produzir e comercializar um produto de qualidade que é mais econômico, mais útil e sempre satisfatório para o consumidor” Kaoru Ishikawa 10.

De modo mais prático, o controle da qualidade envolve técnicas e atividades operacionais objetivando o monitoramento de um processo e a eliminação das causas de desempenho insatisfatório, de modo a se obter uma eficiência econômica.

Geralmente, o monitoramento do processo é realizado através de técnicas estatísticas a fim de verificar a variabilidade do mesmo. Para a determinação das causas e sua eliminação são utilizadas as chamadas “ferramentas da qualidade”• ⌦

Garantia da Qualidade

“Todas as ações planejadas ou sistemáticas necessárias para prover confiança adequada de que o produto ou serviço satisfarão necessidades requeridas” American Society for Quality Control 1.

“Garantia da qualidade significa garantir a qualidade de um produto para que o consumidor possa comprá-lo com confiança e usá-lo por um longo período de tempo com satisfação e confiança” Kaoru Ishikawa 10.

“A garantia da qualidade tem como finalidade assegurar que todas as atividades da qualidade (qualidade do projeto,processo,fabricação etc.) estão sendo conduzidas da forma requerida.” Vicente Falconi 4.

“Garantia da qualidade é a atividade de prover a evidência necessária para estabelecer confiança de que a função da qualidade está sendo efetivamente desempenhada.” Frank M. Gryna 7.

Na indústria em geral, a garantia da qualidade é realizada com base em requisitos pré-determinados para cada fase do processo de produção de um produto, considerando desde o seu projeto até a assistência técnica. Este requisitos são verificáveis quanto a sua adequabilidade e têm possibilidade de produzirem evidências objetivas. Por exemplo, técnicas de especificação de projetos, padrão de apresentação de projeto, procedimento

•

Estas ferramentas são abordadas no capítulo 11, onde é mostrado sua aplicação na área de software.

da passagem do projeto para a engenharia de processo de fabricação, são requisitos veririficáveis quanto ao seu emprego efetivo.

A qualidade é garantida através de auditorias da qualidade, auditorias de produtos, auditorias do desenvolvimento de novos projetos, auditorias de processos e assim sucessivamente.

Este conceito já traz a noção de que as atividades da qualidade não se restringem a uma área da empresa, mas são responsabilidade de todos na organização. ⌦

Controle da Qualidade Total

“Controle da Qualidade Total envolve a implementação de atividades técnicas e gerenciais orientadas para prover qualidade ao cliente como responsabilidade principal da alta administração e das principais funções de linha tais como marketing, engenharia, produção, relações industriais, finanças e serviços, bem como a própria função de qualidade” Armand V. Feigenbaum 5.

“O Controle da Qualidade Total é uma abordagem que tem como princípios básicos: (i) qualidade em primeiro lugar - não os lucros a curto-prazo em primeiro lugar;(ii) orientação para o consumidor - não orientação sobre o enfoque da empresa;(iii) o primeiro processo é o cliente; (iv) usar fatos e dados - utilização de métodos estatísticos; (v) respeito pela humanidade como filosofia da administração - administração plenamente participativa; (vi) gerenciamento por funções cruzadas. “Kaoru Ishikawa 10.

“O Controle da Qualidade Total é regido pelos seguintes princípios básicos: (I) produzir e fornecer produtos e/ou serviços que atendam concretamente as necessidades do cliente;(ii) garantir a sobrevivência da empresa através do lucro contínuo adquirido pelo domínio da qualidade; (iii) identificar o problema mais crítico e solucioná-lo pela mais alta prioridade; (iv) falar, raciocinar e decidir sobre dados e com base em fatos, não com base na experiência,bom senso ou intuição;(v) gerenciar a empresa ao longo do processo, focalizando a prevenção;(vi) reduzir as dispersões nos processos através do isolamento de suas causas fundamentais; (vii) o cliente é o rei,não permitir a venda de produtos defeituosos;(viii) procurar prevenir a origem dos problemas; (ix) nunca permitir que o mesmo problema se repita pela mesma causa;(x) respeitar os empregados como seres humanos independentes.” Vicente Falconi 4 .

O conceito de Ishikawa , como não poderia deixar de ser, e o do Prof. Falconi, refletem a abordagem japonesa para Controle da Qualidade Total (CQT), diferentemente da proposta por Feigenbaum.

O CQT japonês, também denominado de Controle da Qualidade Total Por Toda a Empresa (TQCCW) tem como pressuposto a participação de todos na organização, independente da posição hierárquica. Ou seja, todos devem ser educados (permanentemente ) para a melhoria contínua de todos os processos da empresa visando a redução ou até mesmo a eliminação das causas de problemas que possam ocasionar defeitos nos produtos e serviços. A visão japonesa de CQT também abrange fornecedores , empresas filiadas e redes de distribuição.

Já a abordagem de CQT proposta por Feigenbaum ( que os japoneses denominam abordagem ocidental ) enfatiza a existência de uma área na organização especializada em controle da qualidade.

De acordo com Ishikawa a abordagem ocidental é domínio dos especialistas em controle da qualidade. ⌦

Sistema da Qualidade

“Um sistema da qualidade é uma estrutura de trabalho operacional por toda a empresa, documentada, integrando procedimentos técnicos e gerenciais, para orientar a coordenação das pessoas, das máquinas e da informação da empresa na melhor e mais prática forma, a fim de assegurar a satisfação do consumidor e custos econômicos da qualidade” Armand V. Feigenbaum 5.

“Estrutura organizacional, as responsabilidades, os procedimentos, processos e recursos para a implementação da gestão da qualidade” ISO 11.

O objetivo de um Sistema da Qualidade, de acordo com a ISO 12, é a especificação dos requisitos para que a empresa demonstre capacidade para controlar os processos que determinam a aceitabilidade do produto pelo cliente, bem como à prevenção e à detecção de qualquer não conformidade durante a produção e instalação e na implementação de meios para prevenir a sua reincidência.

Mais adiante, nos itens 2.4 e 2.5, são apresentados os Sistemas da Qualidade representados pelas normas ISO série 9000 e pelos Prêmios Nacionais da Qualidade.

2.2 - As Escolas da Qualidade Muitos autores e pensadores contribuiram decisivamente para o desenvolvimento dos conceitos, abordagens, métodos e práticas relativas à qualidade.

A base da disciplina, entretanto, concentra-se nas contribuições dos seguintes autores: Deming Juran Feigenbaum Ishikawa Crosby Imai Osada Visando complementar os conceitos expostos no item anterior, passaremos agora, a descrever, sucintamente, as contribuições desses autores, que caracterizam as Escolas da Qualidade. ⌦

Deming

A abordagem de Deming 17 baseia-se em 4 aspectos principais, quais sejam:

Os 14 Pontos de Deming A Teoria do Saber Profundo A Reação em Cadeia O Ciclo de Deming Este conjunto forma, na verdade, uma linha filosófica para a gestão da qualidade, que em essência é uma nova maneira de encarar a gestão da empresa.

De acordo com Deming, a boa qualidade significa um grau previsível de uniformidade e confiabilidade a baixo custo, estando a qualidade adequada ao mercado.

Os 14 Pontos de Deming Estabelecer a constância de propósito para melhorar o produto e o serviço Adotar a nova filosofia Acabar com a dependência da inspeção em massa Cessar a prática de avaliar as transações apenas com base nos preços Melhorar permanentemente os processos de planejamento, produção e serviço Instituir o treinamento no trabalho Instituir a liderança Afastar o medo Eliminar as barreiras entre as áreas da organização Eliminar slogans, exortações e metas para os empregados Eliminar as cotas numéricas Remover as barreiras que minam o orgulho do trabalhador Instituir um sólido programa de educação e retreinamento Agir no sentido de concretizar a transformação Teoria do Saber Profundo Conhecimento acerca da variação ( variabilidade dos processos) Conhecimento da função perda ( identificar custos da má qualidade) Conhecimento da filosofia de vencer ou vencer ( cooperação interna e parceria com fornecedores) Conhecimento de psicologia (motivações dos empregados) Conhecimento acerca da confiabilidade ( do produto) Teoria do conhecimento ( usar teoria e experiência conjuntamente)

A Reação Em Cadeia MELHORIA DA QUALIDADE

MELHORIA DA PRODUTIVIDADE

REDUÇÃO DE CUSTOS

PREÇOS MAIS BAIXOS

CONQUISTA DE MERCADOS

PERMANÊNCIA NO NEGÓCIO

EMPREGOS

RETORNO DO INVESTIMENTO

Figura 2-3

O Ciclo de Deming O Ciclo de Deming, mais conhecido como PDCA é uma abordagem para a gestão de processos. Pode ser utilizado tanto para a manutenção de um processo como para a sua melhoria.

PDCA significa: Plan ou planejamento que consiste no estabelecimento de metas da qualidade e a definição das estratégias para alcançá-las; Do ou execução que consiste na realização da tarefa como prevista no plano,bem como a coleta de dados para a análise do processo; Check ou verificação que consiste na análise propriamente dita do resultados da execução da tarefa; e Action ou ação corretiva que consiste na determinação de contramedidas para diminuir a variabilidade do processo ou eliminar causas dos problemas.

O ciclo PDCA é representado por um círculo como se estivesse em rotação no sentido horário , demonstrando a necessidade de rodá-lo indefinidamente, melhorando o processo continuamente.

Deming é considerado o “pai” da qualidade. Ao lado de Frederick Taylor, foi a pessoa que mais contribuiu para o desenvolvimento dos métodos de trabalho no ambiente industrial neste século.

O sucesso japonês na conquista de mercados com produtos inovadores, baratos e de boa qualidade se deve, fundamentalmente, aos ensinamentos de Deming.

A

C

P

D

Figura 2-4 O Ciclo de Deming

⌦

Juran

A grande contribuição dada por Juran 13 foi a famosa “trilogia”, na qual os componentes básicos da gestão da qualidade constituem-se em: Planejamento da Qualidade Controle da Qualidade Melhoria da Qualidade Resumidamente esta abordagem contempla: Planejamento da Qualidade É a atividade de desenvolvimento de produtos e processos necessários para atender às necessidades dos clientes, envolvendo: Determinação sobre quem são os clientes Determinação das necessidades dos clientes Desenvolvimento das características de produtos que respondam às necessidades dos clientes Desenvolvimento dos processos que sejam capazes de produzir essas características de produtos Transferência dos planos resultantes às forças operacionais Controle da Qualidade Avaliar o desempenho da qualidade real Comparar o desempenho real com as metas da qualidade Atuar nas diferenças Melhoramento da Qualidade Consiste na elevação do desempenho da qualidade a níveis inéditos e contempla os seguintes passos: Estabelecer a infra-estrutura necessária para assegurar um melhoramento da qualidade anual Identificar as necessidades específicas para melhoramento - os projetos de melhoramento Para cada projeto estabelecer uma equipe que tenha claramente a responsabilidade de fazer com que o projeto seja bem-sucedido Fornecer os recursos, motivação e treinamento necessários às equipes para diagnosticar as causas, estimular o estabelecimento de uma solução e estabelecer controles para manter ganhos

Juran também é considerado, juntamente com Deming, como responsável por introduzir, no Japão, onde esteve pela primeira vez em 1954, os conceitos de Gestão da Qualidade. ⌦

Feigenbaum

Feigenbaum 5 contribuiu para o detalhamento do conceito de controle da qualidade e na determinação das principais funções de CQ para obtenção da qualidade desejada pelo cliente.

Seu enfoque compreende o controle da qualidade em cada etapa do ciclo do produto na empresa, agrupando estas etapas em 4 principais funções, ou seja: Controle de Novos Projetos Esta função envolve o estabelecimento e especificação do custo qualidade, da qualidade do desempenho, da qualidade da segurança e qualidade da confiabilidade do produto requerido, visando a satisfação cliente, incluindo a eliminação ou localização das possíveis fontes problemas de qualidade antes do início efetivo da produção.

da da do de

Controle de Recebimento de Material Esta função envolve o recebimento e armazenamento, no nível mais econômico da qualidade, daquelas partes cuja qualidade tem conformidade com os requisitos de especificação, com ênfase na responsabilidade total do fornecedor.

Controle do Produto Esta função envolve o controle de produtos na fonte da produção e através de serviços de campo, de forma que as especificações de qualidade possam ser corrigidas antes que produtos defeituosos ou não conforme sejam fabricados, e que os serviços possam ser mantidos no campo para assegurar provisão integral à qualidade para o cliente.

Estudos de Processos Especiais Esta função envolve investigações e teste para localizar as causas de produtos não conformes, para determinar a possibilidade de aperfeiçoar as características da qualidade e para assegurar que o aperfeiçoamento e as ações corretivas sejam permanentes e completas.

Venda de Produtos Engenharia do Produto

Controle de Novos Projetos

Planejamento do Processo Aquisição de Material Recebimento e Inspeção de Material Fabricação de Partes e Produtos

Controle de Recebimento de Material Estudos de Processos Especiais

Inspeção e Testes de Produtos Expedição dos Produtos Instalação e Assistência Técnica

Controle do Produto

Figura 2-5 Modelo de TQC de Feigenbaum

⌦

Ishikawa

Ishikawa 10 foi o grande divulgador dos ensinamentos de Deming e Juran no Japão.

Expandiu os conceitos de controle e gestão da qualidade, criando o que êle denominou de Controle da Qualidade Total ( CQT) ao estilo japonês.

A essência do CQT preconizado por Ishikawa é a participação de todos na organização para a melhoria da qualidade. Por isso também é denominado de Controle da Qualidade por Toda a Empresa.

Um dos instrumentos básicos criados com o incentivo de Ishikawa para o Controle da Qualidade Total por Toda a Empresa foi o Círculo de Controle da Qualidade(CCQ) . O CCQ é um grupo informal formado por operários, supervisores e engenheiros, com a finalidade de melhorar a qualidade de um processo específico, melhorar as condições de segurança, melhorar o ambiente de trabalho e assim sucessivamente.

Outra contribuição foi o diagrama de causa e efeito ( também chamado de diagrama espinha de peixe ou diagrama de Ishikawa) para a análise de causas de problemas.

Para Ishikawa são 5 os fatores que contribuem para a variabilidade nos processos, os chamados 5 M’s: Material, Man, Machine, Measure, Methods. Atualmente foi incorporado mais um fator, o Environment ou Meio-Ambiente. A seguir é dado um exemplo do diagrama de causa e efeito.

material

máquina

medida

EFEITO

pessoas

método Figura 2-6 Diagrama de Ishikawa

⌦

Crosby

Philip B. Crosby 3, discípulo de Juran, estruturou sua visão sobre Gestão da Qualidade conforme os “Quatro Absolutos da Qualidade” e um plano de implementação composto por 14 passos.

Os “Quatro Absolutos São”: A qualidade se define pela conformidade às exigências O sistema da qualidade é a prevenção O padrão de desempenho é zero defeito A medida da qualidade é o preço pago pela não-conformidade Os quatorze passos para a implementação da Gestão da Qualidade são: Engajamento da Direção Equipe de melhoria da qualidade Medição Custo da qualidade Consciência da qualidade Ação corretiva Planejamento para zero defeito Educação Dia de zero defeito Estabelecimento de metas Remoção da causa do erro Reconhecimento Conselhos da qualidade Faça tudo de novo ⌦

Imai

Masaki Imai 9 contribuiu com a criação da filosofia do KAIZEN que em japonês significa melhoramento.

Assim como as demais Escolas, o KAIZEN proporciona uma linha filosófica para a melhoria contínua.

Esta linha filosófica é constituída pelos seguintes elementos: Conceito Básico do KAIZEN KAIZEN significa melhoramento contínuo, envolvendo todos, inclusive gerentes e operários, ou seja, o nosso modo de vida - seja no trabalho, na sociedade ou em casa - merece ser constantemente melhorado.

Abrangência do KAIZEN KAIZEN é um conceito de guarda-chuva que abrange a maioria das práticas japonesas como: (i) orientação para o consumidor; (ii) TQC; (iii) CCQ; (iv) sistema de sugestões; (v) disciplina no local do trabalho; (vi) manutenção produtiva total; (vii) kanban; (viii) melhoramento da qualidade; (ix) just-in-time: (x) zero defeitos (xi) atividades em pequenos grupos; (xii) melhoramento da produtividade; (xiii) desenvolvimento de novos produtos.

Componentes Básicos da Administração A administração tem dois componentes principais, a manutenção e o melhoramento. A manutenção consiste em manter os padrões atuais de tecnologia, administrativos e operacionais. O melhoramento é dirigido para melhorar os padrões atuais.

Administração Orientada Para o Processo O KAIZEN é orientado para o processo e baseia-se fundamentalmente nas pessoas para os esforços de melhoramento. Por basear-se em pessoas exige mudança comportamental. A atuação é sobre prevenção.

Características do KAIZEN Os resultados são atingidos a longo-prazo, porém são duradouros; a mudança é gradual e constante; o envolvimento é de todos; exige pouco investimento entretanto com grande esforço para manter; a orientação do esforço são as pessoas;a avaliação é baseada nos resultados das melhorias.

Estabilização dos Padrões Atuais Antes de iniciar o ciclo PDCA de melhoria contínua é necessário padronizar os processos atuais. ⌦

Osada

Takashi Osada 16 foi o criador da filosofia de “housekeeping” ou 5S’s.

Os 5S’s são assim chamados em virtude das palavras japonesas Seiri,Seiton,Seiso, Seiketsu, Shitsuke que significam respectivamente organização, arrumação, limpeza, padronização e disciplina.

De acordo com Osada a qualidade e produtividade são atingidos pelos 5S’s.

Organização Significa distinguir o necessário do desnecessário no ambiente de trabalho.

Arrumação Consiste em colocar as coisas nos lugares certos ou dispostas de forma correta, para que possam ser usadas prontamente, acabando com a procura de objetos.

Limpeza Significa manter limpo o local de trabalho.

Padronização Significa manter a organização, a arrumação e a limpeza contínua e constantemente.

Disciplina Significa criar ou ter a capacidade de fazer as coisas como deveriam ser feitas;é um processo de repetição e prática.

2.3 - Custos da Qualidade Todas as organizações contabilizam os custos para o desenvolvimento de suas várias funções, quais sejam: marketing, pessoal, projeto, finanças, produção, assistência técnica e assim sucessivamente. Geralmente esta contabilização adota o conceito de centros de custos, sendo que cada centro de custo é representado por um setor, divisão ou departamento da empresa.

Esta abordagem de contabilização ainda presente em praticamente todas as empresas, não permite a contabilização de custos de atividades multifuncionais (atividades que permeiam várias áreas da empresa) como é o caso dos custos da qualidade.• Até a década de 50, os únicos custos relativos à atividades da qualidade nas empresas industriais e que compunham o custo de fabricação eram os relativos a inspeção e teste.

•

Atualmente uma nova abordagem para a contabilização de custos de atividades multifuncionais é o que se denomina custo ABC (Activity Based Costing). Vide a referência 15 para maiores detalhes sobre o tema.

Com a introdução das filosofias de controle da qualidade e qualidade total, os especialistas começaram a perceber que os custos das atividades da qualidade estavam “escondidos” em contas de “overhead”.

Para evidenciar a importância da qualidade para as empresas e vendê-la aos demais gerentes da companhia e alta administração, cuja linguagem está sempre relacionada a “dinheiro”, os reponsáveis pelos primeiros Departamentos de Controle da Qualidade sentiram a necessidade de estudar os custos relacionados com a qualidade.

Como resultado destes estudos algumas surpresas apareceram 8: Os custos relacionados com a qualidade eram muito maiores do que haviam sido mostrados, até então nos relatórios contábeis comuns. Para a maioria das empresas estes custos representavam de 20 a 40% do faturamento anual.

Os custos da qualidade não eram simplesmente o resultado de operações de fabricação: as operações de apoio eram as principais fontes.

A fonte dos custos era resultado de pouca qualidade. Tais custos eram de fato, evitáveis.

Enquanto os custos da má qualidade eram evitáveis, não haviam responsabilidades claras sobre as ações para reduzí-los e nem haviam estruturas para desempenhar essas ações.

Como no passado, ainda há muita confusão a respeito do significado para custos da qualidade.

Custos da qualidade não são os custos para obter qualidade mas sim os custos por não ter qualidade, ou seja, encontrar e corrigir o trabalho defeituoso.

Alguns “experts” , tais como Gryna 8 , definem como custos da qualidade os custos da má qualidade.

Os custos da qualidade são categorizados como: Custos de Falhas Internas São custos associados com defeitos encontrados antes de entregar o produto ou serviço ao cliente.

Custos de Falhas Externas São custos associados com defeitos encontrados depois da entrega do produto ou serviço ao cliente.

Custos de Avaliação

São os custos incorridos para determinar o grau de conformidade do produto ou serviço aos requisitos da qualidade, previamente establecidos.

Custos de Prevenção São os custos incorridos para manter os custos de falha interna, externa e de avaliação a um patamar mínimo.

Esta categorização representa uma das essências fundamentais da qualidade, que é o investimento contínuo em prevenção para a produção econômica de bens e serviços.

Ou seja, a qualidade não está dissociada de baixo custo e, consequentemente,da lucratividade.

Para finalizar este tópico apresentamos os tipos de custos para cada categoria, de acordo com Gryna.

Custos de Falhas Internas Refugo: o trabalho, material , componentes e custos fixos sobre produto defeituoso que não pode ser economicamente recuperado.

Retrabalho: os custos de corrigir produtos defeituosos para adequá-lo ao uso.

Análise de Falhas: os custos de analisar produtos não conformes a fim determinar as causas da não conformidade.

Refugo e Retrabalho do Fornecedor: os custos de refugo e retrabalho devido ao recebimento de produtos não conformes dos fornecedores.

Inspeção 100% : o custo de encontrar unidades defeituosas em um lote de produtos que contém um nível inaceitável de itens defeituosos.

Reinspeção e teste : os custos da reinspeção e teste de produtos que foram retrabalhados.

“Downgrading” : a diferença entre o preço normal de venda e a redução do preço devido a razões de qualidade.

Custos de Falhas Externas Responsabilidades de Garantia : os custos envolvidos em substituir ou realizar reparos em produtos que ainda encontram-se em período de garantia.

Ajustamento de Reclamações : os custos de investigar e ajustar reclamações justificadas atribuídas a produto defeituoso ou à instalação do produto.

Material Devolvido : os custos associados com o recebimento e devolução de produto defeituoso.

Concessões : os custos de concessões feitas ao cliente em virtude do produto aceito não ter os padrões especificados ou não estar dentro da conformidade adequada para as necessidades de uso.

Custos de Avaliação Inspeção e Teste de Recebimento : os custos de determinar a qualidade do produto comprado, através da inspeção no recebimento.

Inspeção e Teste no Processo : os custos de avaliar a conformação dos requisitos para a aceitação do produto.

Inspeção e Teste Final : os custos de avaliar a conformidade dos requisitos para a aceitação do produto.

Auditorias da Qualidade do Produto : os custos de realizar auditorias da qualidade durante o processo ou em produtos.

Manutenção da Exatidão dos Equipamentos de Teste : os custos de manter os equipamentos de medição calibrados.

Serviços e Materiais de Inspeção e Teste : os custos de materiais e suprimentos para o trabalho de inspeção e teste, bem como os serviços.

Avaliação de Estoques : os custos de testar produtos no campo, armazenados ou em estoque para evitar degradação.

Custos de Prevenção Planejamento da Qualidade : incluem os custos relacionados com a elaboração de planos da qualidade e procedimentos para comunicar estes planos a todos envolvidos.

Revisão de Novos Produtos : os custos de engenharia de confiabilidade e outras atividades relacionadas com qualidade, associadas com o lançamento de novos projetos.

Planejamento do Processo : os custos de estudos de capacidade do processo, planejamento das inspeções e outras atividades associadas com o processo de fabricação.

Controle do Processo : os custos de inspeção e teste durante o processo para determinar o seu “status”.

Auditorias da Qualidade : os custos de avaliar a execução de atividades do plano e sistema da qualidade.

Avaliação da Qualidade dos Fornecedores : os custos de avaliar as atividades de qualidade dos fornecedores antes de sua seleção ( auditoria de segunda parte ) ; auditoria das atividades durante o contrato e esforço de desenvolvimento dos fornecedores.

Treinamento : o custo de preparar e conduzir programas relacionados à qualidade.

2.4 - Sistemas da Qualidade Baseados Nas Normas ISO Em 1987, a ISO ( International Organisation for Standardization ) com sede em Genebra, da qual o Brasil participa através da ABNT ( Associação Brasileira de Normas Técnicas), publicou a série de Normas 9000 sobre Gestão da Qualidade.

Os principais motivadores para a publicação dessas normas foram: Os altos custos de auditorias de segunda parte (empresa audita o fornecedor), devido aos diversos critérios de avaliação e especificação que as empresas fornecedoras de bens e serviços tinham que se submeter quando eram auditadas por mais de um cliente, refletindo sobre o preço final do produto para ambas as partes.

A globalização da economia , exigindo certa uniformidade nos elementos de garantia da qualidade na produção de bens e serviços.

A adoção pelos países mais desenvolvidos ( Estados Unidos, Inglaterra, Canadá principalmente), de normas específicas relativas a sistemas da qualidade, anteriores à publicação das normas série 9000.

A série ISO 9000 ( NB-9000 no Brasil) constitue-se em um conjunto de normas internacionais para os sistemas da qualidade.

Ela fornece orientações sobre como estruturar o Sistema da Qualidade da empresa, de forma que a mesma possa evidenciar a qualidade do seu processo de produção de bens e serviços, demonstrando assim que é capaz de suprir as necessidades dos clientes conforme requisitos previamente estabelecidos.

Atualmente a série 9000 é considerada como barreira técnica imposta por muitos países desenvolvidos , principalmente os da Comunidade Econômica Européia, aos países de economia emergente como é o caso do Brasil.

Independente deste fato, a adoção por uma empresa de um Sistema da Qualidade baseado na série ISO 9000 é motivada por: Imposição Contratual de Um ou Mais Clientes Neste caso a empresa deve evidenciar ao cliente que mantém política e objetivos da qualidade consistentes e entendidos por todos os seus colaboradores ( fornecedores, funcionários, acionistas); possui

procedimentos relativos aos elementos da norma , documentados e em uso efetivo, congruentes com a política da qualidade.

Além destes requisitos, a empresa deve submeter-se a auditorias de terceira parte ( empresa contrata empresa de auditoria de sistemas da qualidade para obter certificação).

Iniciativa Própria Neste caso a empresa visa: redução de custos de não conformidade, para aumento da lucratividade; manutenção do nível de satisfação dos clientes; melhor competitividade; aumento de participação de mercado.

A série 9000 é composta por um conjunto de normas ( ou família ) que pode ser dividido em normas para fins contratuais e de guias de orientação, conforme mostra a Figura 2-7.

Para fins de certificação do Sistema da Qualidade, em função de imposição contratual , a empresa pode escolher entre a ISO 9001, 9002 e 9003.

A ISO 9001 é a mais abrangente e pode ser utilizada por empresas que projetam, desenvolvem, fabricam, instalam produtos e prestam assistência técnica.

A ISO 9002 , menos rigorosa que a 9001, pode ser utilizada por empresas que devem garantir a produção, instalação e assistência técnica ao produto. É possível a aplicação desta norma a empresas que também projetam produtos. Entretanto o seu Sistema da Qualidade somente abrangerá o ciclo produção, instalação e assistência técnica. Empresas que somente montam produtos , ou seja, já recebem o projeto pronto do seu parceiro tecnológico são exemplos de empresas que podem certificar-se conforme a 9002.

A 9003, por sua vez, se aplica a situações onde o fornecedor deve garantir a capacidade no que se refere a inspeção e ensaios finais. Aplica-se a laboratórios de inspeção, distribuidores de produtos etc. As certificações segundo esta norma representam apenas 4% do total das certificações que hoje, a nível mundial, já chegam a 30.000 18.

Em 1994 a série 9000 foi revisada esclarecendo alguns pontos obscuros em relação à versão de 1987.

Cada norma é composta por elementos numerados, os quais especificam o Sistema da Qualidade. É importante ressaltar que as normas série ISO 9000 não especificam “o como” fazer, mas sim o que fazer. O como fica a cargo da empresa definir.

Para melhor compreensão daremos uma breve visão sobre os 20 elementos do Sistema da Qualidade conforme a ISO 9001 .•

•

Vide 17  para informações mais detalhadas acerca das normas série ISO 9000.

Elemento 4.1 - Responsabilidade da Administração Tópicos abordados: Política e objetivo da qualidade Responsabilidade e autoridade pelas atividades relativas à qualidade no âmbito da empresa Recursos e pessoal para atividades de verificação Designação do representante da administração no que concerne à qualidade Análise crítica do sistema da qualidade pela administração Elemento 4.2 - Sistema da Qualidade Tópicos abordados: Manual da qualidade com a estrutura do sistema da qualidade e procedimentos Procedimentos consistentes com a política da qualidade Planejamento da qualidade definido e documentado Planejamento da qualidade consistente com os requisitos do sistema da qualidade e adequado ao método do fornecedor Elemento 4.3 - Análise Crítica do Contrato Tópicos abordados: Manutenção de procedimentos para análise crítica do contrato Elemento 4.4 - Controle de Projeto Tópicos abordados: Planejamento do projeto Atribuições das atividades de planejamento identificadas Interfaces técnicas e organizacionais definidas Identificação e documentação dos requisitos de entrada do projeto Consideração de outras legislações existentes para o projeto Vinculação dos requisitos de entrada com a análise crítica do contrato Documentação dos dados resultantes do projeto Dados de saída do projeto verificados e validados com os de entrada Liberação do projeto somente após a análise crítica dos dados de saída Execução e análise crítica do projeto Registro das ações para verificação Controle das alterações no projeto Elemento 4.5 - Controle de Documentos Tópicos abordados: Aprovação e emissão de documentos Controle de documentos externos referenciados no sistema da qualidade Identificação de documentos obsoletos em uso Alterações e modificações em documentos

Elemento 4.6 - Aquisição Tópicos abordados: Avaliação de subfornecedores Seleção de subfornecedores Avaliação do sistema da qualidade do subfornecedor Definição do tipo e extensão do controle Análise crítica dos documentos de aquisição Verificação do produto adquirido pelo comprador Elemento 4.7 - Produto Fornecido Pelo Comprador Tópicos abordados: Manutenção de procedimentos para verificação, manutenção de produto fornecido pelo comprador

armazenagem

e

Elemento 4.8 - Identificação e Rastreabilidade de Produto Tópicos abordados: Estabelecimento e manutenção de procedimentos para identificação de produtos durante todo os estágios de produção, expedição e instalação Elemento 4.9 - Controle de Processo Tópicos abordados: Planejamento da produção Controle das condições de produção Monitorização do processo e controle Aprovação de processos e equipamentos Critérios de qualidade do trabalho Controle de processos especiais Manutenção de equipamentos para assegurar a contínua capabilidade do processo Elemento 4.10 - Inspeção e Ensaios Tópicos abordados: Inspeção e ensaios de recebimento Inspeção e ensaios no processo produtivo Inspeção e ensaios finais Registros de inspeção e ensaios Documentação dos testes e resultados Autoridade para liberação Elemento 4.11 - Equipamentos de Inspeção, Medição e Ensaios Tópicos abordados: Identificação das medições a serem feitas Identificação, aferição e calibração de todos os equipamentos de inspeção e ensaios que possam afetar a qualidade

Estabelecimento, documentação e manutenção de procedimentos para aferição e calibração Mostrar a situação de aferição de cada equipamento Demonstração ao comprador da adequação dos equipamentos de inspeção e ensaio Avaliação e documentação dos resultados de inspeção e ensaios Assegurar condições ambientais para as aferições/calibração Assegurar condições adequadas para o manuseio, preservação e armazenamento dos equipamentos de inspeção e ensaios Verificação de programas de computador usados para inspeção e ensaios Manutenção de registros sobre as inspeções e ensaios

Elemento 4.12 - Situação da Inspeção e Ensaios Tópicos abordados: Identificação da inspeção e ensaio do produto ao longo da produção e instalação Definição da autoridade para liberação de produtos conformes Manutenção de procedimentos referentes ao elemento Elemento 4.13 - Controle de Produtos Não Conformes Tópicos abordados: Análise crítica e disposição de produtos não conformes Manutenção de procedimentos para impedir que produtos não conformes sejam usados na produção Controle de produtos não conformes Elemento 4.14 - Ação Corretiva Tópicos abordados: Investigação de causas de não conformidades e definição de ações corretivas para prevenir repetição Controle sobre o andamento das ações corretivas Implementação e registro de alterações nos procedimentos em função das ações corretivas Análise dos dados de não conformidade e de ações corretivas pela administração Elemento 4.15 - Manuseio, Armazenamento, Embalagem e Expedição Tópicos abordados: Estabelecimento de métodos para manuseio que evitem danos Designação de áreas de armazenamento Controle dos processos de embalagem Expedição Elemento 4.16 - Registros da Qualidade

Tópicos abordados: Estabelecimento de procedimento para controle dos registros da qualidade inclusive os eletrônicos Definição dos tempos de retenção dos registros da qualidade Disponibilização para o comprador dos registros da qualidade Elemento 4.17 - Auditorias Internas da Qualidade Tópicos abordados: Implementação de auditoria interna do sistema da qualidade Documentação das auditorias internas Acompanhamento e avaliação da eficácia das ações corretivas Elemento 4.18 - Treinamento Tópicos abordados: Estabelecimento e manutenção de procedimentos para identificar as necessidades de treinamento Manutenção de registros de treinamento Elemento 4.19 - Assistência Técnica Tópicos abordados: Estabelecimento e manutenção de procedimentos acerca de serviço pósvenda Elemento 4.20 - Técnicas Estatísticas Tópicos abordados: Estabelecimento de procedimentos para identificação de estatísticas Controle da aplicação das técnicas estatísticas especificadas

técnicas

Um dos aspectos principais da evidência do funcionamento de um Sistema da Qualidade, conforme a série 9000, é a sua documentação. Cerca de 90% das não conformidades encontradas por empresas de certificação reside na documentação  18 .

A documentação do sistema da qualidade geralmente é especificada em 4 níveis conforme mostra a Figura 2-8.

MANUAL DA QUALIDADE MANUAL DE PROCEDIMENTOS INSTRUÇÕES DE TRABALHO REGISTROS, FORMULÁRIOS

Figura 2-8 Documentação do Sistema da Qualidade

Os conteúdos dos respectivos níveis são: Manual da Qualidade: Declaração da Política da Qualidade da Empresa Objetivos da Qualidade Estrutura da Empresa Responsabilidades Relativas à Qualidade Representante da Administração Análise Crítica do Sistema da Qualidade Descrição do Sistema da Qualidade O Manual da Qualidade ou MQ geralmente contém informações que compreendem os elementos 4.1 e 4.2 da norma.

Manual de Procedimentos: O Manual de Procedimentos deve descrever, para cada um dos elementos,4.3 a 4.20, o processo respectivo em grandes linhas. O detalhe específico, usualmente é descrito pelas Instruções de Trabalho.

Procedimento de Análise Crítica de Contrato Procedimento de Controle de Projeto Procedimento de Controle de Documentos Procedimentos de Aquisição Procedimento de Produto Fornecido Pelo Comprador Procedimento de Identificação e Rastreabilidade de Produto Procedimento de Controle de Processo Procedimento de Inspeção e Ensaios Procedimento de Equipamentos de Inspeção,Medição e Ensaios Procedimento de Situação de Inspeção e Ensaios Procedimento de Controle de Produtos Não Conformes Procedimento de Ação Corretiva Procedimento de Manuseio,Armazenamento, Embalagem e Expedição Procedimento de Registros da Qualidade Procedimentos de Auditorias Internas da Qualidade Procedimentos de Treinamento Procedimentos de Assistência Técnica Procedimentos de Técnicas Estatísticas Instruções de Trabalho

As instruções de trabalho contemplam o detalhamento de um procedimento. Ou seja, um procedimento pode conter mais de uma Instrução de Trabalho. Por exemplo, o procedimento sobre Análise Crítica de Contrato, poderia, hipoteticamente, referenciar Instruções de Trabalho, tais como: Elaboração de Propostas Técnicas Elaboração de Propostas Comerciais Controle de Versões de Propostas Registros de Reuniões de Especificação de Requisitos Registros,Formulários Nesta parte da documentação são descritos os registros e formulários pertinentes e necessários ao Sistema da Qualidade. Estes registros e formulários podem estar em forma de sistemas informatizados.

A documentação do Sistema da Qualidade é condição necessária para que a empresa se candidate à certificação na norma selecionada (9001,9002 ou 9003). A outra condição é que o Sistema esteja efetivamente implementado.

A certificação é obtida através de uma Auditoria Externa contratada pela própria empresa. O objetivo da auditoria é o de obter evidências objetivas da conformidade do Sistema da Qualidade com a norma. A auditoria é realizada por uma empresa Certificadora, independente, credenciada por um órgão Credenciador.

No Brasil o órgão credenciador é o INMETRO. Os órgãos credenciadores mais respeitados no mundo industrializado são o RAB - Registrar Accreditation Board, americano, o NACCB - National Accreditation Council for Certification Bodies, inglês, o Standards Council of Canada e RVC , holandês.

Conforme o órgão certificador, o certificado de conformidade do Sistema da Qualidade é válido por até 3 anos, sendo que no decorrer do período de validade há acompanhamento por parte da Auditoria Externa em intervalos de 6 em 6 meses.

As auditorias são conduzidas por um Auditor Líder (Leader Assessor) registrado nos órgãos credenciadores. Periodicamente este registro deve ser revalidado.Esta revalidação é feita em função da evidência documentada da participação do Auditor Líder em auditorias de sistemas da qualidade.

2.5 - Outros Sistemas da Qualidade Alguns países, no sentido de promover o desenvolvimento da excelência empresarial em termos da Qualidade Total, instituiram Prêmios Nacionais da Qualidade.

Descreveremos qualidade.

sucintamente, a seguir, os principais prêmios nacionais da

Estados Unidos - Malcolm Baldrige Award• Instituido pelo governo norte-americano em homenagem a Malcolm Braldrige , exSecretário do Comércio no governo Reagan.

Este prêmio é oferecido às empresas americanas que se destacam em Gestão da Qualidade. A premiação possui três categorias: empresas industriais, de serviços e pequenas empresas.

Para receber o prêmio, a empresa candidata tem que apresentar um sistema de Gestão da Qualidade Total o qual é avaliado segundo critérios específicos.

Critérios de Avaliação (1992) 1.0 - Liderança 1.1 - Liderança da alta administração 1.2 - Gestão para a qualidade 1.3 - Responsabilidade comunitária 2.0 - Informação e Análise 2.1 - Abrangência e gestão de dados e das informações sobre qualidade e desempenho 2.2 - Comparações com a concorrência e referenciais de excelência 2.3 - Dados da empresa: análise e uso 3.0 - Planejamento Estratégico da Qualidade 3.1 - Processo de planejamento estratégico da qualidade 3.2 - Planejamento da qualidade e desempenho 4.0 - Desenvolvimento e Gestão de Recursos Humanos 4.1 - Gerenciamento de recursos humanos 4.2 - Envolvimento dos funcionários 4.3 - Educação e treinamento dos funcionários 4.4 - Desempenho e reconhecimento dos funcionários 4.5 - Bem-estar e moral dos funcionários 5.0 - Gestão da Qualidade de Processos 5.1 - Projeto e introdução de produtos e serviços 5.2 - Gestão de processos - processos de produção e fornecimento de produtos 5.3 - Gestão de processos - processos de negócio e dos serviços de apoio 5.4 - Qualidade dos fornecedores 5.5 - Avaliação da qualidade 6.0 - Resultados Obtidos Quanto à Qualidade e às Operações 6.1 - Resultados obtidos quanto à qualidade de produtos e serviços 6.2 - Resultados obtidos quanto às operações da empresa 6.3 - Resultados obtidos quanto à qualidade no processo de negócio e em serviços de apoio 6.4 - Resultados obtidos quanto à qualidade dos fornecedores 7.0 - Focalização no Cliente e Sua Satisfação 7.1 - Gestão do relacionamento com os clientes 7.2 - Compromisso com os clientes 7.3 - Determinação da satisfação dos clientes •

Vide referência 17 para maiores detalhes sobre o Prêmio Baldrige.

7.4 - Resultados relativos à satisfação dos clientes 7.5 - Comparação da satisfação dos clientes 7.6 - Requisitos e expectativas futuras dos clientes Japão - Prêmio Deming 17 Prêmio instituído pela JUSE - Union of Japanese Scientists and Engineers em 1951, em reconhecimento aos trabalhos do Dr. Deming para os esforços de melhoria da qualidade no Japão.

O Prêmio é dividido em três categorias : (1) Prêmio Deming para Pessoas Individual, (2) Prêmio Deming de Aplicação do Controle da Qualidade, e (3) Prêmio Deming de Controle da Qualidade para Fábricas.

Os elementos de verificação são descritos a seguir.

Critérios de Avaliação ( 1991) 1.0 - Política 1.1 - Políticas para gestão, qualidade e controle da qualidade 1.2 - Método para estabelecer as políticas 1.3 - Justificação e consistência das políticas 1.4 - Utilização de métodos estatísticos 1.5 - Transmissão e difusão de politicas 1.6 - Análise das políticas e dos resultados alcançados 1.7 - Relação entre as políticas e o planejamento a longo e a curto prazos 2.0 - Organização e Sua Gestão 2.1 - Explicitação dos limites da autoridade e responsabilidade 2.2 - Adequação das delegações de autoridade 2.3 - Cooperação entre as divisões 2.4 - Comissões e suas atividades 2.5 - Utilização do pessoal 2.6 - Utilização de atividades de círculos de controle da qualidade 2.7 - Diagnóstico do controle da qualidade 3.0 - Educação e Disseminação 3.1 - Programa de educação e resultados 3.2- Consciência da qualidade e do controle da qualidade, graus de compreensão do controle da qualidade 3.3 - Ensino dos métodos e conceitos estatísticos, e a extensão de sua disseminação 3.4 - Noção da eficácia do controle da qualidade 3.5 - Educação de empresa relacionada 3.6 - Atividades de círculo de controle da qualidade 3.7 - Sistema de sugestão para melhoria 4.0 - Coleta,Disseminação e Utilização de Informações Sobre Qualidade 4.1 - Coleta de informações externas 4.2 - Transmissão de informações entre divisões 4.3 - Velocidade na transmissão de informações ( utilização de computadores)

4.4 - Processamento de dados, análise estatística de informação e utilização dos resultados 5.0 - Análise 5.1 - Seleção de problemas 5.2 - Adequação da abordagem analítica 5.3 - Utilização de métodos estatísticos 5.4 - Ligação com tecnologia adequada 5.5 - Análise de qualidade, análise de processos 5.6 - Utilização de resultados analíticos 5.7 - Adequabilidade das sugestões de melhoria 6.0 - Normalização 6.1 - Sistematização de normas 6.2 - Métodos de disseminação, revisão e descarte de normas 6.3 - Resultado do estabelecimento, revisão ou revogação de normas 6.4 - Conteúdos das normas 6.5 - Utilização de métodos estatísticos 6.6 - Acúmulo de tecnologia 6.7 - Utilização de normas 7.0 - Controle 7.1 - Sistema de controle da qualidade 7.2 - Itens de controle e pontos de controle 7.3 - Utilização de métodos estatísticos de controle 7.4 - Contribuição para os círculos de controle da qualidade 7.5 - Condições reais de atividades de controle 7.6 - Situação do controle 8.0 - Garantia da Qualidade 8.1 - Procedimentos para o desenvolvimento de novos produtos e serviços 8.2 - Segurança contra responsabilidade civil do produto 8.3 - Projeto de processo, análise de processo, controle do processo e melhoria 8.4 - Capacidade do processo 8.5 - Instrumentação, aferição, ensaio e inspeção 8.6 - Manutenção de equipamentos, controle de subcontratação,compras e serviços 8.7 - Sistema de garantia da qualidade e auditoria do sistema 8.8 - Utilização de métodos estatísticos 8.9 - Avaliação e auditoria da qualidade 8.10 - Situação real da garantia da qualidade 9.0 - Resultados 9.1 - Medição de resultados 9.2 - Resultados reais em qualidade 9.3 - Resultados intangíveis 9.4 - Ações para remoção de resultados 10 - Planejamento Para o Futuro 10.1 - Compreensão do estágio atual e da adequabilidade do plano 10.2 - Medidas para remover defeitos 10.3 - Planos para novos avanços 10.4 - Ligação com planos de longo prazo Brasil - Prêmio Nacional da Qualidade 6 

Instituído pela Fundação Prêmio Nacional da Qualidade a partir de 1992. A FPNQ tem a participação do governo e de empresas e entidades privadas. O PNQ foi projetado nos moldes do Baldrige Award. Qualquer empresa brasileira• pode candidatar-se ao Prêmio.

Os elementos de verificação são descritos a seguir.

Critérios de Avaliação ( 1994 ) 1.0 - Liderança 1.1 - Liderança pela alta direção 1.2 - Gestão para a qualidade 1.3 - Responsabilidade comunitária e espírito cívico da empresa 2.0 - Informação e Análise 2.1 - Abrangência e gestão dos dados e informações sobre qualidade e desempenho 2.2 - Comparações com a concorrência e com referenciais de excelência 2.3 - Dados da empresa: análise e uso 3.0 - Planejamento Estratégico da Qualidade 3.1 - Processo de planejamento estratégico da qualidade e do desempenho da empresa 3.2 - Planejamento da qualidade e o do desempenho 4.0 - Desenvolvimento e Gestão de Recursos Humanos 4.1 - Planejamento e gestão de recursos humanos 4.2 - Envolvimento dos funcionários 4.3 - Educação e treinamento em qualidade 4.4 - Desempenho e reconhecimento dos funcionários 4.5 - Bem-estar e satisfação dos funcionários 5.0 - Gestão da Qualidade de Processos 5.1 - Projeto e introdução no mercado de produtos e serviços 5.2 - Gestão de processos: processos de produção e fornecimento de produtos e serviços 5.3 - Gestão de processos: processos do negócio e dos serviços de apoio 5.4 - Qualidade dos fornecedores 5.5 - Avaliação da qualidade 6.0 - Resultados Obtidos Quanto à Qualidade e às Operações 6.1 - Resultados obtidos quanto à qualidade de produtos e serviços 6.2 - Resultados obtidos quanto à operações da empresa 6.3 - Resultados obtidos quanto à qualidade no processo do negócio e em serviços de apoio 6.4 - Resultados obtidos quanto à qualidade de fornecedores 7.0 - Focalização no Cliente e Sua Satisfação 7.1 - Expectativa dos clientes: presentes e futuros 7.2 - Gestão do relacionamento com os clientes 7.3 - Compromisso com os clientes 7.4 - Determinação da satisfação dos clientes 7.5 - Resultados relativos à satisfação dos clientes •

Para este autor, empresa brasileira é qualquer empresa instalada em território nacional, independente da origem do capital e do seu controle acionário.

7.6 - Comparação da satisfação dos clientes Ao contrário da ISO, os Prêmios Nacionais da Qualidade aqui descritos focalizam a Gestão da Qualidade Total, bem mais abrangente que o Sistema da Qualidade preconizado pela série 9000 de normas.

Atualmente, os Prêmios Nacionais têm sido utilizados por muitas empresas para realizar “Benchmarking” , que é o processo de comparar-se às melhores práticas gerenciais e operacionais.

O atendimento aos requisitos ou critérios de avaliação desses Prêmios indica para o mercado que a empresa é uma operação de classe mundial.

De acordo com a base de dados PIMS - Profit Impact of Market Strategy 2 • a Qualidade é a estratégia que mais traz retorno para a empresa. Ela possibilita: Lealdade mais forte por parte dos clientes Maior repetição de compras pelos clientes Menor vulnerabilidade a guerras de preços Capacidade de obter preços relativos mais elevados sem afetar a participação no mercado Custos mais baixos de marketing Aumentos de participação no mercado Maior retorno sobre os investimentos e sobre as vendas REFERÊNCIAS 1. ASQC, Statistics Division. Glossary and Tables for Statistical Quality Control.

Milwaukee, 2nd edition,1983.

2. BUZZEL,Robert D & GALE, Bradley T. PIMS - O Impacto das Estratégias de no resultado das Empresas. Pioneira,São Paulo, 1991.

Mercado

3. CROSBY, Philip B. Qualidade é Investimento. José Olympio Editora, Rio de Janeiro,1984.

4. FALCONI, Vicente Campos. TQC - Controle da Qualidade Total (no estilo japonês).

Fundação Christiano Otoni, Belo Horizonte,1992.

5. FEIGENBAUM, Armand V. Total Quality Control. McGraw-Hill, 3rd edition,New York,1986.

6. FGV. Curso de Gestão da Qualidade Total. São Paulo,1994.

7. GRYNA, Frank M. Quality Assurance. In: Juran’s Quality Control Handbook. McGrawHill, 4th edition, New York, 1988.

•

A base de dados PIMS contém o maior conjunto de informações estratégicas do mundo sobre cerca de 3000 unidades de negócio. Avalia o impacto de estratégias empresariais sobre os resultados da empresas.

8. ______, Frank M. Quality Costs. In: Juran’s Quality Control Handbook.

Hill, 4th edition, New York, 1988.

McGraw-

9. IMAI, Masaki. KAIZEN: a estratégia para o sucesso competitivo. Instituto IMAM,São Paulo, 4a. edição, 1988.

10.ISHIKAWA, Kaoru. Controle da Qualidade Total à Maneira Japonesa. Editora Campus,Rio de Janeiro, 1993.

11.ISO -9000: 1987 (E) - Quality Management and Quality Assurance Standards Guidelines Selection and Use - International Organization for Standardization.

12.ISO-9001: 1987 (E) - Quality Systems - Model for Quality Assurance in Design/Development,Production,Installation ans Servicing - International Organization for Standardization.

13.JURAN, J.M. Juran na Liderança Pela Qualidade: um guia para executivos.

Pioneira/IMAM, São Paulo,1990.

14. JURAN,J.M. Juran’s Quality Control Handbook. McGraw-Hill, 4th edition,New York,1988.

15.

NAKAGAWA, Masayuki.

Paulo,1994.

ABC

-

Custo

Baseado

em

Atividade.

Atlas,São

16. OSADA, Takashi. Housekeeping - 5S’s : cinco pontos-chaves para o ambiente da qualidade total. Instituto IMAM,São Paulo,1992.

17.PURI, Subhash C. ISO 9000- Certificação - Gestão da Qualidade Total.Qualitymark Editora,Rio de Janeiro, 1994.

18.SGS-ICS. Leader Assessor Training. Anotações do Seminário, São Paulo, 1994.

Capítulo

3 IMPLICAÇÕES DOS CONCEITOS DA QUALIDADE PARA O SOFTWARE

Talvez uma das áreas mais refratárias à implementação da qualidade seja a de informática e, em especial, as atividades relativas à gestão e ao desenvolvimento de software.

Como observado no primeirto capítulo , as práticas nas organizações evidenciam a afirmativa acima.

Isto entretanto deve ser visto como motivação e oportunidade para a melhoria dessas práticas, objetivando a produção de software de qualidade.

Este capítulo tem como finalidade discutir a interpretação dos conceitos da qualidade para a área de software.

3.1 - O Paradigma da Qualidade do Software Para a definição do que seja qualidade do software é necessário entendermos os fatores críticos que podem ser subdivididos em fatores explícitos e implícitos da qualidade.

Os fatores explícitos normalmente são externados pelo cliente. Lembre-se de quem define a qualidade é o cliente. Esses fatores consistem nas expectativas do cliente.

Abrangem fatores relativos à qualidade do projeto/processo , qualidade do produto final e do atendimento quanto à manutenções corretivas, adaptativas e introdução de melhorias no produto.• Os fatores implícitos dizem respeito aos fatores de qualidade do software, que são percebidos pelos desenvolvedores ( não pelos clientes) e que constituem em elementos para atender aos fatores explícitos e principalmente para atender a produção econômica do software.

Os fatores explícitos e implícitos são:

•

Geralmente a literatura enfatiza fatores da qualidade relativos exclusivamente ao produto de software; aqui expandiremos esta noção para englobar a qualidade do projeto e do atendimento durante a vida útil do produto.

Fatores Explícitos Tabela 3-1

Fatores Prazo do Projeto Informações s/progresso

Atendimento funcional Confiabilidade Integridade Usabilidade Retorno s/ o investimento Tempos de atendimento

Descrição Prazo desejado pelo cliente ou estabelecido em termos contratuais Informações sobre o progresso do projeto disponibilizadas para o cliente, sua periodicidade; pode ser estabelecido também em termos contratuais Extensão na qual o sistema satisfaz suas especificações e atinge os objetivos do usuário Extensão na qual o sistema desempenha suas funções requeridas com precisão Extensão na qual o acesso ao sistema ou dados do mesmo por pessoas não autorizadas pode ser controlado Esforço requerido para aprender, operar, preparar entradas e interpretar as saídas do sistema Benefícios econômicos obtidos pelo cliente através do sistema Tempos de atendimento para manutenções/evolução no produto requeridos pelo cliente

Fatores Implícitos Tabela 3-2

Fatores Exatidão das estimativas Eficiência Manutenibilidade Testabilidade Flexibilidade Portabilidade Reusabilidade Interoperabilidade Estabilidade do software

Descrição Extensão na qual as estimativas do projeto em termos de prazo, esforço, custo e tamanho do software são atingidas Quantidade de recursos computacionais e de código requeridos pelo sistema para desempenhar uma função Esforço requerido para localizar e remover um defeito em um módulo ou programa do sistema Esforço requerido para testar um programa ou módulo para assegurar que o mesmo desempenha a função designada Esforço necessário para modificar um programa ou módulo Esforço requerido para transferir um programa ou módulo ou o sistema como um todo de uma plataforma de hardware e/ou software para outra Extensão na qual um programa pode ser usado em outras aplicações; relacionada ao empacotamento e escopo das funções que o programa desempenha Esforço requerido para interagir/integrar sistemas entre si Extensão na qual os fatores acima são mantidos ao longo da vida útil do produto de software

Adicionalmente aos fatores da qualidade, há os atributos do software os quais determinam esses fatores.

Os atributos do software são:

Tabela 3-3

Atributos Exatidão de Estimativas de Prazo Exatidão de Estimativas de Esforço Exatidão de Estimativas de Custo Exatidão de Estimativa de Tamanho do Software Exatidão da Estimativa de Esforço de Retrabalho Rastreabilidade

Completeza Consistência Exatidão Tolerância a Erros Simplicidade Modularidade Generalidade Expansibilidade

Instrumentação Auto-Descritividade Eficiência da Execução Eficiência de Armazenamento Controle de Acesso Auditoria de Acesso Operabilidade Treinamento

Descrição Atributode gestão do projeto, pelo qual o prazo estimado é cumprido ou não, e em que extensão os prazos são atingidos Atributo de gestão do projeto, pelo qual o esforço estimado é atingido ou não, e em que extensão é atingido Atributo de gestão do projeto, pelo qual o custo estimado é atingido ou não, e em que extensão é atingido Atributo de gestão do projeto, pelo qual a estimativa de tamanho do software é atingida ou não, e em que extensão é atingida Atributo de gestão do projeto, pelo qual a estimativa de esforço de retrabalho é atingida ou não, e em que extensão é atingida Aqueles atributos do software que proporcionam a rastreabilidade dos componentes desde os requisitos até a implementação, considerando especificações (documentos de projeto) , código fonte e executável Aqueles atributos do software que proporcionam a completa implementação das funções requeridas Aqueles atributos do software que proporcionam uniformidade nas técnicas de projeto e implementação empregadas Aqueles atributos do software que proporcionam a precisão requerida em cálculos e geração de saídas Aqueles atributos do software que proporcionam continuidade da operação sob condições anormais Aqueles atributos do software que proporcionam a implementação de funções da forma mais fácil e compreensível Aqueles atributos do software que proporcionam uma estrutura de módulos altamente independentes Aqueles atributos do software que proporcionam certo grau de abrangência das funções desempenhadas Aqueles atributos do software que proporcionam a expansão dos requisitos do armazenamento de dados ou de funções computacionais Aqueles atributos do software que proporcionam a mensuração de utilização ou da identificação de erros Aqueles atributos do software que proporcionam explanação da implementação de uma função Aqueles atributos do software que proporcionam a redução do tempo de processamento Aqueles atributos do software que proporcionam a minimização dos requisitos de memória durante a operação Aqueles atributos do software que proporcionam o controle de acesso ao software e aos dados Aqueles atributos do software que proporcionam a auditoria do acesso ao software e aos dados Aqueles atributos do software que possibilitam a sua operação Aqueles atributos do software que possibilitam a assimilação das funções pelos usuários a partir da operação e familiarização inicial

Tabela 3-3 (Continuação)

Atributos Comunicabilidade Independência de Software Independência de Máquina Comunicação Padrões de Dados Concisão Redução do Custo do Processo Aumento da lucratividade Aumento da Participação do Mercado Manutenção de Clientes Atuais

Descrição Aqueles atributos do software que possibilitam interfaces de entradas e saídas Aqueles atributos do software que determinam sua dependência ao ambiente de software ( sistema operacional,utilitários etc.)

Aqueles atributos do software que determinam sua dependência em relação ao hardware Aqueles atributos do software que proporcionam a utilização de protocolos padrões e rotinas de interfaces Aqueles atributos do software que proporcionam a utilização de representações padrões de dados Aqueles atributos do software que proporcionam a implementação de uma função com uma quantidade mínima de código Atributos do software que possibilitam a redução do custo de um processo de negócio do cliente Atributos do software que possibilitam o aumento da lucratividade do negócio do cliente Atributos do software que possibilitam ao negócio do cliente o aumento de participação no mercado Atributos do software que possibilitam a manutenção dos clientes atuais

As Tabelas 3-4 e 3-5 a seguir, caracterizam respectivamente, os fatores explícitos e implícitos, conforme as dimensões projeto,produto e atendimento, e o seu relacionamento com os atributos do software.

Tabela 3-4

Fatores Projeto Explícitos Prazo do projeto Informações s/progresso Exatidão das estimativas Atendimento funcional Confiabilidade Eficiência Integridade Usabilidade Manutenibilidade Testabilidade Flexibilidade Portabilidade Reusabilidade Interoperabilidade Retorno s/investimento Tempos de atendimento Estabilidade do sw

Dimensões da Qualidade Produto

Implícitos

Explícitos

Implícitos

Atendimento Explícitos

Implícitos

Tabela 3-5

Fatores da Qualidade Exatidão das estimativas

Atendimento funcional

Confiabilidade

Eficiência

Integridade Usabilidade

Manutenibilidade

Flexibilidade

Testabilidade

Portabilidade

Resusabilidade

Interoperabilidade

Retorno s/ investimento

Estabilidade do software

Atributos do Projeto e Produto Exatidão da estimativa de prazo Exatidão da estimativa de esforço Exatidão da estimaiva de custo Exatidão da estimativa de tamanho do software Exatidão da estimativa de esforço de retrabalho Rastrabilidade Consistência Completeza Tolerância a erros Consistência Exatidão Simplicidade Eficiência de uso de memória Eficiência de execução Controle de acesso Auditoria de acesso Operabilidade Treinamento Comunicabilidade Consistência Modularidade Generalidade Expansibilidade Simplicidade Modularidade Instrumentação Auto-Descritividade Modularidade Auto-Descritividade Independência de máquina Independência de software Generalidade Modularidade Independência de software Modularidade Comunicação Comunicabilidade Redução de custo do processo de negócio Aumento da lucratividade do negócio Aumento da participação do mercado Manutenção de clientes atuais Manutenção dos fatores da qualidade especificados, ao longo da vida útil do produto

Adaptado de William Perry 2.

Como podemos concluir, a determinação do que seja qualidade do software não é algo trivial.

Modernamente existem técnicas para auxiliar no planejamento da qualidade do software, tais como o QFD - Quality Function Deployment• (técnica desenvolvida pelos japoneses) destinada a traduzir em termos técnicos os fatores da qualidade ou requisitos explicitados pelos clientes, a fim de incorporá-los no produto e assegurar que isto aconteça.

Estes fatores e requisitos são obtidos de várias formas, através de pesquisas junto a clientes, grupos de foco e assim sucessivamente.

Em desenvolvimento de software, técnicas como JAD (Joint Application Design), servem como meios para determinar o requisitos da qualidade do ponto de vista do cliente/usuário.

Entretanto, o atingimento de níveis aceitáveis de qualidade está subordinado à medição e a comparação dos resultados com padrões já determinados pela organização.

Verificando alguns fatores da qualidade tais como manutenibilidade, testabilidade e portabilidade cuja medida básica é esforço, ou seja, alocação de homens/hora, é necessário padrões de esforço para determinar se em um projeto a meta de qualidade foi atingida.

Outra condição básica é a avaliação sistemática da satisfação do cliente/usuário com o produto logo após a sua implantação e a avaliação da satisfação durante o uso mais prolongado a fim de cotejar se os requisitos foram plenamente satisfeitos (são raríssimas organizações de informática que adotam tal procedimento).

De qualquer forma, o paradigma a resolver é que muitas vezes os requisitos dos clientes e ou usuários são conflitantes com o atingimento de metas da qualidade referentes ao projeto/processo e ao produto.

O prazo é um exemplo típico. Muito frequentemente são impostos prazos inexequíveis cuja busca de atingimento pela equipe de projeto impacta severamente os demais fatores implícitos e atributos correspondentes, principalmente aqueles relacionados com os custos da má qualidade.

Não existe, infelizmente, soluções de curto-prazo para resolver este paradigma.

Somente através de medições relativas ao projeto, processo e produto, aliado à permanente educação do cliente/usuário e dos desenvolvedores de software é que podemos resolver a questão e isto, naturalmente, requer tempo, paciência, persistência e comprometimento.

3.2 - Interpretação dos Demais Conceitos da Qualidade

•

Vide referência 1 para maiores detalhes sobre o QFD.

Neste tópico tentaremos apresentar os conceitos de controle da qualidade, garantia da qualidade, sistema da qualidade e custos da qualidade, sob a ótica do software, conforme suas dimensões correspondentes. ⌦

Controle da Qualidade do Software

Interpretando os conceitos de controle da qualidade como expostos no item 2.2, podemos considerar a seguinte definição para o software: Controle da qualidade do software envolve a utilização de técnicas e atividades para o monitoramento dos processos de gestão, desenvolvimento e manutenção/evolução do software a fim de verificar causas de variabilidade, determinar e eliminar causas de não conformidade, de modo a obter-se eficiência econômica no processo A base para implementar este conceito constitui-se na: Existência de um processo definido de gestão ( metodologia de gestão) Existência de um processo definido de desenvolvimento do software (metodologia de desenvolvimento)• Existência de um processo definido para a manutenção/evolução do software Fatores da qualidade e atributos do produto e respectivos processos já selecionados e que devem ser monitorados/controlados Tecnicamente a aplicação do conceito se dá através de: Coleta de dados sobre os eventos que caracterizam ou representam os fatores da qualidade e atributos do produto e processo Emprego de ferramentas para determinar causas de não conformidade, tais como gráfico de Pareto, diagrama de causa e efeito Emprego de métodos estatísticos, tais como gráficos de controle (controle estatístico do processo) Estes itens de aplicação serão vistos com maior profundidade nos capítulos posteriores. ⌦

Garantia da Qualidade do Software

A garantia da qualidade do software significa garantia da qualidade do processo e do produto.

Nossa definição é:

•

No capítulo 5, o conceito sobre processo de software é exaustivamente discutido.

Garantia da qualidade do software é o conjunto de atividades que tem como finalidade assegurar que a qualidade dos processos de gestão, desenvolvimento e de manutenção/evolução estão sendo desempenhadas conforme requerido, a fim de satisfazer as necessidades explícitas e implícitas do cliente/usuário com o uso do produto.

Da mesma forma que a definição anterior, a garantia da qualidade para ser exercida, também necessita de processos de gestão, desenvolvimento e manutenção/evolução do software definidos, bem como os fatores da qualidade e atributos correspondentes também definidos.

A evidência da existência destes elementos são a documentação e os objetos (componentes de software) que são gerados, numa forma sequencial e logicamente ordenada ao longo dos respectivos processos.

A obtenção desta evidência é desempenhada por atividades de: Auditoria de processo, que tem como finalidade a verificação da conformidade de especificações com os requisitos, conformidade de utilização das técnicas usadas para a contrução dos produtos, conformidade das especificações com padrões estabelecidos, conformidade dos métodos de gestão com o procedimento documentado, verificação de resultados de testes, verificação dos padrões de documentação, verificação dos procedimentos de inspeção, identificação e remoção de defeitos e assim sucessivamente Auditoria do produto, verificando conformidade do software com os requisitos do cliente/usuário, bem como o atingimento das metas e objetivos da qualidade ⌦

Sistema da Qualidade Relativo ao Software

O sistema da qualidade para o software pode ser definido como: Uma estrutura de trabalho, documentada, usada por toda a área de desenvolvimento e gestão do software, que tem como finalidade a especificação dos requisitos para que seja demonstrada a capacidade de controlar os processos de gestão, desenvolvimento e manutenção/evolução, bem como prevenir, detectar, remover não-conformidades e eliminar suas reincidências nos processos.

Como vimos no capítulo 2, a série 9000 e os Prêmios Nacionais da Qualidade são modelos de Sistemas da Qualidade.

Para a área de software, há os modelos ISO 9000-3, que é a 9001 para software, e SEI (Software Engineering Institute - Carnegie Mellon University)• .

•

Ambos modelos são discutidos no capítulo 11.

Com base na ISO, um modelo de sistema da qualidade (SQ) para software deve conter, de forma documentada: Políticas e objetivos da qualidade Definição das responsabilidades sobre as atividades da qualidade Procedimentos de revisão gerencial do SQ Procedimentos de auditorias do sistema da qualidade Procedimentos de ações corretivas Procedimentos para análise crítica de contrato Procedimentos para o planejamento do desenvolvimento do software Procedimentos para o planejamento da qualidade do software Procedimentos para projeto e implementação do software Procedimentos para teste e validação do software Procedimentos para aceitação do software Procedimentos para replicação, entrega e instalação do software Procedimentos de manutenção do software Procedimentos para a gerência de versões do software Procedimentos para o controle da documentação Procedimentos quanto aos registros da qualidade Procedimentos quanto à medição do produto e processo Procedimentos quanto à aquisição Procedimentos quanto a treinamento ⌦

Custos da Qualidade em Software

Considerando a classificação dos custos da qualidade explanados anteriormente, podemos identificar os custos relativos a software como: Custos de Prevenção Treinamento Ferramentas Métodos Padrões, políticas e procedimentos Consultoria externa Planejamento do desenvolvimento Planejamento da qualidade Reuniões de equipe para prevenção Prototipação rápida de sistemas Coleta de dados e análise de resultados de medições Análise de causas de problemas Garantia da qualidade Custos de Avaliação Revisão das especificações dos requisitos Revisão das especificações de projeto Revisão das especificações de componentes e módulos Revisão e inspeção de código

Processo de teste, incluindo teste de unidade, teste do sistema, teste do produto, verificação e validação independente Beta teste, teste em paralelo Auditorias dos produtos Custos de Falhas Internas Identificação de defeitos pré-release Remoção de defeitos pré-release Reinspeção de especificações Reinspeção de produto Reinspeção de código Realização de testes adicionais Utilização de recursos computacionais para testes adicionais Custo de Falhas Externas Identificação de defeitos pós-release Remoção de defeitos pós-release Reinspeção de manutenções Atendimento de campo para remover defeitos Esperamos que o leitor tenha compreendido, em linhas gerais, o significado da qualidade para a área de software.

Com esta compreensão estamos preparados para o detalhamento da medição dos processos de gestão do projeto, desenvolvimento e manutenção/evolução do software, visando o atingimento de objetivos da qualidade.

REFERÊNCIAS 1. GUINTA,L.R. & PRAIZLER,N.C. The QFD Book, the team approach to solving problems and satisfying customers through quality function deployment.

AMACON Books, New York,1992.

2.PERRY, William E. Effective Methos of EDP Quality Assurance. In: Handbook of Software Quality Assurance. Editor’s: G. Gordon Shulmeyer ans James I. McManus, 2nd edition, Van Nostrand Reinhold,New York ,1992.

Capítulo

4 CLASSIFICAÇÃO E MECANISMO DAS MEDIÇÕES EM SOFTWARE Como vimos anteriormente, a Gestão de Projetos e de Produtos de software somente atingem um determinado nível de eficácia e exatidão se houverem Medidas que possibilitem gerenciar através de fatos, e o que é mais importante, gerenciar os aspectos econômicos do software, que geralmente são negligenciados em organizações de desenvolvimento.

Medidas, na disciplina de Engenharia de Software, são denominadas de Métricas, as quais podem ser definidas como métodos de determinar,quantitativamente, a extensão na qual o projeto, processo e produto de software têm certos atributos.Isto inclue a fórmula para determinar o valor da métrica como também a sua forma de apresentação, as diretrizes de utilização e interpretação dos resultados obtidos no contexto do ambiente de desenvolvimento de software.1 Um dos aspectos que deve ser observado quando da implementação de iniciativas de utilização de métricas é quanto a sua utilidade no contexto de um projeto ou do ambiente como um todo além, naturalmente, dos tipos e categorias de métricas,usuários das métricas, audiências (destinatários dos resultados) e os seus níveis de aplicação.

Há várias características importantes que estão associadas com o emprego das métricas de software. A sua escolha, para fins de gerenciar através de fatos e dados, requer alguns pré-requesitos importantes, quais sejam: ⌦

Os objetivos que se pretende atingir com a utilização das métricas Em uma organização que se dedica ao desenvolvimento de software,considerando tanto como atividade fim como de suporte a uma empresa, há vários objetivos que se buscam atingir, dependendo obviamente do estágio de maturidade que se encontra essas atividades.

Alguns dos objetivos perseguidos geralmente se enquadram na seguinte relação: a) Melhorar a qualidade do planejamento do projeto; b) Melhorar a qualidade do processo de desenvolvimento; c) Melhorar a qualidade do produto resultante do processo; d) Aumentar a satisfação dos usuários e clientes do software; e) Reduzir os custos de retrabalho no processo; f) Reduzir os custos de falhas externas; g) Aumentar a produtividade do desenvolvimento; h) Aperfeiçoar continuamente os métodos de gestão do projeto; I) Aperfeiçoar continuamente o processo e produto; j) Avaliar o impacto de atributos no processo de desenvolvimento tais como novas ferramentas;

k) Determinar tendências relativas a certos atributos do processo. ⌦

As métricas devem ser simples de entender Devido as diversas audiências (destinatários dos produtos das medições), as métricas devem ser simples de entender e de serem utilizadas para verificar atingimento de objetivos e para subsidiar processos de tomada de decisão.

⌦

As métricas devem ser objetivas As métricas devem ser objetivas visando reduzir ou minimizar a influência do julgamento pessoal na coleta,cálculo e análise dos resultados.

⌦

Efetivas no custo O valor da informação obtido como resultado das medições deve exceder o custo de coletar,armazenar e calcular as métricas. A efetividade no custo deve ser analisada em função do estágio de maturidade do ambiente de desenvolvimento que se encontra a empresa no contexto de uma estratégia de melhoria contínua.

⌦

Informativas As métricas selecionadas devem propiciar informação que possibilite avaliar acertos ( ou não) de decisões e ações realizadas no passado, evidenciar a ocorrência de eventos presentes que subsidiem decisões tempestivas, bem como prever a possibilidade de ocorrência de eventos futuros.

4.1 - Classificação das Medições As métricas de software podem ser classificadas sob diferentes formas,considerando o tipo de dado a ser coletado e os objetivos e nível de utilização das mesmas. ⌦

Classificação Conforme o Tipo de Medidas

Sob este prisma, podemos considerar as seguintes classificações  2  : Objetiva/Subjetiva Distingue as medições que contam coisas e aquelas que envolvem o julgamento humano.

Absoluta/Relativa Medidas absolutas não variam com a adição de novos itens. O tamanho do software, por exemplo, é uma medida absoluta pois é independente do tamanho dos demais. Medidas relativas mudam como médias de valores de eventos. Medidas objetivas geralmente são absolutas, enquanto as subjetivas tendem a ser relativas.

Explícitas/Derivadas Medidas explícitas são obtidas diretamente, enquanto as derivadas através de outras medidas explícitas ou derivadas. Por exemplo, homens/mês de esforço despendidos em uma atividade é uma medida explícita, enquanto produtividade do desenvolvimento em Pontos de Função por homem/mês é derivada.

Dinâmica/Estática Medidas dinâmicas têm um componente temporal, tal como defeitos encontrados por mês, ou tendência da produtividade do desenvolvimento.

Neste caso os valores mudam ao longo do tempo, dependendo de quando é feita a coleta de dados. Medidas estáticas, entretanto, permanecem inalteradas, tal como o esforço total despendido durante o desenvolvimento.

Preditivas/Explanatórias Medidas preditivas consistem em estimativas geradas a partir de transformações de medidas explícitas/derivadas ou dinâmicas/estáticas. As estimativas geralmente são obtidas através de transformações com o uso de métodos quantitativos. As medidas explanatórias são produzidas após a ocorrência do evento. Estas medidas geralmente vão alimentar um banco de dados de métricas para a gerência do ambiente de desenvolvimento. ⌦

Conforme o Objetivo da Medição

As métricas podem servir à Gestão Estratégica, Tática e Operacional no que concerne ao ativo software da empresa.

As medições estratégicas devem possibilitar a realização de: “benchmarking” , isto é, comparar-se com outras empresas, competidoras ou não; melhorias contínuas, na filosofia de Kaizen, no tocante à qualidade de seus métodos de planejamento de projetos, gestão do processo de desenvolvimento e gestão do produto e a avaliação econômica do ativo software.

As medições táticas dizem respeito à gestão do ambiente de software em termos do impacto da introdução de novas ferramentas, mudanças no processo de desenvolvimento, treinamento de pessoal, análise de tendências da produtividade e assim sucessivamente. Elas são derivadas a partir da agregação das medições de cada projeto ou produto tomados individualmente.

As medições operacionais, por sua vez, ocorrem a nível de cada projeto ou produto de software, visando subsidiar o planejamento de projetos, a gestão do processo de desenvolvimento, o planejamento do atendimento ao produto de software e à própria gestão do produto.

MEDIÇÕES ESTRATÉGICAS BENCHMARKING

MELHORIA CONTÍNUA

AVALIAÇÃO ECONÔMICA

MEDIÇÕES TÁTICAS ANÁLISE DE TENDÊNCIAS

ANÁLISE DE IMPACTOS

ANÁLISE DE ATRIBUTOS

MEDIÇÕES OPERACIONAIS GESTÃO DO PROJETO PROCESSO MÉTRICAS DE PROJETO

GESTÃO DO PRODUTO MÉTRICAS DO PRODUTO

Figura 4-1 Classificação das Medições Em Software

Tanto as medições operacionais, táticas e estratégicas, fornecem os indicadores para que os atributos Qualidade e Produtividade sejam determinados, comparados e assim sucessivamente.

4.2 - O Mecanismo da Medição em Software ⌦

Medições Operacionais

Alguns aspectos importantes na aplicação das medições, geralmente tratados de forma obscura pela literatura técnica, é quanto a determinação de: Quais as medições que devem ser realizadas no processo de planejamento de um projeto específico Quais as medições realizadas no processo de planejamento de um projeto específico que vão subsidiar a gestão do processo de desenvolvimento e do produto correspondente Quais as medições que devem ser realizadas no processo de desenvolvimento de um software específico que irão realimentar a gestão do próprio processo Quais as medições no processo de desenvolvimento de um software específico que irão subsidiar a gestão do produto correspondente Quais as medições que devem ser realizadas no planejamento da gestão do produto

Quais as medições que devem ser realizadas durante manutenção/evolução do produto para subsidiar a própria gestão do produto

a

Quais as medições que devem ser realizadas no processo de desenvolvimento de um software específico para subsidiar o aperfeiçoamento do modelo de processo de software e a metodologia de planejamento de projetos da empresa Quais as medições que devem ser realizadas no processo de gestão do produto de um software específico para subsidiar o aperfeiçoamento do modelo de processo de software e na metodologia de planejamento de projetos da empresa

PROJETO ESPECÍFICO

PLANEJAMENTO DO PROJETO

MODELO DE PROCESSO DE PLANEJAMENTO DE PROJETOS

PROCESSO DE DESENVOLVIMENTO DO SOFTWARE

MODELO DE PROCESSO DE DESEN VOLVIMENTO DE SOFTWARE

GESTÃO DO PRODUTO

MODELO DE PROCESSO DE GESTÃO DE PRODUTO

MODELOS GENÉRICOS NÍVEL EMPRESA

Figura 4-2 Mecanismo da Medição

Este modelo que denominamos de mecanismo da medição focaliza sobre os momentos em que as medições devem ser realizadas e em que momento devem ser utilizadas.

A seguir relacionamos as principais medições que ocorrem em cada etapa do ciclo de vida do software.

Medições Realizadas no Planejamento de Projetos

No processo de planejamento, a maioria das medidas é de natureza preditiva, já que concentra-se em estimativas. Entretanto o planejamento também faz uso de medidas explanatórias visto que as mesmas compõem os padrões da instalação quanto a determinados atributos do processo de desenvolvimento e de gestão do produto.

Ambos tipos de medidas servirão para que o processo de desenvolvimento e de gestão do produto possam ser controlados, ou seja, comparando-se os atributos dos respectivos processos com os padrões a fim de verificar desvios e tomar ações corretivas.

Medições Realizadas Para o Processo de Desenvolvimento Estas medições são as estimativas realizadas no processo de planejamento que vão subsidiar a gestão do processo de desenvolvimento do software. As principais são: Estimativa do Tamanho do Software Estimativa do Prazo do Projeto Estimativa do Esforço do Projeto Custo Estimado Para o Projeto Estimativa do Número de Instruções Fontes Estimativa da Distribuição de Esforço Por Fase do Projeto Estimativa da Distribuição do Prazo Por Fase do Projeto Estimativa do Número de Defeitos Pré-Release Estimativa do Número de Defeitos Pós-Release Estimativa do Esforço de Retrabalho Estimativa do Custo de Retrabalho Estimativa do Número de Profissionais a Serem Alocados ao Projeto Estimativa do Número de Profissionais Por Fase do Projeto Medição Realizada Para o Processo de Gestão do Produto Esta medição é utilizada quando do planejamento do atendimento do produto do software. Porém este dado pode mudar visto o comportamento do processo de desenvolvimento.

Número de defeitos pós-release previstos Medições Utilizadas Pelo Planejamento - Padrões da Instalação Estas medições são de natureza essencialmente explanatórias pois explicam o comportamento do processo de desenvolvimento e de gestão do produto da instalação e se constituem nos padrões, sobre os quais o controle é exercido.

Os padrões compõem a “base de dados” de métricas, os quais devem estar associados com o tipo do processo de desenvolvimento e com o produto específico e muitas vezes com a área de aplicação do software em virtude da volatilidade do negócio atendido pelo mesmo.

Por exemplo, não podemos misturar padrões do processo de software caracterizado por “maniframe”, DB2, CICS e CSP e metodologia estruturada, com o processo caracterizado como rede local , Windows NT, Visual Basic , SQL-Server e metodologia orientada a objeto. Para cada tipo de processo deve haver um “data set” específico de métricas.

Somente alguns padrões de medições podem ser utilizados independente do tipo do processo, como por exemplo, padrões relativos ao processo de inspeção formal de software, que abrange taxas de inspeção, tempos médios de preparação para inspeção etc.

Em relação ao produto de software em si, os padrões são específicos ao software, ou seja, devemos manter um “data set” para cada produto. É com base nestes padrões é que o processo de gestão do produto pode ser realizado.

Os principais padrões que devem ser mantidos são: Exatidão da estimativa de prazo Exatidão da estimativa de tamanho Exatidão da estimativa de custo Exatidão da estimativa de esforço Exatidão da estimativa de defeitos pré-release Exatidão da estimativa de defeitos pós-release Exatidão da estimativa de esforço de retrabalho Exatidão da estimativa de custo de retrabalho Exatidão da estimativa de instruções fontes Exatidão da estimativa de número de profissionais Distribuição do esforço por fase Distribuição do custo por fase Distribuição dos defeitos por fase Distribuição dos defeitos por tipo Origem dos defeitos Produtividade média do desenvolvimento Custo médio do ponto de função de desenvolvimento Crescimento funcional médio do software Taxa de inspeção Tempo médio de preparação da inspeção Densidade média de defeitos Eficiência na remoção de defeitos Média de reutilização de código Complexidade do projeto do software Índice de tecnologia de desenvolvimento do ambiente Índice de tecnologia de gestão do ambiente Intensidade de falhas Custo médio do ponto de função de manutenção corretiva Custo médio do ponto de função de manutenção adaptativa Custo médio do ponto de função de projetos de melhoria Índice de manutenção no software Densidade média de defeitos Crescimento funcional do software após a release Produtividade média de manutenções corretivas Produtividade média de manutenções adaptativas Produtividade média de projetos de melhoria Exatidão da estimativa de esforço de atendimento Exatidão da estimativa de custo de atendimento Medições Realizadas No Processo de Desenvolvimento As medições realizadas durante o processo de desenvolvimento do software têm vários propósitos , ou seja, para a própria gestão do processo, para o planejamento do

processo de gestão do produto, para o aperfeiçoamento dos modelos de processo de planejamento, de desenvolvimento e de gestão do produto utilizados pela instalação.

Quanto ao aperfeiçoamento dos modelos, as medições realizadas durante o desenvolvimento vão suprir o nível tático de medição.

Aqui se misturam vários tipos de medição. Temos medições explícitas, derivadas, dinâmicas, estáticas, algumas poucas preditivas e a geração de medidas explanatórias que irão alimentar o banco de dados de métricas. Na realidade todas as medidas, após o término do desenvolvimento do software, tornam-se explanatórias.

Medições Para a Gestão do Próprio Processo de Desenvolvimento As medições realizadas para a gestão do próprio processo de desenvolvimento têm como propósito possibilitar a gestão de várias facetas do projeto, ou seja, a gestão da qualidade do produto que está sendo desenvolvido, a gestão do progresso do projeto, a gestão financeira do projeto e a gestão de mudanças.

A seguir estão relacionadas as principais medições que devem ser realizadas.

Progresso na remoção de defeitos Defeitos restantes Desvio da estimativa de defeitos Composição dos tipos de defeitos na fase Composição de defeitos até a fase Composição das classes de defeitos Distribuição de defeitos por módulo do software Densidade de defeitos da inspeção Densidade de defeitos na fase Densidade de defeitos por módulo do software Eficiência da remoção de defeitos do processo de inspeção Taxa de exame por inspeções Taxa de preparação por inspeção Tamanho do material inspecionado por inspeções Complexidade do módulo Falhas adicionais esperadas para atingir o objetivo de intensidade Tempo de execução adicional esperado para atingir o objetivo de intensidade Progresso na elaboração de produtos Acompanhamento físico do projeto Estimativa atualizada do tamanho do software Estimativa atualizada de prazo Exatidão da estimativa de prazo da fase Estimativa atualizada de esforço Estimativa atualizada de alocação de recursos Exatidão da estimativa de esforço da fase Acompanhamento financeiro do projeto Estimativa atualizada do custo do projeto Comportamento do custo do retrabalho Monitoramento de mudanças nos requisitos Origens de incremento/mudanças nos requisitos Medições Realizadas Para a Gestão do Produto

São medições de natureza eminentemente preditivas, a fim de auxiliar o planejamento da gestão do produto.

Falhas esperadas para o software Intensidade atual de falhas Estimativa atualizada do número de defeitos pór-release Medições Realizadas Para o Aperfeiçoamento dos Modelos de Planejamento de Projetos e do Processo de Desenvolvimento São medições de natureza explanatórias que irão alimentar o banco de dados de métricas da instalação a fim de subsidiar o planejamento e gestão de novos projetos, conforme a lista apresentada anteriormente.

Estas medições também dão subsídio ao gerenciamento tático do ambiente de software como um todo, indicando, principalmente, tendências e possibilitando a análise de atributos do processo.

Verificação da exatidão das estimativas Tamanho do software entregue Produtividade do desenvolvimento Custo do ponto de função do desenvolvimento Crescimento funcional do software durante o desenvolvimento Reutilização do código Complexidade do software Custo da qualidade Distribuição do esforço por fase Distribuição dos defeitos por fase Densidade de defeitos do software Índice de tecnologia do desenvolvimento empregado Índice de tecnologia de gestão empregado Outras medições qualitativas Medições Realizadas No Processo de Gestão do Produto O processo de gestão do produto ou da release do software pode ser subdividido em dois subprocessos, quais sejam: planejamento do atendimento e atendimento.

Este é representado pelas manutenções corretivas, adaptativas e projetos de melhoria do software.

O planejamento do atendimento ainda pode ser subdividido em planejamento anual e planejamento de atendimento específico, ou seja, a uma determinada solicitação de manutenção ou melhoria.

Similarmente aos outros momentos de medição, as medições realizadas na gestão do produto alimentam o próprio processo , assim como subsidiam o aperfeiçoamento dos modelos de planejamento de projetos e desenvolvimento do software.

Aqui também são encontradas medições de natureza explícita, derivada, dinâmica,estática, preditiva e explanatória.

A diferença em relação ao processo de desenvolvimento é que o aspecto temporal é fundamental neste caso, visto que o objetivo principal é melhorar continuamente o software durante a sua vida útil.

Medições Para o Próprio Processo de Gestão As medições aqui são realizadas durante o planejamento do atendimento e durante o atendimento específico.

Estimativa do esforço de atendimento anual Estimativa do número de profissionais para o atendimento anual Estimativa do custo de atendimento anual Estimativa dos defeitos do atendimento anual Esforço esperado de retrabalho Custo esperado do retrabalho do atendimento Modelos probabilísticos para atendimento a manutenções corretivas Estimativa do esforço de manutenções adaptativas Estimativa do prazo de manutenções adaptativas Estimativa do número de profissionais para a manutenção adaptativa Estimativa do custo da manutenção adaptativa Estimativa do número de defeitos da manutenção adaptativa Estimativa do esforço de retrabalho da manutenção adaptativa Estimativa do custo de retrabalho da manutenção adaptativa Estimativa do tamanho do projeto de melhoria Estimativa de esforço do projeto de melhoria Estimativa de prazo do projeto de melhoria Estimativa do número de profissionais para projetos de melhoria Estimativa de defeitos do projeto de melhoria Estimativa de esforço de retrabalho no projeto de melhoria Estimativa de custo de retrabalho no projeto de melhoria Monitoramento do “backlog” Tempo médio de atendimento às solicitações Tempo médio do “backlog”em aberto Origem das solicitações Frequência do tipo de solicitação Frequência de solicitações por módulo do software Produtividade da manutenção corretiva Monitoramento da densidade de defeitos do produto Monitoramento da intensidade de falhas do produto Índice de manutenção do produto Produtividade de manutenções adaptativas e projetos de melhoria Custo do ponto de função de manutenção adaptativa e projetos de melhoria Medições Realizadas Para o Aperfeiçoamento dos Modelos de Planejamento , do Processo de Desenvolvimento e Gestão do Produto Eficiência da remoção de defeitos do processo de desenvolvimento Verificação da exatidão das estimativas Tamanho atual do software Crescimento funcional relativo do software Crescimento funcional médio anual do software Complexidade atual do software Custo da qualidade Índice de tecnologia de manutenção/melhoria empregado Índice de tecnologia de gestão empregado

Demais medições qualitativas ⌦

Medições Táticas

O objetivo das medições táticas é o de auxiliar a gestão do ambiente de software como um todo.

Para tanto, as informações armazenadas no banco de dados de métricas são transformadas para verificar tendências, analisar impactos e analisar atributos.

Análise de Tendências A análise de tendências tenta prever o comportamento futuro dos valores de determinados indicadores.

Geralmente utiliza-se de técnicas estatísticas de previsão para realizar a análise de tendências, tais como regressão linear e análise de séries temporais.

As principais possibilidades de medição são: Tendência da produtividade do desenvolvimento por tipo de processo Tendência da produtividade da manutenção corretiva Tendência da produtividade da manutenção adaptativa Tendência da produtividade de projetos de melhorias Tendência da densidade de defeitos de software Tendência da exatidão das estimativas relativas a projeto Tendência do custo do ponto de função de projetos de desenvolvimento Tendência do custo do ponto de função de manutenção corretiva Tendência do custo do ponto de função de manutenção adaptativa Tendência do custo do ponto de função de projetos de melhoria Tendência da exatidão de estimativas relativas à gestão do produto Tendência do crescimento funcional de um software específico Tendência dos defeitos pré-release por tipo de processo Tendência dos defeitos pós-release por tipo de processo Tendência da distribuição do esforço por fase do projeto Tendência da distribuição de defeitos por fase Análise de Impactos Neste caso procuramos avaliar o impacto sobre a qualidade e produtividade em função de determinados eventos, tais como a introdução de uma nova tecnologia de desenvolvimento e gestão e assim por diante.

Na realidade, a análise de impacto é feita comparando-se os resultados das medições antes e depois da introdução da novidade.

Impacto da introdução de CASE Impacto da introdução de nova metodologia de desenvolvimento Impacto da introdução de nova metodologia de gestão Impacto da introdução de inspeção formal de software Impacto da introdução de nova ferramenta de desenvolvimento Impacto do aumento do “skill” do pessoal de desenvolvimento

Análise de Atributos O objetivo da análise de atributos é a comparação das medidas entre plataformas de desenvolvimento.

Esta análise de atributos dá “insights” valiosos para determinação de causas e fatores que levam a melhor qualidade e produtividade de uma plataforma sobre outra, bem como avaliar a eficácia dos métodos.

Análise de produtividade entre plataformas de desenvolvimento Análise de produtividade conforme métodos de desenvolvimento Análise de densidade de defeitos por processo de desenvolvimento Análise de custos por plataforma e processo de desenvolvimento ⌦

Medições Estratégicas

As medições estratégicas, por sua vez, são obtidas a partir de agregações das medições operacionais e táticas e visam subsidiar processos de “benchmarking” , a melhoria contínua do processo de gestão do ambiente de software e a realização de avaliações financeiras sobre o acervo de software da organização, inclusive a nível de análise de retorno do investimento.

Benchmarking da produtividade do desenvolvimento Benchmarking da densidade de defeitos Benchmarking dos custos de desenvolvimento Nível de satistação dos clientes/usuários Melhoria da qualidade do software Melhoria da produtividade do desenvolvimento Acervo de software da empresa em pontos de função Acervo de software em pontos de função por área da empresa Custos médios de desenvolvimento Valor do acervo de software Retorno sobre o investimento Crescimento do “market share” da empresa Redução de custos de processos empresariais Antes de detalharmos cada tipo de medição é necessário discutirmos a importância do processo de software . Este processo é condição “si ne qua non” para efetivar um Programa de Métricas dentro da organização.

REFERÊNCIAS 1.DASKALANTONAKIS, Michael K. A Practical View of Software Measurement ans Implementation Experiences Within Motorola. IEEE Transactions on Software Engineering, Vol 18, no. 11, November 1992.

2.HUMPHREY, Watts .

Reading,MA,1990.

Managing

the

Software

Process.

Addison-Wesley,

Capítulo

5 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE - BASE PARA A APLICAÇÃO DAS MEDIÇÕES São três as condições técnicas básicas para se realizar medições operacionais, táticas e estratégicas, quais sejam: ➲ ➲ ➲

Um Processo de Software Definido; O Conceito de “Work-Product”; Banco de Dados de Métricas.

Estas três condições estão intimamente relacionadas visto que as medições são feitas no contexto de um Processo de Software, o qual gera produtos intermediários e final (“Work-Products”), sendo que os dados sobre essas medições vão alimentar um Banco de Dados cuja finalidade é permitir o monitoramento/aperfeiçoamento do processo, bem como realimentar e subsidiar novos projetos de software. Podemos considerar este relacionamento como um ciclo evolutivo, como nos mostra a Figura 5-1 a seguir.

PROCESSO DE SOTWARE

WP

medição

medição

WP

medição

WP

medição

WP

medição

WP

medição

BANCO DE DADOS DE MÉTRICAS Realimentação

GERENCIAMENTO/ MONITORAMENTO Figura 5-1 Ciclo de Medição

Neste capítulo nos deteremos em apresentar os conceitos associados a Processo e “Work-Products”, visando evidenciar a importância de ambos para um esforço de medição, dando base inclusive para a melhor compreensão dos temas que serão apresentados nos capítulos seguintes.

5.1 - Conceitos Básicos do Processo de Software

Como já apresentado anteriormente, o ciclo de vida do software, que podemos considerar como um modelo macro do processo , é imutável e independente de tecnologia, plataforma, finalidade e criticidade do software.

Planejamento Concepção

Projeto Desenvolvimento

Projeto

Implantação

Operação

Manutenção/Melhoria

Produto Substituição/Desativação

Figura 5-2 Ciclo de Vida do Software

Qualquer software que formos desenvolver passa, necessariamente, por estas grandes fases.

Há uma analogia bastante significativa com o ciclo de vida de produtos (físicos) industriais.

A diferença é que a produção de software é fruto de interações intelectuais entre pessoas, dificultando a definição de atividades rotineiras repetitivas, ao contrário da produção de bens industriais, que muitas vezes não requerem a intervenção humana e quando requerem, exigem baixo “skill” do pessoal , comparado com as exigências de conhecimento requeridas dos engenheiros de software.

Este fato é um dos principais fatores que concorrem para a dificuldade em padronizar o processo de software, ou no “jargão” mais conhecido, da metodologia de desenvolvimento, bem como sua aplicação efetiva nas organizações.

De acordo com Humphrey 2 , “ao desenvolvermos software, estamos tratando com um processo intelectual que deve ajustar-se dinamicamente às necessidades criativas dos profissionais e suas tarefas”.

Há portanto, um claro paradigma : “como flexibilizar o processo em função das necessidades individuais e atender os requisitos da empresa por padronização? “ Outro fator que adiciona maior complexidade é que , apesar do macro processo ser semelhante, as novas tecnologias de “hardware” , métodos e abordagens de desenvolvimento, ambiente orientado a eventos e a finalidade do software, requerem um conjunto de atividades diferenciadas, ou seja, o detalhamento do macro processo torna-se específico conforme a combinação destes fatores.

Entretanto, a padronização traz benefícios do ponto de vista da gestão do ambiente de desenvolvimento, quais sejam: ➲ ➲ ➲ ➲ ➲

Possibilita a redução de problemas de treinamento; Possibilita a melhoria contínua do processo em função da experimentação das equipes de projeto; Possibilita base para as medições selecionadas; Possibilita base para o planejamento de projetos; Possibilita base para a gestão do projeto e processo.

Ainda de acordo com Humphrey, as necessidades conflitantes de customização e padronização podem, frequentemente, serem resolvidas pelo estabelecimento de uma arquitetura do processo, a qual consiste de um conjunto de unidades ( etapas do processo) , sendo que a customização é obtida incluindo-se etapas específicas conforme as características do projeto.

Por exemplo, para qualquer projeto de software há etapas comuns, tais como Teste e Inspeção ( esta última pode ocorrer em várias fases do desenvolvimento) porém, ao desenvolvermos um projeto para plataforma “mainframe” e outro para plataforma “client-server” em GUI ( Graphical User Interface), o processo ( ou metodologia) de ambos terá componentes comuns e específicos.

Toda e qualquer organização tem, de forma intuitiva ou não, uma arquitetura de processo, ou seja, ela pode estar normatizada/manualizada ou não. O importante é que haja uma sequência pré-determinada de atividades, relacionadas entre si, que guie os desenvolvedores na produção e evolução do software.

Para fins de medição do processo isto é uma condição “sine qua non”.

Um simples roteiro metodológico, que evidencie a arquitetura e os produtos do processo já basta, dependendo é óbvio, dos objetivos que se pretende atingir com as medições.

Quanto maior o nível de detalhamento da arquitetura do processo e do processo em si, maiores são as possibilidades de aperfeiçoar a maneira de como o trabalho é feito, antecipar problemas e visualizar alternativas de prevení-los ou de resolvê-los. Isto é a essência da gestão do software.

Neste ponto é importante a definição formal de Arquitetura e Processo 2: ➲

Arquitetura do Processo de Software: é o arcabouço dentro do qual o processo de software de um projeto específico é definido

➲

Processo de Software: é o conjunto de atividades, métodos e práticas que são utilizadas na produção e evolução do software

Para compreendermos melhor estes conceitos e podermos também determinar o significado de “Work-Product” é necessário maior detalhamento.

De acordo com o modelo SEI ( Software Engineering Institute) 2• , o processo de software pode ser definido em três níveis, quais sejam: ➲

Modelo U : ou universal, que consiste nas políticas de desenvolvimento e explicita as grandes fases do processo ( do nosso ponto de vista, trata-se do segundo nível de abstração do modelo do processo, sendo o primeiro o ciclo de vida do software)

➲

Modelo W : ou modelo de trabalho que procedimentos,etapas, responsabilidades do processo

➲

Modelo A : ou modelo atômico, o qual define padrões e ferramentas de desenvolvimento, relacionadas aos procedimentos e etapas definidas no modelo W

compreende

os

A Figura 5-3 mostra a hierarquia dos modelos.

A representação do modelo U é caracterizada pela abordagem denominada “Waterfall” conforme mostra a Figura 5-4 Observe que tal abordagem é um detalhamento do modelo ciclo de vida.

CICLO DE VIDA MODELO U MODELO W MODELO A

Figura 5-3 Níveis dos Modelos do Processo de Software

•

No capítulo11 este modelo é apresentado com maior profundidade.

Viabilidade Validação Planos e requisitos Validação

Desenho do Produto Validação

Desenho Detalhado Validação

Codificação Validação

Integração Validação

Implementação Validação Figura 5-4 Modelo “Waterfall”de Desenvolvimento de Software

Para fins de gestão, o modelo “waterfall” não representa o que realmente acontece durante o desenvolvimento do software.

Já os modelos W e A , vistos de forma integrada, possibilitam especificar: ➲ ➲ ➲

O que deve ser feito ( o objetivo da tarefa) Como deve ser feito (procedimento, padrões e ferramentas) Quem deve fazer

➲ ➲ ➲ ➲ ➲ ➲ ➲

Quando deve ser feito ( qual o posicionamento da tarefa na sequência do processo) Que resultados são esperados (produtos a serem gerados) Quais as medições são apropriadas Quais os pontos chaves de controle Quais os critérios de entrada para se iniciar uma tarefa ( critérios que devem estar plenamente satisfeitos) Quais os critérios de saída de uma tarefa ( idem à observação anterior) Quais os relacionamentos entre as tarefas, para trás e para frente no processo ( “backward” e “forward” )

A implementação da arquitetura do processo depende desses dois modelos e pode ser efetivada através do que se denomina de Célula , a qual representa uma tarefa específica e é unicamente identificada.

A Figura 5-5 mostra a representação da célula.

Entrada

Tarefa OUT

Saída IN

feedback Especificações: Entrada: as condições a serem atendidas antes do início da tarefa Saída : os resultados a serem produzidos e como serão embutidos no produto da tarefa Feedback In : qualquer feedback vindo de outros estágios do processo Out : qualquer feedback da tarefa para outros estágios do processo Tarefa

: o que deve ser feito, por quem, como e quando, incluindo padrões e procedimentos apropriados, bem como as responsabilidades

Medições: as medições requeridas da tarefa (atividades,recursos e tempo) produtos ( número, tamanho e qualidade ) e feedback (número, tamanho e qualidade) Figura 5-5 Célula da Arquitetura de Processo de Software

Um conjunto logicamente ordenado de células constitue a Arquitetura do Processo.

A Figura 5-6, mostra parte de uma arquitetura hipotética para a construção de um modelo essencial de sistemas.

001 Modelo Ambiental

002 Modelo Comportamental

003 Dicionarização dos Modelos

004 Especificação dos Processos

005 Inspeção

006 Derivação do Modelo Lógico de Dados

005 Inspeção

Figura 5-6 Arquitetura do Processo

A célula também permite a definição de produtos. Se tomarmos o exemplo da Figura acima, teríamos os seguintes produtos: ➯ ➯ ➯ ➯ ➯

Modelo Ambiental do Software Modelo Comportamental do Software Dicionário dos Modelos Processos Especificados Modelo Lógico Derivado

Apesar de termos colocado dois pontos de inspeção, a célula 005 poderia ocorrer entre as tarefas 001 e 002, 002 e 003, 003 e 004.

Um dos grandes problemas no gerenciamento de projetos é a prática, nada recomendável, de medir o progresso com base apenas na informação de que a tarefa foi concluída sem a evidência de um produto.

A única forma que temos de medir o progresso é através da evidência de um produto, 100% concluído, passível de inspeção, e que foi construído considerando determinadas técnicas e métodos e dentro de um padrão de apresentação.

Isto nos dá a condição básica para realizarmos as medições de prazo, esforço, custo, tamanho, defeitos e assim sucessivamente.

Sem uma arquitetura de processo definida, o desenvolvimento de software continua sendo um trabalho artesanal ao invés de um trabalho de engenharia.

A importância de considerarmos produtos é que: ➲ ➲ ➲

A conclusão 100% de um produto evidencia o prazo efetivo realizado para desenvolver a tarefa Consequentemente, evidencia o esforço e o custo da tarefa Sem produto inspecionável, é impossível realizar medições acerca de defeitos, complexidade do produto, tamanho do software

5.2 - Níveis de Medição Conforme Os Modelos de Processo De acordo com os modelos de processo, podemos determinar três níveis de medição, ou seja: ➲ ➲ ➲

A nível do Modelo Ciclo de Vida A nível do Modelo Universal A nível do Modelo W

A escolha do modelo que servirá de base para as medições dependerá, além dos fatores organizacionais normais: ➲ ➲

Dos objetivos que se quer atingir com as medições Do estágio em que se encontra o esforço de medição

Como já comentamos anteriormente, quanto maior o nível de detalhe do modelo maior será a complexidade do esforço de medição porém, maiores também serão os benefícios que poderão ser obtidos.

Para organizações que ainda não determinaram os seus modelos W’s, um bom ponto de partida pode ser o modelo Ciclo de Vida ou o modelo Universal. Isto também é válido para organizações que experimentam ambientes distintos conforme a classe/tipo de software, por exemplo, software básico, firmware, de controle de processo, de processamento de imagem, aplicativos comerciais etc.

Esta abordagem foi muito bem sucedida na HP através do relato de Grady & Caswell 1 , cuja estratégia para iniciar o esforço de medição fundamentou-se no modelo Ciclo de Vida, já que não havia modelos W’s para as diversas classes de software que a empresa desenvolvia.

O interessante a observar é que as medições de projeto e produto, consequentemente as táticas e estratégicas, já apresentadas no capítulo 3, podem ser empregadas, em sua maioria, desde o mais alto nível de abstração.

A empresa pode, com o passar do tempo, na medida em que ganha experiência, atinja estágios mais elevados de maturidade e, conforme os resultados obtidos nos níveis maiores, implementar as medições no nível mais detalhado que é o W. Neste nível é que os maiores benefícios são conseguidos, principalmente no tocante à melhoria contínua do processo.

A seguir é apresentado para os três Modelos de Processo os possíveis pontos de medição, de acordo com as métricas básicas de projeto.

O modelo W a ser apresentado trata-se de um modelo real, adaptado a partir da metodologia comercial Multimétodo desenvolvida pela Multinformática  3 .

Tabela 5-1 MODELO DE PROCESSO

FASE

ETAPA

ATIVIDADES 1

Ciclo de Vida Planejamento Concepção Projeto Desenvolvimento Implantação Manutenção/ Melhoria UNIVERSAL Viabilidade Planos e Requisitos Desenho do Produto Desenho Detalhado Codificação Integração Implementação W Estudo Preliminar

1-Elaboração do Plano de Traba-

1- Elaboração do Plano de Trabalho do Estudo Preliminar

do Estudo Preliminar 2-Levantamento

2- Levantamento Preliminar

Preliminar 3-Delimitação do

1-Definição de Objetivos

Problema

2-Delimitação do Contexto de Análise 3-Elaboração da Visão Macro 4-Modelo de Dados Preliminar 5-Elaboração do Diagnóstico

Legenda: 1- Prazo 2- Esforço 3- Custo 4- Tamanho 5- Defeitos

MEDIÇÕES 2 3 4

5

MODELO DE PROCESSO W

FASE

ETAPA

ATIVIDADES 1

Estudo

4- Elaboração

1- Definição dos Requisitos do Sis-

Preliminar

de Proposta

tema

de Solução

2- Elaboração de Alternativas

5- Elaboração

1- Definição da Estratégia de De-

do Plano de

senvolvimento

Trabalho

2- Detalhamento de Atividades

1-Elaboração

1- Elaboração do Modelo Funcional

Especificação

do Modelo Funcional 2-Elaboração

1- Elaboração do Modelo de Dados

do Modelo de Dados 3-Compatibili-

1- Compatibilização dos Modelos de

zação dos Mo-

Dados e Funcional

delos 4-Integração

1- Integração com Modelos Existen-

com Modelos

tes

Existentes 5-Elaboração

1- Elaboração do Modelo Operacio-

do Modelo de

nal

Implementa-

2- Definição de Interfaces Entre

ção

Ambientes 3- Definição dos Procedimentos de Segurança e Controle 4- Especificação da Sequência de Processamento On-Line 5- Especificação da Sequência de Processamento Batch e Manual 6- Elaboração de Modelos de Entrada e Saída

6-Revisão do

1- Revisão do Plano de Desenvolvi-

Plano de Tra-

mento

balho Projeto de Im-

1-Projeto de

2Distribuição de Responsabilidades 1- Identificação do Modelo de Dados

plementação

Armazena-

do Modelo Operacional

mento de Da-

2- Modelo Lógico de Armazena-

dos

mento 3- Identificação das Necessidades de Acesso 4- Projeto Físico de Banco de Dados

2-Revisão do

1- Revisão do Modelo Operacional

Modelo Operacional

Legenda: 1- Prazo 2- Esforço 3- Custo 4- Tamanho 5- Defeitos

MEDIÇÕES 2 3 4

5

MODELO DE

FASE

ETAPA

ATIVIDADES

MEDIÇÕES

PROCESSO W

1 Projeto da Im-

3-Projeto de

1- Elaboração do Fluxo Operacio-

plementação

Rotinas Ope-

nal das Rotinas Automatizadas

racionais

2- Projeto de Programas

4-Projeto de

1-Elaboração do Fluxo Operacio-

Rotinas Ma-

nal das Rotinas Manuais

nuais

2- Descrição das Rotinas Manuais

5-Revisão do

1- Revisão do Plano de Desenvol-

Plano de Tra-

vimento

balho 1-Implementa-

2Distribuição Responsabilidades 1- Codificação de Programas

ção de Progra-

2- Preparação do Teste do Progra-

mas

ma

Implementação

2

3

4

5

de

3- Teste do Programa 2-Liberação

1- Preparação do Teste da Unidade

da Unidade de

de Implementação

Implementa-

2- Teste da Unidade de Implemen-

ção

tação

3-Elaboração

1- Elaboração da Documentação

da Documen-

Operacional

tação Operacional Implantação

1-Planejamen-

1- Elaboração do Plano da Implan-

to Implantação

tação

da

2- Revisão dos Critérios de Homologação

2- Treinamen-

1- Treinamento

to 3- Execução

1- Execução do Sistema

do Sistema 4- Homologa-

1- Homologação da Implantação

ção da Implantação 5- Avaliação

1- Avaliação do Desenvolvimento

do Desenvolvimento

Legenda: 1- Prazo 2- Esforço 3- Custo 4- Tamanho 5- Defeitos

Para finalizar este capítulo, gostaríamos de lembrar que, independente do nível do Modelo de Processo selecionado, as medições devem ser realizadas com base em produtos 100% inspecionáveis.

REFERÊNCIAS 1. GRADY,Robert B. & CASWELL,D.L. Software Metrics: Establishing a CompanyWide Program. Prentice-Hall, Englewood Cliffs, New Jersey, 1987.

2.HUMPHREY,Watts.

Managing Reading,MA,1990.

the

Software

3.MULTINFORMÁTICA. Multimétodo, São Paulo.

Process.

Addison-Wesley,

Capítulo

6 APLICAÇÃO DAS MEDIÇÕES NO PLANEJAMENTO DO PROJETO O objetivo principal para aplicar medições no planejamento do projeto está associado aos seguintes aspectos: ➪ ➪ ➪ ➪

Estimar consistentemente o tamanho previsto do software Estimar consistentemente o esforço previsto para o projeto Estimar consistentemente o custo do projeto Estimar consistentemente outros atributos do processo, tais como número de defeitos esperados

Para tanto é necessário produzir um planejamento do projeto de qualidade, que significa realizar estimativas confiáveis e que possibilite controlar/monitorar o processo de desenvolvimento visando manter a produtividade nos níveis previstos, remover defeitos introduzidos no projeto o quanto antes no processo, reduzindo ou mesmo eliminando o esforço de retrabalho, consequentemente mantendo o orçamento sob controle.

A Figura 6-1 exemplifica o ciclo básico de gestão de projetos.

PADRÕES CONTROLE

PLANEJAMENTO

ATUAR SOBRE OS DESVIOS

DESENVOLVIMENTO

AVALIAÇÃO

REALIMENTAÇÃO

Figura 6-1 Ciclo Básico de Gestão de Projetos de Software

Esta representação mostra que o controle deve atuar tanto sobre o planejamento como o desenvolvimento. Os desvios são determinados por padrões a partir do controle que gera ações para atuar sobre os desvios observados. A avaliação, ao final do projeto, realimenta o planejamento de novos projetos e assim num círculo indefinido.

A idéia é que as medições propiciem a geração e manutenção de padrões de forma que o controle , a ação sobre os desvios e a avaliação, possam ser exercidos.

6.1 - O Processo de Planejamento de Projetos Antes de detalharmos a aplicação das medições no processo de planejamento de projetos é preciso compreendermos melhor no que consiste este processo. A Figura 6-2 apresenta o fluxo do processo.

Caracterizar a Solução

Definir o Processo de Desenvolvimento

Selecionar Perfis de Pessoal

Elaborar Estimativas

Definir Premissas de Gestão

Definir a Estrutura de Organização do Projeto

Elaborar o Cronograma

Orçar o Projeto

Elaborar o Documento de Planejamento do Projeto

Figura 6-2 O Processo de Planejamento de Projetos

Caracterizar a Solução significa definir o escopo do projeto em termos de requisitos do cliente/usuário, ou seja, requisitos funcionais e fatores da qualidade, determinar plataforma tecnológica de desenvolvimento, bem como os atributos do produto que deverão merecer atenção.

Definir o Processo de Desenvolvimento consiste em determinar o processo que apoiará o desenvolvimento da solução em termos de fases/etapas/atividades, padrões, produtos intermediários esperados, técnicas a serem utilizadas ,precedência entre as atividades etc.

Selecionar os Perfis de Pessoal consiste na determinação das habilidades técnicas e gerenciais necessárias para o projeto em função da natureza e características da solução e do processo definido.

Elaborar Estimativas consiste na elaboração de estimativas de prazo, esforço e custo do projeto, bem como a estimativa de tamanho do software. Pode-se considerar também nesta etapa a elaboração de estimativas de esforço de retrabalho, custo de retrabalho, produtividade esperada da equipe a ser alocada e assim sucessivamente.

Definir Premissas de Gestão consiste na determinação do modelo de gestão a ser adotado em termos de monitoramento do projeto, informações a serem fornecidas para o cliente/usuário acerca do progresso do projeto, estabelecimento dos pontos de controle, local de desenvolvimento, aspectos relativos à transferência de tecnologia, tratamento de não conformidades, tratamento de mudanças de escopo do projeto a

pedido do cliente/usuario durante o desenvolvimento, gerência de mudanças, avaliação de impactos de contingências sobre o projeto, metas de qualidade a serem atingidas e assim por diante. Na realidade é o estabelecimento das “regras do jogo” para a condução do projeto juntamente com o cliente/usuário.

Definir a Estrutura de Organização do Projeto consiste na definição de como o projeto será organizado em termos de coordenação, quem deverá participar da coordenação, a definição das atribuições, a indicação das funções de apoio ao projeto, tais como suporte técnico, garantia da qualidade, apoio administrativo/logístico, suporte de metodologia, suporte tecnológico, bem como a participação de técnicos do cliente/usuário.

Elaborar o Cronograma consiste no estabelecimento dos prazos para cada fase/etapa/atividade do projeto, conforme o processo de desenvolvimento definido.

Geralmente a cronogramação, estabelecimento de datas efetivas de início e término de cada fase/etapa/atividade, se dá após a instalação formal do projeto.

Orçar o Projeto consiste na elaboração do orçamento do projeto, a partir dos resultados das estimativas e da determinação quantitativa dos recursos necessários, requeridos pelo empreendimento. Em alguns casos , de acordo com regras da organização, pode-se elaborar o cronograma de desembolso do projeto , mês as mês, conforme a sua duração estimada.

Elaborar o Documento de Planejamento do Projeto• consiste na confecção do Plano de Trabalho do Projeto o qual deverá conter os objetivos do projeto, o escopo da solução que deverá ser desenvolvida, os recursos necessários, metas de qualidade se houverem, a estrutura organizacional de gestão e operação do projeto, o cronograma estimativo e o orçamento. Este documento é o ponto de partida para as discussões iniciais com o cliente/usuário e uma vez aprovado, servirá de guia para a gestão durante o desenvolvimento da solução.

O ponto crítico deste processo é a elaboração de estimativas de prazo, esforço, custo do projeto e do tamanho do software. É a principal preocupação do gerente de projetos , pois estimativas não realistas afetam seriamente a credibilidade do projeto junto ao cliente/usuário.

Veremos agora como podemos realizar estimativas baseadas em métodos formais, na infra-estrutura de infomações necessárias para apoiar o uso destes métodos e nas medições necessárias.

6.2 - Tipos e Técnicas de Estimativas Este é um tema extremamente controvertido na literatura técnica de engenharia de software.

De acordo com Fenton 3 os principais modelos de predição para software foram desenvolvidos a partir de análises no contexto de um “data set” específico. Portanto eles •

Fernandes & Kugler 4 fornecem um texto básico sobre gerência de projetos, no qual encontra-se em detalhes o processo de planejamento de projetos.

incorporam as características particulares de cada “data set” e frequentemente incluem parâmetros difíceis de serem determinados no início de um projeto, o que a princípio invalida sua utilização para a realização de estimativas quando do planejamento do projeto• .

Para utilização dos modelos de estimativas, ainda de acordo com Fenton, é necessário calibrá-los ou mesmo customizá-los conforme a realidade da organização.

A realidade da organização constitue-se em uma série histórica com as observações acerca de prazos, esforço, custo, tamanho do software e de outros atributos referentes a cada projeto.

Dessa forma o parâmetro preconizado pelo modelo de estimativa pode ser utilizado para realizar inferências.

A Figura 6-3 mostra este raciocínio.

Estimativas Para a Plataforma A

Modelos de Estimativas

Estimativas Para a Plataforma B Estimativas Para a PlataformaN

Série Histórica Plataforma A/Processo A

Série Histórica Plataforma B/Processo B

Série Histórica Plataforma N/Processo N

Por projeto: Tamanho Prazos/Esforço/ Custo/Tamanho/ Outros Atributos

Por Projeto: Tamanho Prazos/Esforço/ Custo/Tamanho/ Outros Atributos

Por Projeto: Tamanho Prazos/Esforço/ Custo/Tamanho/ Outros Atributos

PROJETOS Figura 6-3 Modelo de Data Set de Métricas

A Figura 6-3 mostra que, a partir da coleta de dados sobre prazos, esforço, custo efetivamente realizados pelos projetos da instalação, considerando tipo de plataforma de hardware/software e o tipo de processo de desenvolvimento, bem como a coleta de dados sobre outros atributos, tais como esforço de retrabalho, custo de retrabalho, número de defeitos pré-release etc., alimenta-se uma base de dados para manter uma série histórica.

Os parâmetros gerados pelos modelos de estimativas fazem, a partir da série histórica, inferências para determinar os valores dos itens que queremos estimar, geralmente: prazo, esforço, custo , número de profissionais em tempo integral a serem alocados e tamanho do software.

•

Observação deste autor.

Os tipos de estimativas e respectivas técnicas e modelos que podemos realizar (não limitadas ao conjunto apresentado abaixo) durante o planejamento do projeto são: Tabela 6-1 - Técnicas e Modelos Para Estimativas Tipo de Estimativa FPA Tamanho do Sistema

Metodologia 2

Prazo do Projeto

Inferência

Prazo das Fases Esforço do Projeto

e

COCOMO

Modelos Regressão Linear

Modelo Prórpio Modelo Próprio

Inferência

Esforço por Fase Custo do Projeto

Técnicas

Modelo Próprio Inferência

Custo por Fase

Modelo Próprio Modelo Próprio

Número de Defeitos

Inferência

Pré-Release Número de Defeitos

Inferência

Pós-Release Esforço de Retrabalho

Inferência

Custo do Retrabalho

Inferência

Número de Linhas de

Conversão FPA

Código

Linhas de Código

Número de Profissionais

Inferência

Modelo Próprio

6.3 - Estimativas Utilizando a Análise Por Pontos de Função - FPA O Ponto de Função mede o tamanho do software pela quantificação de sua funcionalidade externa, baseada no projeto lógico ou a partir do modelo de dados. A contagem dos Pontos de Função tem como objetivos: ➪ ➪ ➪ ➪ ➪

Medir o que o cliente/usuário requisitou e recebeu Medir independentemente da tecnologia utilizada para implementação Propiciar uma métrica de tamanho para apoiar análises de qualidade e produtividade Propiciar um veículo para estimativa de software Propiciar um fator de normalização para comparação entre software

A técnica de FPA foi desenvolvida por Albrecht em 1974 quando trabalhava na IBM e evoluída por Capers Jones e o International Function Point User’s Group IFPUG. O IFPUG considera a abordagem de Albrecht como a Metodologia #1. A Metodologia #2 em desenvolvimento pelo próprio IFPUG 5 pressupõe a medição do software a partir do Modelo de Dados preliminar, o que permite realizar a primeira medição antes mesmo de iniciar o Projeto Lógico .

6.3.1 - Estimativa do Tamanho do Software - Metodologia #1

Os procedimentos para a contagem dos Pontos de Função ( ou tamanho de um software ) de acordo com o Counting Practice Manual (Release 4.0) do IFPUG 5 são: Determinar o Tipo de Contagem O Ponto de Função pode estar associado com três tipos de contagem:(i) contagem de pontos de função de projetos de desenvolvimento;(ii) contagem de pontos de função de projetos de melhoria; e(iii) contagem de pontos de função de aplicações ( sistemas já entregues e em produção).

Identificar as Fronteiras da Contagem Uma fronteira indica os limites entre a aplicação ou projeto que está sendo medido e as aplicações externas do domínio do usuário. A fronteira determina as funções que deverão ser medidas.

Determinar os Pontos de Função Não Ajustados Os Pontos de Função Não Ajustados abrangem a funcionalidade específica requerida pelo usuário para o projeto. A funcionalidade requerida diz “o que” será( ou é ) entregue para o usuário.

Os Pontos de Função Não Ajustados compõem-se de dois tipos de função,isto é, funções de dados e transacionais como mostra a Figura 6-4 a seguir.

Funções de Dados representam a funcionalidade proporcionado ao usuário para atender seus requisitos de dados internos e externos.

Um Arquivo Lógico Interno é um grupo de dados logicamente relacionados ou informação de controle mantidos dentro das fronteiras da aplicação.

Arquivos Lógicos Internos Funções de Dados Arquivos de Interfaces Externas Pontos de Função Não Ajustados

Entradas Externas Funções Transacionais

Saídas Externas

Consultas Externas Figura 6-4 Tipos de Funções

Arquivos Lógicos Internos podem ser exemplificados por: ➪ ➪

Arquivos mestres da aplicação Tabelas criadas para atender a aplicação

➪ ➪ ➪ ➪

Dados de segurança da aplicação Dados de auditagem Mensagens de auxílio (help) Mensagens de erro

Um Arquivo de Interface Externa é um grupo de dados logicamente relacionado ou informação de controle mantida externamente às fronteiras da aplicação.

Pode ser exemplificado por: ➪ ➪ ➪

Arquivos mestres de outras aplicações Tabelas criadas para atender outras aplicações Mensagens de auxílio ou de erro criadas para atender outras aplicações

Funções Transacionais representam a funcionalidade proporcionada aos usuários para processar os dados da aplicação.

Uma Entrada Externa processa dados ou informação de controle oriundos de fora das fronteiras da aplicação.

Pode ser exemplificada por: ➪ ➪

Entrada de dados “on-line” Entrada de dados “batch”

Uma Saída Externa processa dados ou informação de controle que são enviadas para fora das fronteiras da aplicação.

Pode ser exemplificada por: ➪ ➪ ➪ ➪

Dados transferidos para outra aplicação Relatórios Relatórios “on-line” Gráficos gerados em forma de texto

Uma Consulta Externa representa uma combinação de entrada e saída quando uma entrada gerar imediatamente uma saída.

Pode ser exemplificada por: ➪ ➪ ➪

Recuperação de dados Consulta Consultas de mensagens de “help”

Portanto, para o cálculo dos Pontos de Função Não Ajustados deve-se identificar e enumerar as funções da aplicação, ou seja, determinar o número de Arquivos Lógicos Internos, Arquivos de Interface Externa, Entradas Externas, Saídas Externas e Consultas Externas.

Após essa identificação, classificar cada uma das funções conforme seu nível de complexidade, se baixa, média ou alta.

O nível de complexidade das funções de dados é determinado pelos números de tipos de elementos de dados e tipos de elementos de registro associados com os Arquivos Lógicos Internos e Arquivos de Interfaces Externas.

Tipo de Elemento de Dados (TED) é um campo único reconhecido pelo usuário, não recursivo, no Arquivo Lógico Interno ou no Arquivo de Interface Externa.

Tipo de Elemento de Registro (TER) é um subgrupo de dados, reconhecido pelo usuário, dentro de um Arquivo Lógico Interno ou Arquivo de Interface Externa.

O nível de complexidade das funções transacionais é determinado pelos números de tipos de arquivos referenciados e tipos de elementos de dados associados com as Entradas Externas, Saídas Externas e Consultas Externas.

Tipo de Arquivo Referenciado (TAR) é um arquivo lógico interno lido ou mantido por um tipo de função e/ou um arquivo de interface externa lida por uma função.

Tipo de Elemento de Dados (TED) neste caso, é um campo único reconhecido pelo usuário e tratado pelas funções transacionais.

As Tabelas 6-2,6-3,6-4 e 6-5 a seguir, apresentam complexidade das respectivas funções.

a determinação da

Tabela 6-2 - Complexidade de Arquivos Lógicos Internos e Interfaces Externas

Registros 1 TER 2 a 5 TER 6 ou mais TER

1 a 19 TED Baixa Baixa Média

Dados 20 a 50 TED Baixa Média Alta

51 ou mais TED Média Alta Alta

Dados 5 a 15 TED Baixa Média Alta

16 ou mais TED Média Alta Alta

Tabela 6-3 - Complexidade de Entradas Externas

Arquivos 0 a 1 TAR 2 TAR 3 ou mais TAR

1 a 4 TED Baixa Baixa Média

Tabela 6-4 - Complexidade de Saídas Externas

Arquivos 0 a 1 TAR 2 a 3 TAR 4 ou mais TAR

1 a 5 TED Baixa Baixa Média

Tabela 6-5 - Complexidade de Consultas Externas

Dados 6 a 19 TED Baixa Média Alta

20 ou mais TED Média Alta Alta

Arquivos Entradas 0 a 1 TAR 2 TAR 3 ou mais TAR Saídas 0 a 1 TAR 2 a 3 TAR 4 ou mais TAR

1 a 4 TED Baixa Baixa Média 1 a 5 TED Baixa Baixa Média

Dados 5 a 15 TED Baixa Média Alta 6 a 19 TED Baixa Média Alta

16 ou mais TED Média Alta Alta 20 ou mais TED Média Alta Alta

Uma vez classificadas as funções conforme sua complexidade , deve-se utilizar a tabela de transformação.

Para melhor compreensão iremos exemplificar. Suponha uma aplicação na qual identificamos: ➪ ➪ ➪ ➪ ➪

3 Entradas Externas, sendo todas as 3 de complexidade baixa 2 Saídas Externas, sendo uma com complexidade baixa e outra média 4 Arquivos Lógicos Internos, sendo 3 de complexidade baixa e um médio 3 Arquivos de Interfaces Externas, sendo 2 de complexidade baixa e um médio 5 Consultas Externas, sendo 1 de complexidade baixa, 3 médias e 1 alta

A técnica pressupõe que cada nível de complexidade de uma função tem um peso.

A tabela de transformação tem o formato a seguir.

Determinar o Valor do Fator de Ajustamento O valor do fator de ajustamento (FA) indica a funcionalidade geral proporcionada ao usuário pela aplicação.

O FA consiste de 14 características do sistema que avaliam a funcionalidade geral da aplicação. O nível de influência dessas características é dado por uma escala que varia de 0 a 5 representando: ➪ ➪ ➪ ➪ ➪ ➪

0, não está presente ou não tem influência 1, pouca influência 2, moderada influência 3, média influência 4, significante influência 5, forte influência

Essas características são: ➪ ➪

Comunicação de Dados Processamento de Dados Distribuído

➪ ➪ ➪

Desempenho Configuração Pesadamente Utilizada Taxa de Transação

Tabela 6-6 - Determinação dos Pontos de Função Não Ajustados

Função Entradas Externas

Ocorrências 3 0 0

Saídas Externas

1 1 0

Arquivos Lógicos Internos

3 1 0

Arquivos de Interfaces Externos

2 1 0

Consultas Externas

1 3 1

➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Complexidade Baixa Média Alta

Peso x3= x4= x6= Total 1 = Baixa x4= Média x5= Alta x7= Total 2 = Baixa x7= Média x 10 = Alta x 15 = Total 3 = Baixa x5= Média x7= Alta x 10 = Total 4 = Baixa x3= Média x4= Alta x6= Total 5 = Total de Pontos de Função Não Ajustados

Resultado 9 0 0

Entrada de Dados On-Line Eficiência do Usuário Final Atualização On-Line Processamento Complexo Reutilização Facilidade de Instalação Facilidade Operacional Múltiplas Instalações Facilidade de Mudança

Voltando ao nosso exemplo, suponha os seguintes níveis de influência: Tabela 6-7 - Características Gerais da Aplicação

Características Comunicação de Dados Processamento de Dados Distribuído Desempenho Configuração Pesadamente Utilizada Taxa de Transação Entrada de Dados On-Line Eficiência do Usuário Final

Nível de Influência 2 1 5 5 4 3 2

9 4 5 0 9 21 10 0 31 10 7 0 17 3 12 6 21 87

Atualização On-Line Processamento Complexo Reutilização Facilidade de Instalação Facilidade Operacional Múltiplas Instalações Facilidade de Mudança Nível de Influência Total

3 1 0 2 4 3 3 38

Utilizando o nível de influência total, podemos determinar o FA de acordo com a fórmula a seguir: 0.65 + (0.01 x NI ) = FA No nosso exemplo, o FA seria de: 0.65 + (0.01 x 38 ) = 1.03 Calcular o Ponto de Função Ajustado Esta é a etapa final do processo de contagem dos Pontos de Função, ou seja, a determinação do tamanho do software.

Para determinar os Pontos de Função é preciso multiplicar o FA pelos Pontos de Função Não Ajustados.

Assim nosso exemplo finaliza com o seguinte resultado: 1.03 x 87 = 90 ( por arredondamento) 6.3.2 - Estimativa do Tamanho do Software - Metodologia #2 Os procedimentos para a utilização da metodologia 2 são descritos a seguir.

Determinar o Tipo de Contagem Procedimento análogo ao utilizado pela metotologia# 1.

Identificar as Fronteiras da Contagem Procedimento análogo ao utilizado pela metodologia# 1.

Determinar os Pontos de Função Como observado anteriormente, a metodologia# 2 baseia-se no Modelo de Dados Preliminar. Neste caso exige-se da pessoa que fará a medição, familiaridade com as técnicas de modelagem e de processos.

As definições principais adotadas pela metodologia# 2 são: ➪Atributo: uma característica da entidade, geralmente análogos aos tipos de Elementos de Dados.

➪Entidade Associativa: uma entidade que contém atributos que descrevem uma relação “M para N” entre duas outras entidades. ➪Entidade Atributiva: uma entidade que descreve uma ou mais características de outra entidade. ➪Processo Elementar: a menor unidade de uma atividade que é representativa para o usuário final em termos do seu negócio. ➪Entidade: uma coisa fundamental, de relevância para o usuário, sobre a qual uma coleção de fatos é mantida. ➪ Sub-tipo de Entidade: a subdivisão de uma entidade. Um sub-tipo herda todos os atributos e relacionamentos da entidade pai e pode ter, adicionalmente, atributos e relacionamentos únicos. ➪ Relacionamento: uma associação entre duas entidades. Um relacionamento não tem atributos. ➪ Tipos de Elementos de Dados: são os números de atributos incluindo atributos de chave estrangeira. ➪ Tipos de Elementos de Registros: são o número de entidades, incluindo subtipos e atributos. ➪ Tipos de Arquivos Referenciados: são as entidades mantidas pela aplicação ou não que são utilizados por funções transacionais.

Considerando o modelo de dados resumido de uma aplicação de acompanhamento de projeto conforme a Figura 6-5 , podemos definir os tipos de funções de dados e de transação.

Figura 6-5 - Modelo de Dados Exemplo

Fases/ Etapas

Metodologia

Grupo de Desenvolvimento

Unidades

Projeto Solicitação

Plano de Trabalho

Estimado

Atual

Ambiente Computacional

Realizado

ARQUIVOS LÓGICOS INTERNOS Projeto Solicitação Ambiente Computacional Plano de Trabalho Fases/Etapas Metodologia

Ocorrências

Observe que a entidade Ocorrências não é considerada como um Arquivo Lógico Interno pois somente pode ser mantida através da entidade Projeto.

ARQUIVOS DE INTERFACE EXTERNA Grupo de Desenvolvimento Unidades (Supondo que são mantidas por outra aplicação)

ENTRADAS EXTERNAS Considere para cada Arquivo Lógico Interno os seguintes processos: Create Update Delete

SAÍDAS EXTERNAS Considere para cada Arquivo Lógico Interno o seguinte processo: Emissão de Relatório

CONSULTAS EXTERNAS Considere para cada Arquivo Lógico Interno o seguinte processo: Read

Neste exemplo teríamos, portanto, 8 funções de dados e 30 funções transacionais.

A determinação da complexidade de cada função, o uso da tabela de tradução, a aplicação das 14 características da aplicação e a determinação do ponto de função ajustado seguem os mesmos procedimentos da metodologia #1.

6.3.3 - Estimativa do Prazo do Projeto O emprego do Function Points para a estimativa do prazo de um projeto tem sua limitações, a não ser que a empresa se disponha a utilizar ferramentas comerciais disponíveis no mercado que objetivam a geração de estimativas dessa natureza.

Uma dessas ferramentas é o Checkpoint, desenvolvida pela SPR - Software Productivity Research 6 , a qual consiste de um sistema especialista que, a partir da informação sobre o tamanho do software em Pontos de Função e sobre atributos do

ambiente de desenvolvimento, gera uma série de estimativas, inclusive o prazo esperado para o projeto.

Na falta de um instrumento dessa natureza, o procedimento é realizar inferências sobre uma base de dados que contenha uma série histórica (observações) com informações acerca de projetos já completados em termos de: plataforma de hardware/software, processo de desenvolvimento (metodologia empregada), prazo, esforço, custo e tamanho.

A Figura 6-8 mostra um exemplo de um “data set” com uma série histórica hipotética.

Tabela 6-8 - Data Set de Métricas

Plataforma de Hardware : “mainframe” Plataforma de Software : ➪ Gerenciador de Banco de Dados : DB2 ➪ Monitor de TP : CICS ➪ Linguagem de Programação : CSP Processo : Metodologia Estruturada Projetos

Itens

A Tamanho Esforço Prazo Custo Equipe Produtividade

300 10 H/M 5 meses $ 48.000 2 30 FP/h/m

B 500 16,67 H/M 6 meses $ 80.016 3 30 FP/h/m

C 800 32 H/M 8 meses $ 153.000 4 25 FP/h/m

D 1200 60 H/M 10 meses $ 288.000 6 20 FP/h/m

O procedimento para realizar inferência, a partir do tamanho do software em Ponto de Função é o que segue.

Determinar o Ambiente de Hardware/Software de Desenvolvimento A inferência deve ser realizada para o mesmo ambiente em que será desenvolvido o software.

Determinar o Processo Que Será Utilizado Para o Desenvolvimento A inferência deve ser realizada para o mesmo processo que servirá de base para o desenvolvimento.

Determinar o Prazo do Projeto Para valores de tamanho de software diferentes aos existentes no “data set” e que estejam compreendidos entre a amplitude 300 a 1200 pode-se empregar “interpolação aritmética”. É uma forma de determinar valores “eqüidistantes” entre dois pontos na tabela. Em geral, se tivermos dois pontos numa tabela ( Xo,Yo) e (X1,Y1) e desejarmos

encontrar o valor de Y correspondente a um ponto X entre Xo e X1 , por interpolação , podemos usar a seguinte fórmula: X - Xo Y = Yo +

( Y1- Yo) X1- Xo

Supondo uma estimativa de tamanho de 600 PF’s ( que fica entre 500 e 800 PF’s do nosso “data set”) as variáveis da fórmula acima assumem os seguintes valores: Yo Y1 X Xo X1

=6 =8 = 600 = 500 = 800

Aplicando a fórmula teríamos a seguinte estimativa: Y = 6 + 600-500 x (8-6) 800 -500 Y = 6 + 2/3 x 2 = 6,6 meses 6.3.4 - Estimativa do Esforço do Projeto O esforço estimado para um projeto é medido pela alocação dos recursos humanos em termos de homem/mês ou homem/hora.

A inferência a ser realizada é similar a anterior.

Entretanto a transformação pode ser direta caso o “data set” contiver o dado sobre a produtividade média do desenvolvimento conforme a plataforma de hardware/software e respectiva metodologia ou se houver valor de Ponto de Função similar ao estimado.

A interpolação também pode ser empregada nos casos de valores de PF’s estimados, intermediários aos existentes no “data set”.

Transformação Direta Para determinar o esforço, o “data set” deve conter a Produtividade Média do Desenvolvimento em PF’s por Homem/Mês de acordo com a plataforma de hardware/software e o processo de desenvolvimento.

Exemplo de aplicação:

➪ ➪

Supondo: Produtividade Média na Plataforma “mainframe” ,DB2,CICS e CSP seja igual a 26.25 FP’s /H/m PF’s estimados sejam 500

O cálculo do esforço esperado é: Esforço = ( Tamanho Estimado do Software em PF’s ) ( Produtividade Média em FP’s/H/m ) No nosso exemplo teríamos: Esforço =

500 PF’s 26,26 FP/H/m

ou 19 H/m (por arredondamento)

Transformando em horas, considerando jornada de 168 horas/mês, teríamos em torno de 3192 homens/hora de esforço.

Transformação Por Interpolação O tratamento é o mesmo dado para determinar o prazo. Neste caso para cada projeto no “data set” deverá conter a produtividade correspondente realizada para o mesmo.

6.3.5 - Custo Estimado Para o Projeto O custo estimado para o projeto é o produto do custo do homem/mês ou homem/hora, multiplicado pelo esforço previsto sendo que, de forma simplificada o Custo = f ( Esforço).

Aqui devemos observar duas abordagens para tratar o custo do homem/mês: ➪ ➪

Custeio Direto Custeio Por Absorção Total

O custeio direto considera apenas o salário + encargos ou em termos de valores médios ou aquele que representa o recurso específico a ser empregado no projeto, de acordo com a respectiva faixa salarial.

O custeio por absorção total já é mais complexo, pois deve considerar um rateio entre diversos tipos de despesas incidentes sobre o desenvolvimento do software, tais como: recursos computacionais, equipamentos auxiliares, serviços contratados, custos administrativos, custos com materiais de consumo, custos de pessoal referente às áreas de assessoria, chefia do desenvolvimento e assim sucessivamente.

O conceito que está por trás desta abordagem é que a área de desenvolvimento “vende “ serviços de análise e programação ou funções, que são medidos pelo consumo de Homens/Mês ao projeto.

Portanto o custo do Homem/Mês no modo de absorção total é: (salários + encargos) + parcela correspondente de rateio

Para simplificar podemos considerar a relação desenvolvida por Bandeira1, cujo custo de pessoal no desenvolvimento de software representa cerca de 60 a 70% do custo total, excluindo itens de investimento que sejam necessários.

Outra forma de determinar o custo estimado do projeto é através do custo unitário para produzir um Ponto de Função.

Determinação do Custo Estimado Com Base no Esforço As três alternativas neste caso são: ➪

Por custeio direto: (salário + encargo) médio do Homem/Mês x esforço estimado

➪

Por absorção total: (salário + encargos + parcela de rateio) x esforço estimado

➪

Relação 60 a 70% considerando X o custo de pessoal e Y o custo total, então: custo total = ( X x 30) ÷ 70  + X

Determinação do Custo Pelo Custo Unitário do PF Neste caso o “data set” deverá conter o custo unitário em PF para cada projeto, conforme a plataforma e o processo de desenvolvimento.

No exemplo daTabela 6-8 , os respectivos custos unitários para os projetos A,B,C e D seriam: $160,03 - $ 160,00 - $ 191,25 - $ 240,00.

O custo médio seria de: $ 187.82.

Para determinar o custo estimado do projeto na plataforma “mainframe” ,DB2,CICS,CSP, necessitamos apenas multiplicar o tamanho do software em PF’s por $ 187.82. Considerando uma estimativa de 500 PF’s obteríamos um resultado de $ 93.910,00.

Outra alternativa é o emprego da interpolação aritmética para determinarmos o custo do projeto para tamanhos intermediários na tabela.

6.3.6 - Estimativa do Número de Instruções Fontes De acordo com Caper Jones 6, a predição do número de instruções fontes para um software é baseada na observação empírica do nível da linguagem e sobre o número de instruções requerido para implementar um ponto de função.

O nível da linguagem, a partir das pesquisas realizadas na IBM por Capers Jones e Albrecht, foi normalizado a partir de “instruções equivalentes em Assembler” na linguagem alvo, a fim de produzir um ponto de função.

Por exemplo, uma instrução fonte em Cobol equivale a três em Assembler, já o PL/1 equivale a quatro.

A Tabela a seguir apresenta uma amostra dos níveis de linguagem com o número correspondente de instruções fontes equivalentes para produzir um ponto de função.

Tabela 6-9 - Instruções Equivalentes Conforme Pontos de Função

Linguagem 1. Default - baixo nível• 2. Linguagem de Máquina 3. Assembler 4. Macro Assembler

1.0 1.0 1.0 1.5

Instruções Equivalentes 320 320 320 213

5. Default C 6. Basic Interpretado 7. Fortran II 8. Fortran 66 9. Default - segunda geração

2.5 2.5 2.5 2.5 3.0

128 128 128 128 105

10.Default - linguagens procedurais 11.Fortran 77 12.Algol 68 13.Algol W 14.Chill

3.0 3.0 3.0 3.0 3.0

105 105 105 105 105

15.ANSI Cobol 74 16. Coral 66 17. Jovial 18. ANSI Cobol 85

3.0 3.0 3.0 3.5

105 105 105 91

19.Default - Pascal 20.Basic Compilado 21.PL/S 22.Default - linguagens de terceira geração

3.5 3.5 3.5 3.5

91 91 91 91

23.Default - Geradores de Relatórios 24.PL/1 25.Modula 2 26.Ada

4.0 4.0 4.0 4.5

80 80 80 71

27.Prolog 28.Lisp 29.Forth 30. ANSI/Quick/Turbo Basic

5.0 5.0 5.0 5.0

64 64 64 64

31.Default- Linguagens de IA 32.Linguagens de Simulação 33.Default-Tabelas de Decisão 34.Default - Banco de Dados 35.Default - Suporte à Decisão 36.Default - Linguagem Estatistica 37.APL

6.5 7.0 7.0 8.0 9.0 10.0 10.0

49 46 46 40 35 32 32

•

Nível

Enquadram-se como default todas as outras linguagens do mesmo nível.

38.Default - Orientação à Objeto

11.0

29

39.Default - Quarta Geração 40.Default - Gerador de Programas 41.Default- Linguagens de Query 42.Default- Planilhas Eletrônicas 43.Default - Quinta Geração ( GUI)

16.0 20.0 25.0 50.0 75.0

20 16 13 6 4

Para a estimativa do número de instruções fontes do software devemos proceder como segue.

Determinar a Linguagem ( ou linguagens) de Desenvolvimento Realizar a Transformação - Caso de Uma Linguagem Exemplo: ➪ ➪

Linguagem Cobol 1000 PF’s estimados

O resultado é: Pontos de Função Estimados x No. de Instruções Equivalentes ou 1000 x 91 = 91.000 Instruções Fontes Realizar a Transformação - Caso de Duas Linguagens Exemplo: ➪ ➪ ➪ ➪

Linguagem Cobol Linguagem Assembler 1000 PF’s em Cobol 200 PF’s em Assembler

O resultado é: (1000 x 91 ) + (200 x 320 ) = 155.000 Instruções Equivalentes

6.4 - Estimativas Utilizando o COCOMO ( Constructive Cost Model) O método COCOMO foi desenvolvido por Barry Boehm 2 , para estimar esforço, prazo , custo e tamanho da equipe para um projeto de software.

O método foi derivado a partir de um “data set” compreendendo 63 projetos, cobrindo áreas como: negócios, controle, científica, suporte e sistema operacional.

Existem três modelos neste método:

➪ ➪ ➪

COCOMO Básico COCOMO Intermediário COCOMO Detalhado

O COCOMO Básico é uma versão aplicável à grande maioria dos projetos de software : pequenos a médios software, em termos de tamanho, desenvolvidos “inhouse”.

Entretanto as estimativas fornecidas pelo COCOMO Básico são limitadas, pois desconsideram alguns fatores tais como restrições de hardware, qualificação e experiência do pessoal, uso de modernas técnicas e ferramentas e outros atributos do projeto.

O COCOMO Intermediário já adiciona estes fatores, proporcionando estimativas mais acuradas.

O COCOMO Detalhado , por sua vez, apresenta técnicas para se estimar tanto a nível de módulo, subsistema e sistema, individualizando, a cada fase do projeto, os atributos de custo.

Para os objetivos deste capítulo, descreveremos os modelos Básico e Intermediário, pois julgamos suficiente para as necessidades da maioria dos ambientes de desenvolvimento das organizações brasileiras.

Um método de estimativa, para projetos de software, tem certa exatidão se o mesmo pode estimar os custos de desenvolvimento com 20% de variação em relação ao previsto e 30% em relação ao prazo.

De acordo com Boehm, o COCOMO Intermediário enquadra-se dentre desta definição.

O COCOMO categoriza os projetos de software em três tipos fundamentais: ➪

Modo Orgânico (Convencional) No modo orgânico, equipes relativamente pequenas desenvolvem sistemas num ambiente altamente “familiar”, “in-house”. A maior parte das pessoas engajadas no projeto tem experiência prévia com sistemas similares na organização, bem como tem um completo entendimento de como o sistema em desenvolvimento contribuirá para os objetivos da empresa.

Isto significa que a maioria das pessoas engajadas no projeto pode contribuir para o mesmo em seus estágios iniciais, sem gerar uma grande sobrecarga de comunicação sobre o que o sistema fará e qual será a divisão de trabalho para a equipe.

Um projeto orgânico é relativamente flexível sobre a forma como o software atende às especificações de requisitos e interfaces.

Outras características do modo orgânico são: (I) ambiente estável de desenvolvimento; (ii) algoritmos simples; (iii) prêmio relativamente baixo

para término antes do prazo;(iv) tamanho relativamente pequeno, projetos na faixa de 50.000 instruções fontes. ➪

Modo Difuso O modo difuso representa um estágio intermediário entre os modos orgânico e restrito. Significa uma mistura das características dos modos orgânico e detalhado.

Suas características básicas são: ➠ ➠ ➠

➪

a equipe mescla grande e pouca experiência com a aplicação a equipe mescal grande e pouca experiência com a tecnologia o tamanho do software varia até 300.000 instruções fontes

Modo Restrito O principal fator que distingue um projeto de software de modo Restrito é a necessidade para operar conforme grandes restrições. O produto deve operar dentro de um contexto complexo de hardware, software, regras e procedimentos operacionais, tal como um sistema de transferência eletrônica de fundos ou um sistema de controle de tráfego aéreo.

Como resultado, projetos de modo restrito não têm a opção de modificar facilmente suas especificações.

São projetos que requerem altos custos de verificação e validação. Estes fatores contribuem para baixar a produtividade e criar deseconomias de escala.

Geralmente, o prêmio para término antes do prazo é extremamente alto.

A seguir são apresentados os procedimentos para a realização de estimativas pertinentes com o COCOMO. 6.4.1 - Estimativa de Esforço - COCOMO Básico Determinar o Modo do Projeto (Orgânico,Difuso ou Restrito) Determinar o Número de Instruções Fontes Previstas Este é um das limitações do método, pois como, no início do projeto, saberemos quantas instruções fontes serão produzidas?

Uma alternativa, que nos parece viável, é a utilização combinada do método FPA com o COCOMO. Uma vez que o FPA pode transformar Pontos de Função em Instruções Fontes, poderíamos usar o resultado da transformação para a aplicação das equações de esforço do COCOMO.

Aplicar a Estimativa de Instruções Fontes na Equação de Esforço O COCOMO propicia três equações para determinar o esforço previsto para o projeto, conforme o modo do mesmo.

Tabela 6-10 - Equações de Esforço - COCOMO Básico

Modo

Esforço 1.05•

Orgânico

H/M = 2.4 (KDSI) 1.12

Difuso

H/M = 3.0 (KDSI) 1.20

Restrito

H/M = 3.6 (KDSI)

Supondo: ➪ ➪ ➪

50 KDSI para um software classificado como orgânico 100 KDSI para um software classificado como difuso 200 KDSI para um software classificado como restrito

Aplicando a fórmula: ➪

Esforço estimado para 50 KDSI orgânico 1.05

H/M = 2.4 ( 50 ) ➪

= 146 (por arredondamento)

Esforço estimado para 100 KDSI difuso 1.12

H/M = 3.0 ( 100 ) ➪

= 521 ( por arredondamento)

Esforço estimado para 200 KDSI restrito 1.20

H/M = 3.6 ( 200 )

= 2077 ( por arredondamento)

6.4.2 - Estimativa do Prazo - COCOMO Básico O COCOMO também provê equações para a determinação do prazo do projeto.

Tabela 6-11 - Equações de Prazo

Modo

Prazo 0.38

Orgânico

Prazo = 2.5 ( H/M) 0.35

Difuso

Prazo = 2.5 (H/M) 0.32

Restrito

•

Prazo = 2.5 (H/M)

H/M significa Homem/Mês e KDSI, milhares de instruções fontes entregues.

Aplicando as estimativas de esforço do exemplo anterior, os prazos estimados seriam: ➪

50 KDSI orgânico 0.38

Prazo = 2.5 ( 146 ) ➪

= 16.61 meses

100 KDSI difuso 0.35

Prazo = 2.5 ( 521 ) ➪

= 22.33 meses

200 KDSI restrito 0.32

Prazo = 2.5 ( 2077)

= 28.81 meses

6.4.3 - Estimativa de Quantitativo de Pessoal - COCOMO Básico Para a determinação do número médio de profissionais necessários para o projeto é preciso dividir o esforço estimado pelo prazo estimado. No nosso exemplo os resultados seriam: ➪

50 KDSI orgânico Equipe = 146 ÷ 16.61 = 9 ( por arredondamento)

➪

100 KDSI difuso Equipe = 521 ÷ 22.33 = 23 ( por arredondamento)

➪

200 KDSI restrito Equipe = 2077 ÷ 28.81 = 72 ( por arredondamento)

6.4.4 - Estimativa de Esforço - COCOMO Intermediário O mesmo procedimento adotado para o COCOMO Básico deve ser adotado aqui.

As diferenças fundamentais entre o modelo Básico e o Intermediário residem nas equações de estimativa de esforço e na consideração dos fatores de custo aplicáveis ao projeto.

No modelo Intermediário, as equações para determinação do esforço são: Tabela 6-12 - Equações de Esforço - COCOMO Intermediário

Modo

Esforço 1.05

Orgânico

H/M = 3.2 ( KDSI ) 1.12

Intermediário

H/M = 3.0 ( KDSI ) 1.20

Restrito

H/M = 2.8 ( KDSI )

Os fatores de custo são classificados por atributo do projeto, ou: ➪

Atributos do Produto ➠RELY Confiabilidade requerida pelo software ➠DATA Tamanho da base de dados ➠CPLX Complexidade do software

➪

Atributos Computacionais ➠TIME Restrições de execução (tempo de máquina) ➠STOR Restrições quanto ao uso de memória principal ➠VIRT Mudanças do ambiente de software ➠TURN Tempo de resposta

➪

Atributos da Equipe ➠ACAP Capacidade dos analistas ➠AEXP Experiência na aplicação ➠PCAP Capacidade dos programadores ➠VEXP Experiência no ambiente de hardware ➠LEXP Experiência na linguagem de programação

➪

Atributos do Projeto ➠MODP Técnicas modernas de programação ➠TOOL Uso de ferramentas ➠SCED Prazo requerido para o desenvolvimento

Cada um destes fatores tem um peso, que são os multiplicadores, que ajustam para mais ou para menos as estimativas iniciais.

Na Tabela 6-13 são mostrados os pesos para cada atributo.

Tabela 6-13 - Multiplicadores de Esforço Multiplicadores Atributos Muito Baixo Baixo .75 .88 RELY .94 DATA .70 .85 CPLX TIME STOR .87 VIRT .87 TURN 1.46 1.19 ACAP 1.29 1.13 AEXP 1.42 1.17 PCAP 1.21 1.10 VEXP 1.14 1.07 LEXP 1.24 1.10 MODP 1.24 1.10 TOOL 1.23 1.08 SCED

Pesos Nominal 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00

Alto 1.15 1.08 1.15 1.11 1.06 1.15 1.07 .86 .91 .86 .90 .95 .91 .91 1.04

Muito Alto 1.40 1.16 1.30 1.30 1.21 1.30 1.15 .71 .82 .70

Extra Alto

.82 .83 1.10

A determinação dos pesos aplicáveis ao projeto é dado pela Tabela 6-14.

1.65 1.66 1.56

Tabela 6-14 - Determinação dos Pesos Atributos Muito Baixo Baixo RELY InconveniênPerdas cia facilmente recuperadas DATA DB bytes ÷ no. instruções fontes < 10 CPLX Vide Tabela 6-15 TIME

STOR

VIRT

Nominal Perdas moderadas

Alto Altas perdas financeiras

Muito Alto Risco à vida humana

10 ≤DB <100 IF

100≤DB<1000 IF

DB ≥1000 IF

Extra Alto

≤50% disponibilidade de tempo de execução

70%

85%

95%

≤50% uso de memória disponível 6 meses

70%

85%

95%

Principais mudanças a cada 12 meses Interativo

< 4 horas

15o. percentil ≤4 meses de experiência 15o. percentil ≤1 mês de experiência ≤1 mês de experiência Não utiliza

35o. percentil 1 ano

55o. percentil 3 anos

75o. percentil 6 anos

35o. percentil 4 meses

55o. percentil 1 ano

75o. percentil 3 anos

4 meses

1 ano

3 anos

Iniciando

Algum uso

TOOL

Ferramentas básicas em micro

Ferramentas em mini

Ferramentas básicas de mainframe

SCED

75% nominal

85%

100%

Uso generalizado Ferramentas de programação e teste 130%

Ferramentas para análise, projeto, gerência 160%

Muito Baixo

Baixo

Nominal

Alto

Muito Alto

Extra Alto

Controle de Operações

Código simples com poucos operadores sem uso de Programação Estruturada

Operadores com uso de programação estruturada

Uso tabelas decisão; algum controle entre módulos

Código reentrante e recursivo; manuseio de interrupções

Controle de microcódigo; programação dinâmica de recursos

Operações Computacionais

Avaliaçào de expressões simples

Avaliaçào de expressões moderadas

Equações diferenciais parciais

Análise de dados stocásticos

Operações Dependenes de Máquina

Instruções simples de leitura e gravação

Tratamento de I/O

Uso de rotinas matemáticas e estatísticas padrões; operações com matrizes Processamen o de I/O incluido escolha do periférico,

Considerável controle entre módulos; controle de filas e pilha; grande número de operadores Análise numérica, interpolação multivariada. equações diferenciais Operações a nível físico de I/O

Rotinas de diagnóstico; comunicação

Operações em microprogramação ; controle de tempos

TURN ACAP AEXP PCAP VEXP LEXP MODP

do

2 meses

2 semanas

4-12 horas

mais que 12 horas 90o. percentil 12 anos 90o. percentil

Uso rotineiro

Tabela 6-15 - Complexidade de de

Operações De Gerência de Dados

Arrays simples memória principal

Projeto de Requisitos e do Produto

Pouco detalhe; pouca verificação; sem QA,CM•

QA,CM básicos; planos testes

Projeto Detalhado

Informação de projeto mínima; mínimo QA e CM; inspeções informais

Detalhe moderado; QA e CM básicos,plan o de teste

V&V

de e

Sem procediment o de teste; mínimo QA e CM

Procedimento de teste mínimo; QA e CM básico;

V&V

Integração e Teste

Sem procediment o de teste; muitos requisitos sem teste; mínimo QA e CM;

Procedimento de teste mínimo; requisitos frequenteme nte sem testes; QA e CM básico

Teste Código Unidade

na

Arquivos simples, sem arquivos intermediários

detecção de erro de processamen to Entradas para múltiplos arquivos

Verificação e validação de

V&V

Reestruturação complexa de dados a nível de registro

Verificação detalhada;pa drões de QA, CM, PDR, planos de teste detalhados Verificação detalhada; padrões de QA e CM; plano de teste detalhado

Procedimento de teste detalhado; QA e CM;

Procedimento de teste detalhado; QA e CM; documentação

Rotina parametrizada de estruturação de dados; otimização de pesquisa Verificação detalhada; QA,CM ,PDR e I V&V, planos de teste muito detalhados Verificaçào detalhada; padrões de QA e CM; inspeções detalhadas; planos de testes muito detalhados; I V&V Procedimento de teste detalhado; QA e CM; inspeções detalhadas de código; I V&V Procedimento de teste muito detalhados; QA e CM; IV & V

Estrutura realacional

Exemplo de aplicação do modelo Intermediário: Supondo: ➪

50 KDSI estimado para o software modo orgânico

Determinação do esforço não ajustado: 1.05

Esforço = 3.2 ( 50 )

•

= 195 Homens/Mês

QA=Quality Assurance,CM=Configuration Management,PDR=Product Design Review,IV & V = Independent Verification & Validation.

Ajustamento do esforço pelos multiplicadores escolhidos: Supondo as seguintes características do software conforme a tabela.

Multiplicadores Atributos

RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED

Pesos Muito Baixo

Baixo

Nominal

Alto

Muito Alto

.75 .70

.88 .94 .85

1.46 1.29 1.42 1.21 1.14 1.24 1.24 1.23

.87 .87 1.19 1.13 1.17 1.10 1.07 1.10 1.10 1.08

1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00

1.15 1.08 1.15 1.11 1.06 1.15 1.07 .86 .91 .86 .90 .95 .91 .91 1.04

1.40 1.16 1.30 1.30 1.21 1.30 1.15 .71 .82 .70

Extra Alto

1.65 1.66 1.56

.82 .83 1.10

195 x 1.15 x 1.08 x 1.00 x 1.00 x 1.06 x .87 x 1.07 x .86 x .91 x .86 x .90 x .95 x .82 x .83 x .1.10 = 102. 96 ou 103 H/M

Neste exemplo o esforço estimado passaria de 195 para 103 H/M. 6.4.5 - Estimativa de Prazo - COCOMO Intermediário O COCOMO intermediário utiliza as mesmas equações para determinar o prazo que o modelo Básico.

6.4.6 - Estimativa de Quantitativo de Pessoal - COCOMO Intermediário Utiliza-se do mesmo procedimento que o COCOMO Básico.

6.4.7 - Estimativa de Distribuição de Esforço e Prazo - Ambos Modelos O COCOMO emprega uma tabela padrão de tamanho de software, ou seja: ➪ ➪ ➪ ➪ ➪

Projeto pequenos Projetos intermediários Projetos médios Projetos grandes Projetos muito grandes

2KDSI 8KDSI 32KDSI 128KDSI 512KDSI

Associado a estes tamanhos de projetos, Boehm desenvolveu uma tabela (6-17) que estabelece a distribuição percentual de esforço e prazo pelas fases de um projeto.

Esta tabela é baseada na distribuição de Rayleigh. A distribuição de Rayleigh permite realizar estimativas aproximads da distribuição de esforço, pessoal necessário, previsão de defeitos etc.

Essa distribuição é determinada pela seguinte fórmula: 2

2

2

X = Y ( 1 ÷ td ) x e ✸✸ ( t ÷ 2 x td ) onde: X Y

➽ ➽

td t

➽ ➽

é o valor a ser estimado é o valor do atributo que será decomposto pela distribuição é o mês que o projeto atinge seu pico é o mês para o qual desejamos estimar

As fases contempladas pelo modelo COCOMO são: ➪ ➪ ➪ ➪

Planos e Requisitos Projeto do Produto Programação Integração e Teste

O procedimento para determinar o esforço e prazo para cada fase do projeto é dado pelo exemplo a seguir.

Considere o tamanho de um projeto , modo orgânico, conforme o modelo Intermediário, em 32 KDSI. Aplicando a equação de esforço teremos 122 H/M. Supondo um fator de ajustamento de 1.19 (derivado dos multiplicadores), teremos o H/M ajustado em 145 H/M e o prazo de 16,5 meses.

Para acharmos a distribuição do esforço e prazo por fases é necessário multiplicarmos o H/M e o prazo respectivamente pelos percentuais da tabela.

A distribuição ficaria conforme as tabelas a seguir: Tabela 6-17 - Distribuição de Esforço e Prazo Para Tamnhos Padrões Distribuição de Esforço (%) Modo Fase 2KDSI 8KDSI Planos e Requisitos 6 6 Orgânico Projeto do Produto 16 16 Programação 68 65 Projeto Detalhado 26 25 Codificação 42 40 Integração e Teste 16 19 Planos e Requisitos 7 7 Difuso Projeto do Produto 17 17 Programação 64 61 Projeto Detalhado 27 26 Codificação 37 35 Integração e Teste 19 22 Planos e Requisitos 8 8 Restrito

Tamanho 32KDSI 6 16 62 24 38 22 7 17 58 25 33 25 8

128KDSI 6 16 59 23 36 25 7 17 55 24 31 28 8

512KDSI

7 17 52 23 29 31 8

Projeto do Produto Programação Projeto Detalhado Codificação Integração e Teste Prazo (%) Orgânico

Difuso

Restrito

Planos e Requisitos Projeto do Produto Programação Integração e Teste Planos e Requisitos Projeto do Produto Programação Integração e Teste Planos e Requisitos Projeto do Produto

Programação Integração e Teste

18 60

18 57 28 32

22

18 54 27 30

25 10

19 63 18

26 28

11

16

12

18

24

31

34

19 51 30 20

22

26 48 26 28

24 24

13

19 55 26

25 52 23

18 48 25 26

28

19 59 22

24 56 20

18 51

27 44 29 32

24 28 40 32

36

40

30

32

34

36

38

48 22

44 24

40 26

36 28

38 30

Tabela 6-18 - Distribuição do Esforço do Exemplo

Orgânico

Planos e Requisitos Projeto do Produto Programação Integração e Teste

.06 x 145 = 8.7 .16 x 145 = 23.20 .62 x 145 = 89.90 .22 x 145 = 31.90

Tabela 6-19 - Distribuição do Prazo Para o Exemplo

Orgânico

Planos e Requisitos Projeto do Produto Programação Integração e Teste

.12 x 16.5 = 1.98 .19 x 16.5 = 3.14 .55 x 16.5 = 9.08 .26 x 16.5 = 4.29

Para tamanhos de software diferentes dos tamanhos da tabela padrão, mas que estejam dentro dos limites 2 - 512, podemos empregar a interpolação aritmética a fim determinarmos a distribuição do esforço e prazos por fases.

A estimativa do quantitativo de pessoal necessário para cada fase é obtida dividindo-se a distribuição do esforço pela de prazo.

Tabela 6-20 - Distribuição do Quantitativo de Pessoal Por Fase Para o Exemplo

Orgânico

Planos e Requisitos Projeto do Produto Programação Integração e Teste

8.7 ÷ 1.98 = 4.39 ou 4 23.20 ÷ 3.14 = 7.39 ou 7 89.90 ÷ 9.08 = 9.90 ou 10 31.90 ÷ 4.29 = 7.44 ou 7

6.4.8 - Estimativa de Custo do Projeto A mesma conceituação e procedimentos que foram explicados no item 6.3.5 são empregados com os resultados do método COCOMO. 6.5 - Estimativas Utilizando Regressão Linear A regressão linear é uma técnica estatística que permite realizar previsões através da determinação do tipo de associação entre variáveis.

A regressão linear simples, associa duas variáveis entre si. Por exemplo, uma variável é função de outra variável.

Defeitos de um software = f ( Tamanho em Function Points) Através da equação de regressão linear podemos determinar ou prever o valor da outra variável. No exemplo anterior, tendo-se um certo número de observações de defeitos de software e de tamanho do software em function points, e um dado valor atribuído ao software em pontos de função, podemos prever o número de defeitos esperados para o software.

A regressão não só apresenta a relação linear positiva como também a negativa.

Isto significa dizer que, no caso de associação positiva, quando o valor de uma variável cresce, o valor da outra também cresce. No caso de associação negativa acontece o inverso.

A forma geral da equação de regressão linear para dados de uma amostra é: __ Y x = a + bX onde: __ Yx é o valor estimado da variável dependente, dado um valor específico da variável independente X a é o ponto de intersecção da linha de regressão linear com o eixo Y b é a declividade da linha de regressão X é o valor específico da variável independente Há diversos critérios matemáticos para o desenvolvimento de uma equação de regressão.

Pelo método dos mínimos quadrados• , a equação de regressão melhor ajustante é aquela para a qual é mínima a soma dos quadrados dos desvios entre os valores observados e estimados da variável dependente em função dos dados amostrais.

As fórmulas pelas quais os valores de a e b da equação são determinados, a fim de satisfazer o critérios dos mínimos quadrados, são: _ _ ∑ XY - nX Y b= 2 _2 ∑ X - nX _ _ a = Y - bX Formulada a equação de regressão, podemos estimar o valor da variável dependente dado o valor da variável independente. Entretanto, tal estimativa deve ser feita apenas dentro do intervalo de variação dos valores da variável independente.

•

Vide Kazmier 7 para obter maiores detalhes sobre regressão linear e outros tratamentos estatísticos.

Para auxiliar na demonstração da aplicação da regressão linear, usaremos a Tabela 6-21 .

Tabela 6-21 - Data Set de Variáveis de Tamanho e Defeitos

Observações

1 2 3 4 5 6 7 8 9 10 Totais Média

Tamanho do Software em PF’s - X 10 20 40 80 160 320 640 1280 2560 5120 10230 1023

Defeitos do Software Y 6 24 32 192 384 768 1536 3072 6144 12288 24446 2444,60

2

2

XY

X

Y

60 480 1280 15360 61600 245760 983040 3932160 15728640 62914560 83882940

100 400 1600 6400 25600 102400 409600 1638400 6553600 26214400 34952500

36 576 1024 36864 147456 589824 2359296 9437184 37748736 150994940 201315940

6.5.1 - Estimativa do Número de Defeitos Pré-Release A equação da regressão neste caso é : Defeitos Pré-Release = f ( Tamanho do Software em Pontos de Função) Supondo que a estimativa do tamanho do software seja 1200, queremos determinar qual o número de defeitos pré-release esperado.

Determinação dos Valores de a e b ∑ XY - nX Y b= 2

∑X

_2 - nX

_ _ a = Y - bX b = 62914560 - 10 (1023) (2444,60) = 1,55 2

34952500 - (10) (1023) a = 2444,60 - (1,55) (1023) = 860.99 ou 861 Aplicar a e b Na Equação de Regressão _ Y x = a + bX = 861 + 1,55 x 1200 = 2721 defeitos esperados

6.5.2 - Estimativa do Número de Defeitos Pós-Release A equação de regressão neste caso é: Defeitos Pós-Release = f( Tamanho do Software em Pontos de Função) Analogamente à aplicação anterior, deveria ser estruturado um “data set” que contivesse todas as observações acerca de defeitos pós-release para os tamanhos correspondentes dos software em pontos de função a fim de aplicar a equação de regressão e realizar a estimativa.

6.5.3 - Estimativa do Esforço de Retrabalho O retrabalho no desenvolvimento de software está associado ao número de defeitos encontrados no software ao longo do projeto.

Ou seja, a equação de regressão é: Esforço de Retrabalho = f( Número de Defeitos Pré-Release) Para tanto o “data set” deveria conter dados acerca do esforço de retrabalho conforme o tamanho do software em pontos de função.

Este raciocínio também é válido para a estimativa de esforço de retrabalho durante a manutenção do software.

6.5.4 - Estimativa do Custo de Retrabalho Como o esforço é o principal componente de custo, a equação de regressão para determinar o custo estimado do retrabalho, tanto para defeitos pré-release como pósrelease é: Custo do Retrabalho = f( Esforço de Retrabalho) Outra alternativa seria multiplicarmos o custo médio do homem/mês ou homem/hora pelo esforço estimado.

REFERÊNCIAS 1. BANDEIRA, Alfredo. Acompanhamento do Custo de Sistemas. SUCESU-DF, Anais do Congresso Regional de Informática,Brasília, 1984.

2.

BOEHM,Barry . Software Cliffs,New Jersey, 1981.

Engineering

Economics.

Prentice-Hall,Englewood

3. FENTON, N.E. Software Metrics: a rigorous approach. Chapman & Hall, London, 1991.

4.FERNANDES, A.A. & KUGLER,J.L.C. Gerência de Projetos de Sistemas:uma abordagem prática. Livros Técnicos e Científicos Editora S.A., Rio de Janeiro, 2a. edição,1990.

5.

IFPUG. Function Points Westerville,Ohio,1994.

Counting

Practice

Manual

-

Release

4.0.

6. JONES,Capers. Applied Software Measurement. McGraw- Hill, New York ,1991.

7.KAZMIER,L.J. Estatística Aplicada a Economia e Administração. McGraw-Hill,São Paulo,1982.

Capítulo

7 APLICAÇÃO DAS MEDIÇÕES NO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE O objetivo principal para aplicar medições na gestão do projeto está associado aos seguintes aspectos: ➪ ➪ ➪ ➪ ➪

Atingimento do prazo inicialmente previsto Atingimento do orçamento inicialmente previsto Geração de um produto de software de boa qualidade, adequado ao uso Satisfação do cliente/usuário Prover a gerência do ambiente de desenvolvimento com as informações requeridas para a melhoria dos processos de planejamento, desenvolvimento de software e projeto e gestão do produto

Para tanto é preciso controlar/monitorar o processo de desenvolvimento visando manter a produtividade nos níveis previstos ou padrões, remover defeitos introduzidos no produto o quanto antes no processo, reduzindo ou eliminando o esforço de retrabalho, consequentemente mantendo o orçamento sob controle.

O processo de gestão, que conta com uma série de atributos, tais como gestão dos recursos, revisão e refinamento do planejamento, gestão financeira,gestão da documentação e objetos, gestão das mudanças, a realização de medições e inspeções e a avaliação final do projeto, atua sobre um processo de desenvolvimento de software que é representado pela metodologia de desenvolvimento.

Neste capítulo, similarmente ao anterior, procuramos descrever os princípios fundamentais do processo de gestão, dando destaque especial para o processo de inspeção formal de software e de avaliação do projeto para após, detalharmos as medições que devem ser aplicadas.

7.1 - O Processo de Gestão de Projetos O Processo de Gestão do Projeto é composto por um conjunto de elementos ou atributos como mostra a Figura 7-1.

O Processo de Gestão atua sobre um processo de desenvolvimento, geralmente representado por uma metodologia composta por fases,etapas e atividades, assim como padrões de construção (técnicas,métodos e ferramentas) e padrões de apresentação de produtos.

Na Figura, o processo de desenvolvimento está representado por 7 fases,quais sejam:

Gestão da Qualidade

Controle do Progresso

Gestão Financeira

Gestão das Mudanças

MEDIÇÕES E ANÁLISES

Instalação

Análise Preliminar

Especificação

Prototipação

Projeto Detalhado

Implementação

PROCESSO DE INSPEÇÃO

Implantação Avaliação

MONITORAMENTO Figura 7-1 O Processo de Gestão do Processo de Desenvolvimento

➪

Instalação do Projeto

A instalação do projeto tem como objetivo formalizar o seu início junto aos clientes/usuários participantes. Com este procedimento, procura-se criar visibilidade para o projeto perante o cliente, assim como obter comprometimento quanto às metas perseguidas.

A instalação do projeto deve ocorrer por meio de uma Reunião de Instalação do Projeto a qual é o primeiro serviço a ser desenvolvido independente do roteiro metodológico a ser seguido.

A reunião de instalação deve ser considerada como o “ponto de partida” real do projeto.

Nesta reunião são apresentados os objetivos e escopo do projeto, premissas e diretrizes que nortearão o projeto, o modelo de gestão do projeto, as responsabilidades tanto do cliente/usuário como da área de desenvolvimento, os critérios de resolução de pendências, o cronograma mestre resumido do projeto calendarizado e o cronograma de atividades cuja responsabilidade principal é do cliente/usuário.

Devem participar todas as pessoas que serão envolvidas de forma direta ou indireta no esforço do projeto. ➪

Análise Preliminar

Consiste no esforço necessário para entender o negócio do cliente/usuário a fim de propor soluções informatizadas, na elaboração do modelo de dados preliminar, na elaboração de estimativa de tamanho do software, no estabelecimento de alternativas de solução e na identificação preliminar das principais funções da solução.• O produto desta fase é o Projeto Preliminar ou Ante-Projeto. ➪

Especificação

Refere-se à elaboração do projeto lógico do software, incluindo a elaboração do modelo funcional e de dados ou o modelo essencial do sistema, do modelo operacional preliminar do sistema (Diagrama Hierárquico do Sistema-DHS), dos procedimentos de segurança e controle, do projeto de diálogo,do projeto de normalização e assim sucessivamente. O produto desta fase é o Projeto de Especificação. ➪

Prototipação

Refere-se à elaboração de versões de um protótipo do sistema conforme especificado na fase anterior. Geralmente pode ser construído um protótipo com funcionalidade mínima apresentando telas de entradas e saídas, o que na linguagem técnica significa “mock-up”. Na prototipação é que as especificações são validadas pelos clientes/usuários. Esta fase pode ser realizada concomitantemente com a fase anterior e gera como produto o protótipo do sistema. ➪

Projeto Detalhado

Consiste na elaboração do modelo de armazenamento de dados, na identificação das necessidades de acesso ao banco de dados, no projeto físico do banco de dados, no projeto de rotinas automatizadas, na definição das regras de integridade do banco de dados e na revisão do modelo operacional preliminar do sistema.

Gera como produto o Projeto Físico o qual também deve ser homologado formalmente pelo cliente/usuário. ➪

Implementação

Abrange a codificação das rotinas automatizadas, a criação do banco de dados, o teste individual de programas, o teste de módulos, o teste integrado do sistema, o teste de aceitação do cliente/usuário, a realização de acertos que porventura houverem, o ajuste no banco de dados e a disponibilização do produto para ser implantado em ambiente operacional. Gera como produto o software para ser testado em campo. ➪ Implantação

•

Apesar desta fase geralmente encontrar-se dentro do contexto do projeto, onde os compromissos com prazos e resultados já foram feitos junto ao cliente/usuário, esta fase, a rigor não deveria fazer parte do projeto; deveria ser considerada no esforço de planejamento.

Refere-se ao planejamento da implantação, treinamento dos clientes/usuários na operação do novo sistema, execução do sistema no campo e, se for o caso, passagem para a produção, bem como o atendimeno inicial.

As Medições referem-se à coleta de dados sobre prazo, esforço, custo de cada fase, defeitos encontrados e removidos e outros atributos do processo, assim como a medição do tamanho do software ao final do projeto. As medições são necessárias para a gestão do processo de software como um todo (compreendendo ações para a melhoria contínua), bem como para o projeto de desenvolvimento.

O Processo de Inspeção,que será detalhado mais adiante, é efetivado em pontos específicos do processo de desenvolvimento. A inspeção tem como objetivo detectar defeitos introduzidos no projeto e acompanhar sua resolução, assegurando a conformidade dos produtos com os requisitos e especificações.

Para realizarmos as inspeções é necessário que o processo gere produtos intermediários 100% inspecionáveis. O progresso de qualquer projeto somente é perceptível com produtos intermediários 100% acabados.

A Avaliação do projeto tem como objetivo registrar informações sobre: ➪

➪

➪ ➪

Aspectos técnicos do projeto e do processo de desenvolvimento, visando alimentar uma base de dados que possa subsidiar o planejamento de novos projetos Eventos que contribuiram para a variabilidade do processo, visando subsidiar a ação corretiva correspondente a fim de eliminar as fontes de não conformidade Percepção do cliente/usuário a respeito da qualidade do desenvolvimento do projeto Percepção do cliente/usuário a respeito da “adequação ao uso” do software

A Gestão da Qualidade enfatiza a remoção de defeitos nos produtos que são introduzidos durante o processo de desenvolvimento . Dessa forma é preciso monitorar o progresso na remoção de defeitos, verificar defeitos restantes, analisar os defeitos em termos de sua composição, origem, verificar a distribuição de defeitos por módulo do software, analisar a eficiência do processo de inspeção, identificar módulos propensos a erros, determinar a densidade de defeitos do software entregue e comparar com padrões e determinar a intensidade de falhas esperada para o produto a fim de prover a gestão do produto com informações necessárias para alocação de recursos para manutenção.

O Controle do Progresso contempla o refinamento do planejamento, o replanejamento do projeto, base para o acompanhamento físico, bem como a verificação do progresso do desenvolvimento dos produtos intermediários do projeto conforme o roteiro metodológico de trabalho adotado.

O refinamento do planejamento é requerido na medida em que o projeto avança.

Isto ocorre quando temos uma maior compreensão da solução, quando são registradas atividades realizadas e que não haviam sido previstas inicialmente, quando, em função de um maior conhecimento da solução, prevêem-se novas

atividades a serem realizadas e quando, ao término de uma fase do projeto, necessitamos desdobrar as atividades da próxima fase.

O refinamento não deve ser confundido com replanejamento. Este geralmente ocorre em função de atrasos, antecipações ou por mudança de escopo do projeto.

Uma das preocupações em refinar o planejamento inicial do projeto é manter o registro de como o mesmo foi conduzido e determinar, para uso futuro, o melhor roteiro metodológico para projetos de mesma natureza, além de, naturalmente, propiciar a gerência efetiva do projeto em curso•.

O replanejamento do projeto é necessário quando há solicitações feitas pelo cliente/usuário que impactam o projeto e há ocorrências de eventos (contingências) que também impactam o projeto.

O replanejamento pode caracterizar-se por alterações nos prazos previstos e/ou na alteração do roteiro metodológico inicial. Atenção deve ser dada ao controle das versões do planejamento.

A Gestão Financeira e de Recursos abrange o controle do orçamento, cotejando continuamente o realizado contra o previsto, a verificação do custo restante ou previsão de custo adicional, bem como na alocação, realocação, qualificação e substituição dos recursos orçados para o projeto em termos de recursos humanos, recursos computacionais e demais tipos de recursos/serviços. Esta função, no âmbito de um projeto é crucial, visto ser a base para os registros de esforço(homem/mês) alocado às fases/etapas/atividades, bem como para os registros da alocação de outros recursos. Estes regisros também vão determinar os custos reais do projeto.

A Gestão de Mudanças contempla o controle de mudanças no escopo do projeto, a análise das mudanças, a manutenção da documentação técnica e gerencial pertinente e a elaboração de simulações de impacto sobre o projeto.

Um dos principais problemas na gestão de projetos de software é a alteração constante do escopo do projeto, ou em função de mudanças nos requisitos dos usuários ou em função de eventos inesperados, tal como mudança de legislação.

A gerência do projeto, neste caso, deve evidenciar, através de simulações, o impacto sobre prazos e, principalmente custos. Esta função dá o “start” para o replanejamento.

A gestão de mudanças também contempla a gestão da documentação técnica e objetos (componentes de software), da documentação gerencial e as respectivas versões.

•

De acordo com Frederick P. Brooks 3 um dos principais fatores de insucesso em projetos de software é a inexistência de um calendário detalhado de eventos.

A documentação técnica do projeto refere-se aos documentos (produtos) de especificação, projeto detalhado,implementação, implantação e componentes de software e versões.

A documentação gerencial abrange o conjunto de documentos pertinentes às informações sobre a gestão do projeto em termos de: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Cópia do estudo preliminar, ante-projeto ou proposta técnica Cópias de Atas de Reunião Cópias de homologações de produtos intermediários Cópias de registros de ocorrências Cópias das análises das solicitações de alterações de escopo Cópia do cronograma original (1a. versão) e versões consecutivas Quadro de alocação de recursos e versões consecutivas Cópias de comunicações expedidas e recebidas Cópia da avaliação do projeto

O Monitoramento do projeto, por sua vez, abrange a análise das informações quantitativas sobre o processo de desenvolvimento , das informações sobre inspeção , sobre recursos, planejamento, financeiras, produtos intermediários (documentos) e sobre mudanças a fim de apoiar processos de tomada de decisão que sejam necessários.

Geralmente o monitoramento ocorre em pontos intermediários do processo ou pontos de controle a fim de verificar o grau de atingimento das metas, nível da qualidade, decidir sobre pendências e assim sucessivamente.

O monitoramento deve ser feito junto com o cliente/usuário e pode ser agendado desde o início do projeto. Dependendo do porte e importância do projeto, é recomendável a criação de Comitê Gerencial.

7.2 - O Processo de Inspeção Formal de Software O Processo de Inspeção de Software é o principal meio pelo qual a qualidade do processo pode ser medida; é a base para a gerência do processo de desenvolvimento.

De acordo com Ebenau & Strauss 6 , inspeções no processo são meios de verificar produtos intelectuais pelo exame manual dos mesmos, através de pequenas equipes, para assegurar a conformidade dos produtos com especificações e requerimentos.

O objetivo principal do processo de inspeção é a detecção de defeitos e a remoção subsequente dos mesmos.

Não é objetivo da inspeção a avaliação das decisões conceituais sobre a solução que está sendo desenvolvida. Tal tipo de avaliação pode ser feita em processos de “Walkthrough’s” os quais são menos formais• que os de inspeção.

Um processo de inspeção para se tornar viável depende dos seguintes fatores: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Capacitação do pessoal técnico para realizar inspeções Conhecimento do pessoal técnico acerca do ambiente de desenvolvimento, métodos e técnicas de projeto de software Um processo de desenvolvimento claramente definido Checkpoints em estágios intermediários no processo Produtos intermediários claramente definidos (“work-products”) no contexto do processo de desenvolvimento Uso efetivo das informações coletadas pela inspeção para melhorar a qualidade do produto, do processo e dos métodos de gestão Avaliar o processo e produto e não pessoas• ( importantíssimo) Atributos a serem medidos devem estar claramente definidos

Do ponto de vista econômico a inspeção permite reduzir os custos de desenvolvimento, pela redução do esforço de retrabalho.

A Figura 7-2 mostra a relação do custo para identificar e remover defeitos entre as fases de desenvolvimento do software.

Custo Relativo

Figura 7-2

1000 500 200 100 50 20 10 5 2 1 Requisitos

Projeto

Codificação

Teste

Aceitação

Operação

A aplicação da Inspeção , desde o início do processo de desenvolvimento, permite obter uma primeira indicação quantitativa da qualidade do produto que está sendo construído, ao contrário do que ocorre quando utilizamos somente metotologia de teste.

A Figura 7-3 demonstra este aspecto.

•

Vide a referência 12 , para uma apreciação detalhada sobre Walkthrough.

Vide o capítulo 13, o qual trata sobre questões éticas quanto ao uso de medições em software.

•

SEM INSPEÇÕES Projeto

Codificação

Teste

Primeira indicação quantitativa da qualidade - a partir dos resultados do teste Cronograma COM INSPEÇÕES Projeto Io Codificação I1

I2 Teste

Primeira indicação quantitativa da qualidade Custo de Remoção de Defeitos

  Figura 7-3 Inspeção e Indicação Quantitativa da Qualidade

Segundo David Card 5 , 81% dos defeitos introduzidos em um software são oriundos da fase de projeto. Este é mais um dos motivos pelos quais é importante aplicar a inspeção desde o início do projeto do software.

Mesmo com este dado estatístico, o rigor dos procedimentos de inspeção devem ser homogêneos ao longo do desenvolvimento, particularmente no Brasil, onde os requisitos e consequentemente as especificações sofrem constantes alterações.

A inspeção pode ser aplicada em várias etapas do processo de desenvolvimento como mostra a Figura 7-4.

ANÁLISE PRELIMINAR

Inspeção de Planos de Projeto

ESPECIFICAÇÃO

Inspeção de Conceitos e de Requisitos

PROTOTIPAÇÃO

Inspeção do Protótipo

PROJETO DETALHADO

Inspeção do Projeto

IMPLEMENTAÇÃO

Inspeção de Requisitos e Projeto

Figura 7-4 Inspeções No Processo do Software

O Processo de Inspeção é composto por 5 etapas, ou seja: ➪ ➪ ➪ ➪ ➪ ➪

Planejamento Visão Geral Preparação Reunião Retrabalho Acompanhamento

A Tabela 7-1 mostra a descrição e os objetivos de cada etapa Tabela 7-1 - Etapas do Processo de Inspeção  6 

Etapa Planejamento

Visão Geral Preparação

Descrição Estabelecimento de cronograma; selecionar inspetores; obter e distribuir material Apresentação pelo autor, do trabalho a ser inspecionado Estudo individual do material

Objetivos Assegurar que os prazos,participantes e materias estejam disponíveis Prover entendimento sobre o material a ser inspecionado Preparar os participantes a

Reunião Retrabalho Acompanhamento

a ser inspecionado Exame formal do material distribuído Revisar o produto Verificar a resolução satisfatória dos defeitos identificados

identificar defeitos Identificar e registrar os defeitos Resolver problemas Certificar a revisão pelo autor e completar a inspeção

Estas etapas compõem uma sequência natural de condução do processo de inspeção, a qual prevê a geração de produtos.

Produto

Etapa de Planejamento

Notificação de Inspeção

Etapa de Visão Geral

Etapa de Preparação

Etapa de Retrabalho

Etapa de Reunião de Inspeção Lista de Defeitos

Sumário de Defeitos Produto Inspecionado

Etapa de Acompanhamento

Fonte 6 Relatório Gerencial Figura 7-5 Fluxo Do Processo de Inspeção

Note que o produto a ser inspecionado pode ser um “deliverable” intermediário a uma fase, por exemplo, o modelo de dados juntamente com o dicionário de dados, pertencente à fase de especificação, ou o produto final de uma fase. Os itens a serem selecionados para sofrerem inspeção dependem do prazo e porte do projeto. Entretanto devem consistir naqueles produtos que são críticos para o sucesso do projeto.

A Tabela 7-2 descreve cada uma das etapas do processo de inspeção, considerando as entradas, o processo e as saídas.

Tabela 7-2 - Descrição das Etapas do Processo de Inspeção 6

Entradas Planejamento

Processo

Saídas

1. “Work-Product” completado

1. Moderador verifica atendimento dos critérios de entrada

1. Critérios de entrada verificados

do produto a ser inspecionado 2. Critério de entrada da inspeção 3. Taxa de inspeção

2. Moderador seleciona inspetores 3. Moderador determina a necessidade pela visão geral

2. Notificação de reunião de inspeção 3. Reserva de sala para a reunião

4. Moderador cronograma a

Materiais de inspeção

inspeção

Visão Geral 1. Produto a ser inspecionado

1. Moderador conduz reunião preliminar para entendimento

1. Conhecimento do produto a ser inspecionado

do produto 2. Materiais relacionados

2. Autor apresenta o produto para moderador e inspetores

2. Respostas à questões

3. Auxílios Visuais

3. Moderador determina a preparação e responsabilidades

3. Atribuição de responsabilidades

de leitura do material 4. Sala de reunião

Preparação 1. Produto a ser inspecionado

1. Estudo, pelos inspetores, do material a ser inspecionado

1. Conhecimento do material

2. Notificação de reunião de inspeção

2. Determinação sobre como o produto será apresentado

2. Anotação dos defeitos

3. Checklists de inspeção

3. Inspetores registram seu tempo de preparação

3. Registro do tempo de preparação

1. Produto a ser inspecionado

1. Moderador inicia a reunião e verifica tempos de preparação

1. Lista de defeitos identificados

2. Referências necessárias

2. Leitura do produto

2. Relatório da reunião de inspeção e sumário de defeitos

3. Tempos de preparação dos inspetores

3. Defeitos são identificados e registrados

3. Disposição do produto

4. Anotações de preparação

4. Lista de defeitos é revisada

dos inspetores

e a disposição do produto é

4. Tempo de preparação recomendado

Reunião de Inspeção

determinada 5. Checklist de inspeção

5. Relatório da reunião e sumário de defeitos são completados

6.Notificação de reunião de inspeção

Tabela 7-2 - Descrição das Etapas do Processo de Inspeção (Continuação)

Retrabalho 1. Lista de defeitos identificados

1. Autor resolve a lista de defeitos

1. Produto revisado

2. Disposição do produto

2. Moderador notifica o

3. Cronograma para o modera-

término do retrabalho

dor revisar ou reinspecionar o retrabalho

Acompanhamento 1. Produto revisado

1. Moderador verifica o atendimento, pelo produto, dos cri-

1. Produto inspecionado

térios de saída 2. Se for uma reinspeção considerar as entradas das etapas de planejamento,visão geral, preparação e reunião de inspeção

2. Considerar os processos das 4 primeiras etapas

2. Se a disposição do produto for condicional ou rejeitado, considerar as saídas da etapa de reunião de inspeção

3. Moderador completa o relatório de inspeção

3. Relatórios de inspeção completados

No Processo de Inspeção os membros da equipe desempenham os seguintes papéis: ➪

Autor é o indivíduo responsável pela elaboração do produto epela realização de mudanças exigidas em função da inspeção

➪

Moderador é o indivíduo que assegura que os procedimentos são seguidos; gerencia o processo de inspeção

➪

Leitor é o responsável por conduzir a equipe de inspeção na leitura do material durante a reunião de inspeção

➪

Registrador é o indivíduo responsável por registrar e classificar todos os defeitos identificados na reunião de inspeção

➪

Inspetor é representado por todos os membros da equipe de inspeção, incluindo o autor; sua responsabilidade é a de identificar defeitos

Durante a reunião de inspeção, o produto inspecionado pode receber a seguinte disposição: ➪

Produto Aceito, ou seja, atende as especificações e os critérios de saída da inspeção (não está porém, totalmente livre de defeitos)

➪

Produto Aceito Condicionalmente; neste caso há alguns defeitos significativos os quais podem ser removidos, (necessitando de retrabalho) com a revisão pelo moderador junto ao autor, sendo que os defeitos não criam mudança relevante para o produto em termos de conformidade

➪

Produto a Ser Reinspecionado, ou seja, o produto deve passar novamente pelas etapas de reunião de inspeção, retrabalho e acompanhamento

Em equipes pequenas de projeto sugere-se que o próprio líder se responsabilize pelo papel de moderador, enquanto os demais membros pelo papel de inspetores.

Algumas empresas de classe mundial 4, 11, 13, têm obtido grande sucesso com a aplicação do processo de inspeção. Este sucesso tem sido traduzido em projetos nos prazos e economias no custo (orçamento) , tanto para a fase de desenvolvimento do software como para a de manutenção/evolução.

Pelo investimento em inspeção, reduz-se significativamente os custos de má qualidade de falha interna e externa.

Visto os conceitos básicos relevantes para a gestão do processo de desenvolvimento, iremos detalhar as medições necessárias nesta fase do ciclo de vida do software.

7.3 - Medições no Processo de Desenvolvimento de Software Como vimos pelo modelo que denominamos de mecanismo de medição, as medições no processo de desenvolvimento do software têm vários propósitos, quais sejam: ➪ ➪ ➪ ➪

Medições para a gestão do próprio processo Medições para atender à gestão do produto Medições para subsidiar o aperfeiçomento do processo de planejamento de projetos, a ser utilizado por todos os projetos da instalação Medições para subsidiar o aperfeiçoamento do processo de software, a ser utilizado por todos os projetos da instalação

➊ PROCESSO

➌

➋

PRODUTO

➍

PROCESSO DE PLANEJAMENTO DE PROJETOS

PROCESSO DE SOFTWARE

Figura 7-6 Medições Realizadas Durante do Desenvolvimento

Antes mesmo de começar o projeto propriamente, já devemos registrar algumas informações no Banco de Dados de Métricas e Projetos.

Essas informações , maioria de caráter subjetivo, vão subsidiar a avaliação final do projeto, bem como delinear as características do ambiente de desenvolvimento visando possibilitar a verificação, a posteriori, de fatores críticos que possam afetar a qualidade e produtividade do processo de desenvolvimento.

Dessa forma começaremos por listar estas informações.

7.3.1- Informações Que Devem Ser Coletadas No Início do Desenvolvimento No início do projeto o software deve ser caracterizado. A caracterização consiste numa série de atributos que qualificam o projeto em termos de: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Ambiente de hardware/software de desenvolvimento Perfil preliminar da equipe do projeto Abrangência do software em termos organizacionais ou de mercado Classe e tipo do software, se software produto, se comercial,controle de processos, software de missão crítica etc.

Caracterização do ambiente de apoio ao desenvolvimento Utilização de métodos e técnicas de gestão do projeto Metodologia de desenvolvimento a ser empregada Métodos e técnicas de remoção de erros a serem utilizadas

Estas informações na realidade são variáveis as quais podem ser tratadas estatísticamente para determinar qual a combinação de fatores que levam a uma melhor qualidade e produtividade do processo de desenvolvimento.• Ao final do projeto esta qualificação inicial é comparada com o que de fato ocorreu para fins de análise de causas.

Se estivermos usando um banco de dados de projetos e de métricas, estas informações constituirão os dados de identificação do projeto.

7.3.2 - Medições Para a Gerência do Processo de Desenvolvimento Aqui as medições podem ser visualizadas conforme as principais funções desempenhadas pela gerência e as metas estipuladas no planejamento do projeto em termos de prazos, esforço, custo e qualidade.

De acordo com a Figura 7-1, que mostra o esquema de gestão do processo de desenvolvimento, as funções principais são: ➪ ➪ ➪ ➪ •

Gestão da Qualidade Gestão do Progresso Gestão Financeira Gestão de Mudanças

Ainda neste capítulo, quando da discussão da avaliação final do projeto, é mostrada a forma sobre como estas variáveis são mensuradas.

Decidimos, para a melhor compreensão da aplicação das medições, apresentá-las conforme este modelo. ⌦

Medições Para a Gestão da Qualidade

A gestão da qualidade do processo de desenvolvimento visa fundamentalmente a remoção de defeitos nos produtos que vão sendo gerados ao longo do processo. Na realidade é uma abordagem preventiva.

Para fins de medição qual o significado de defeitos, falhas e “bugs”?

Uma definição simples para Defeitos é: um problema com o produto que é detectado em algum ponto do desenvolvimento. Falhas ocorrem quando o produto não desempenha a tarefa requerida pelo cliente/usuário (conforme especificações) durante a sua operação. Já “bug” é um defeito no programa que é encontrado durante a sua operação , tanto no teste como durante o seu uso. É importante notar que defeitos e falhas não são sinônimos. Falhas podem ser causadas por defeitos. Destacamos a palavra podem, em virtude de que nem sempre um defeito causa uma falha. Por exemplo, um defeito de não atendimento do padrão de programação pode não criar uma falha caso a lógica estiver correta.

Adicionalmente, a instalação deve possuir uma classificação dos defeitos para fins de monitorar o processo e identificar as principais causas de introdução dos mesmos nos produtos.

Há várias forma de classificação de defeitos, algumas mais detalhadas do que outras, porém todas com o mesmo propósito.

A mais abrangente é fornecida por Beizer 1 , cuja classificação é apresentada resumidamente a seguir.

Tabela 7-3 - Classificação de Defeitos

Tipos de Defeitos Funcionais

Sub-Tipos Requisitos Incorretos Completeza dos Requisitos Verificabilidade dos Requisitos Documentação dos Requisitos Mudanças de Requisitos

Implementação de Funções Acertos na Implementação Completeza das “Features” Completeza de Condições Domínio de Variáveis Mensagens Condições de Exceção

Tabela 7-3 - Classificação de Defeitos (Continuação)

Estruturais Controle do Fluxo do Programa Processamento Dados Definição, Estrutura e Declaração de Dados Tratamento e Acesso aos Dados Implementação Edição de Programas Violação de Padrões de Programação Documentação de Programas Integração Interfaces Internas Interfaces Externas Arquitetura do Software Uso do Sistema Operacional Arquitetura do Software Recuperação de Falhas Desempenho Diagnóstico Incorreto Partição Incorreta Execução do Teste Projeto do Teste Execução do Teste Documentação do Teste Completeza do Teste As medições relativas à gestão da qualidade enquadram-se dentro de cinco categorias: para o monitoramento de defeitos, para a análise de defeitos, para a análise do processo, para a análise de complexidade dos módulos e para a confiabilidade esperada do produto.

A gestão da qualidade dentro deste prisma está intimamente relacionada com o monitoramento do progresso do projeto e de seus aspectos financeiros.

Monitoramento de Defeitos Os objetivos das medições são: ➪ ➪

Verificar o progresso na remoção de defeitos ao longo do calendário de execução do projeto Verificar os desvios entre o realizado e as estimativas

Progresso na Remoção de Defeitos Objetivo: Verificar o progresso na remoção de defeitos ao longo do desenvolvimento.

Método de Determinação: Plotar o número cumulativo de defeitos identificados ao longo do calendário de execução do projeto.

Fonte de Informações: processo de inspeção e cronograma atualizado do projeto.

Forma de Apresentação: gráfica.

Ação Gerencial: No caso de haver desvio entre defeitos identificados e removidos, o gerente de projeto poderá verificar a produtividade da inspeção ( taxa de inspeção ) , bem como avaliar a produtividade da remoção de defeitos( que é a fase de acompanhamento do processo de inspeção) Exemplo: Defeitos Identificados

Defeitos Removidos

50 40 Defeitos Cumulativos 30 20 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Semanas Figura 7-7

Neste exemplo, entre as semanas 8 e 17 houve atraso na remoção dos defeitos.

Defeitos Restantes Objetivo: Estimar o número de defeitos restantes no projeto a partir do término de uma determinada fase do projeto Métodos de Determinação: aqui podemos vislumbrar dois métodos.

Método #1: Estimativa Atualizada de Defeitos Pré-Release - Defeitos Cumulativos Até a Fase A estimativa atualizada pode ser determinada a partir do cálculo atualizado dos pontos de função do software. Os cálculos dos pontos de função podem ser elaborados ao final do projeto lógico e ao final do projeto físico.

O raciocínio a ser utilizado é o mesmo que foi demonstrado no capítulo 6 em relação à metodologia #1 da Análise Por Pontos de Função.

Método #2: Projeção de defeitos pelo uso da distribuição de Rayleigh.

Como já apresentado na capítulo 6, a distribuição de Rayleigh também pode ser utilizada para estimar o número de defeitos restantes para o projeto, a partir de um determinado ponto no cronograma e considerando a estimativa atualizada de defeitos pré-release. Esta estimativa no caso,

prevê o número de defeitos possíveis para cada um dos meses restantes para o projeto.

Fonte de Informações: processo de inspeção, o qual registra o número cumulativo de defeitos; o cálculo atualizado dos pontos de função do software.

Forma de Apresentação: gráfica e tabular.

Ação Gerencial: De posse de informações sobre o desempenho das inspeções em termos de taxa de preparação e de exame, juntamente com os dados sobre o número de defeitos restantes no global ou mês a mês, até o término do projeto,o gerente do projeto pode avaliar sobre a necessidade de alocar mais recursos para a inspeção ou criar novos pontos de inspeção para aumentar a taxa de detecção de defeitos e assim diminuir a ocorrência de defeitos.

Exemplo: Método #1 Supondo a estimativa atualizada do número de defeitos esperados do software, em função de seu tamanho, em 1000 defeitos e o registro de 500 defeitos até a fase, teríamos 500 defeitos restantes.

Método #2 Supondo a estimativa atualizada do número de defeitos esperados do software em 1000 ; o prazo total do projeto 10 meses; se estivermos no 4o. mês; o 5o. mês é o mês de pico do projeto, pelo uso da distribuição de Rayleigh, os defeitos restantes seriam: 5o. mês 6o. mês 7o. mês 8o. mês 9o. mês 10o. mês

➽ ➽ ➽ ➽ ➽ ➽

122 defeitos 117 defeitos 105 defeitos 89 defeitos 71 defeitos 54 defeitos

➽ Total de 558 defeitos

Desvio da Estimativa de Defeitos Objetivo: Realizar análise de sensibilidade em relação às estimativas de defeitos pré-release esperados.

Método de Determinação: Número de Defeitos Identificados No Período dividido pelo Número de Defeitos Esperados No Período; plotar gráficamente.

Fonte de Informações: processo de inspeção e estimativa atualizada de defeitos esperados.

Forma de Apresentação: gráfica ou tabular.

Ação Gerencial: Caso haja grandes desvios ou desvios sucessivos, o gerente do projeto pode calibrar a expectativa de defeitos restantes a partir do percentual médio do desvio verificado e re-estimar o esforço e custo de retrabalho e alocação de pessoal para inspeção.

Exemplo: Supondo o seguinte “data set”.

Tabela 7-4

Período

Estimativa de Defeitos (ED)

1o. mês 2o. mês 3o. mês 4o. mês 5o. mês 6o. mês 7o. mês 8o. mês 9o. mês 10o. mês

39 74 100 116 122 117 105 89 71 54

Estimativa de Defeitos (EDA) Atualizada

Defeitos Identificados (DI) 50 84 120 117

Relação DI / DE +28% +14% +20% +1%

142 136 122 103 82 63 Média 16%

Neste exemplo, a estimativa de defeitos foi recalibrada com base na variação média da relação DI/DE, ou seja, na mesma proporção.

A mesma tabela poderia ser apresentada de forma gráfica conforme mostra a Figura 7-8 a seguir.

150 Defeitos Cumulativos

130 110 90 70 50 30 1

2

3

ED

4

5

DI

6 Meses

7

8

9

10

EDA

Análise de Defeitos Os objetivos das medições são: ➪ ➪ ➪ ➪

Identificar a composição dos defeitos Identificar as classes de defeitos Verificar a distribuição dos defeitos por fase do projeto Verificar o número de defeitos por módulo do software, bem como sua distribuição

Composição dos Tipos de Defeitos Na Fase Objetivo: Identificar a frequência do tipo de defeito por fase do projeto.

Método de Determinação: ∑ Tipo de Defeito na Fase dividido pelo ∑ Número de Defeitos na Fase. Realizar esta operação para cada um dos tipos de defeitos identificados na fase.

Fonte de Informações: Processo de inspeção.

Forma de Apresentação: gráfica Ação Gerencial: Conforme for a frequência, em termos percentuais, dos tipos de defeitos na fase, o gerente deve selecionar aqueles tipos de defeitos que apresentaram maior ocorrência para fins de análise de suas causas, visando criar contra-medidas para a eliminação ou redução de sua ocorrência.

Exemplo: Supondo a fase de especificação.

80% 70% 60% Frequência

50% 40% 30% 20% 10%

RI

DO VP Tipos de Defeitos Figura 7-9

DE

Legenda: RI - Requisitos Incorretos DO- Documentação dos Requisitos VP- Violação de Padrões DE- Definição de Estrutura de Dados

Composição de Defeitos Até a Fase Objetivo: Identificar a frequência do tipo de defeito até a fase do projeto.

Método de Determinação: ∑ Tipo de Defeito até a Fase dividido pelo ∑ Número de Defeitos até a Fase. Realizar esta operação para cada um dos tipos de defeitos identificados na fase.

Fonte de Informações: Processo de inspeção.

Forma de Apresentação: gráfica Ação Gerencial: Analisar as causas dos defeitos de maior frequência, bem como comparar a intensidade dos tipos de defeitos ao longo do projeto. Caso um tipo de defeito persistir em termos de frequência, o gerente pode decidir quanto à ênfase das inspeções.

Exemplo: Especificação

Projeto Detalhado

70% 60% Figura 7-10 50% 40% 30% 20% 10% RI DO VR Legenda: RI - Requisitos Incorretos DO - Documentação dos Requisitos

DE

RI

DO

VR

DE

VR- Verificabilidade dos Requisitos DE - Definição de Estrutura de Dados

A Figura mostra que houve uma melhoria na intensidade e foco das inspeções na fase de Projeto Detalhado.

Composição das Classes de Defeitos Objetivo: Identificar as classes de defeitos por fase e até a fase, a partir da decomposição dos tipos de defeitos.

Método de Determinação: ∑ Classe de Defeito de um Tipo de Defeito dividido pelo ∑ Tipo de Defeito. Realizar esta operação para cada um dos tipos de defeitos identificados , decompondo-os em classes de defeitos.

Fonte de Informações: Processo de inspeção.

Forma de Apresentação: gráfica Ação Gerencial: Verificar as causas dos defeitos relativas ao tipo de defeito que apresentou maior frequência durante a fase ou até a fase.

Exemplo: Supondo a defeito RI - Requisitos Incorretos, conforme a Figura 7-11.

50% 40% Frequência

30% 20% 10% Esquecido Incorreto Extra Classes de Defeitos Figura 7-11

Distribuição de Defeitos Por Módulo do Software Objetivo: Identificar os módulos candidatos a serem propensos a erros ( módulos com erros crônicos).

Método de Determinação: Plotar o número de defeitos por módulo do software.

Fonte de Informações: Processo de inspeção e diagrama hierárquico do sistema ( de forma simplificada, os módulos do software são as Unidades de Implementação conforme o Diagrama de Estrutura de Sistema ou DHS.) Forma de Apresentação: tabular ou gráfica.

Ação Gerencial: A distribuição indica o(s) módulo(s) com possibilidade de serem propensos a erros; neste caso o gerente pode decidir monitorar mais de perto os referidos módulos ou reprojetá-los ou refazê-los.

Exemplo: Supondo a distribuição dos defeitos conforme a Tabela a seguir e considerando que os defeitos identificados o foram pela inspeção dos projetos de programas.

Tabela 7-5

Módulo 1 2 3 4 5 6 7 8 9 10 Total

Defeitos Identificados 30 20 10 50 30 20 60 70 10 5 305

Frequência 10% 7% 3% 16% 10% 7% 20% 23% 3% 2%

Neste exemplo o gerente do projeto deveria concentrar-se nos módulos 4,7 e 8 pois representam mais de 50% dos defeitos identificados.

Análise do Processo Os objetivos das medições são: ➪ ➪ ➪

Avaliar a eficiência das inspeções Identificar módulos propensos a erros Avaliar possíveis desvios da densidade de defeitos padrão

Densidade de Defeitos da Inspeção Objetivo: Verificar o desempenho das inspeções, comparativamente ao padrão de densidade de defeitos da instalação, bem como avaliar a melhoria do processo de inspeção.

Método de Determinação: Número de Defeitos Identificados dividido pelo Número de Linhas do Material Inspecionado.

Geralmente procura-se normalizar esta relação por 1000 linhas, ou referentes a documentos de especificação ou a instruções fontes. Para se elaborar a normalização utiliza-se a regra de três. Exemplo: 40 defeitos encontrados em 400 linhas inspecionadas de um produto intermediário, significa uma densidade de 100

defeitos por 1000. A fórmula é : ( No. de Defeitos Identificados x 1000) dividido pelo Número de Linhas Inspecionadas.

Para analisar o processo , no caso o desempenho das inspeções, uma alternativa é a utilização das técnicas de controle estatístico, mais especificamente através do gráfico de controle.

O gráfico de controle, utilizando a definição dada por Feigenbaum 7,é um método gráfico para avaliar se um processo está ou não sob controle estatístico.

Esta ferramenta permite comparar a variação da densidade de defeitos dentro de limites aceitáveis.

Existem uma série de tipos de gráficos de controle, cada tipo para atender uma situação específica.

No caso do controle estatístico da densidade de defeitos em produtos de software, utiliza-se o gráfico de “Número de Não- Conformidades por Unidade (u)”, ou seja, várias não conformidades independentes (defeitos) podem ocorrer em uma unidade do Produto (documento de especificação do projeto ou módulo do software em instrução fonte). O tamanho de cada subgrupo (n) e o conjunto de unidades pode variar.

A determinação do gráfico de controle é dada então por: ➪

Determinação da média de não-conformidades _ u = ∑ de não-conformidades (defeitos) ∑ do no. de unidades (linhas) inspecionadas

➪ Determinação do Limite Superior de Controle - LSC e do Limite Inferior de Controle - LIC _ LSC = u + 3

_ LIC = u - 3

_ u n _ u n

A forma de representação do gráfico é:

LSC média LIC

Figura 7-12

Caso os valores de densidade de defeitos estiverem dentro dos limites, considerase que o processo está sob controle estatístico.

Fonte de Informações: Processo de inspeção.

Forma de Apresentação: gráfica.

Ação Gerencial: Valores de densidade de defeitos acima do LSC indicam produtos “propensos a erros”; valores abaixo do LIC indicam produtos “mal inspecionados”. Para análise dos indícios, o gerente do projeto deve analisar o desempenho das respectivas inspeções ( “cujas densidades estão fora dos limites”) em termos de taxas de preparaçào e de exame, verificando se estão dentro dos padrões, assim como o tamanho do produto inspecionado.

Exemplo: ➪

Densidade de defeitos de uma inspeção 100 defeitos encontrados tamanho do produto inspecionado = 1500 linhas densidade = ( 100 x 1000) ÷ 1500 = 66.67 ou 67 defeitos por 1000 linhas.

➪

Confrontar a densidade de defeitos do produto com os limites padrões da instalação para uma dada combinação de plataforma de hardware/software e metodologia ( processo de desenvolvimento).

80 70 ▲ densidade = 67 60 50

LSC

40 30

média

20 10

LIC Figura 7-13

Neste exemplo o produto inspecionado está com indícios de ser “propenso a erros. ➪ Todo o processo de inspeção, ocorrido até um determinado ponto do calendário do projeto, pode ser comparado com os limites padrões da instalação.

Término do Projeto Detalhado•

80 70 60 50 40

LSC

▲ ▲ ▲

30

▲

média

▲

20

LIC

10

▲

1

2

3

4

5

6 Figura 7-14

Neste exemplo as inspeções 4 e 5 deveriam ser analisadas para verificar as causas da variação observada.

Densidade de Defeitos Na Fase Objetivo: Verificar o nível de defeitos introduzidos na fase do projetoe compará-lo aos padrões de controle da instalação.

Método de Determinação: Similar ao aplicado para a densidade de defeitos da inspeção, porém deve-se considerar a média da densidade de defeitos das inspeções realizadas na fase.

Fonte de Informações: Processo de inspeção.

Forma de Apresentação: gráfica.

Ação Gerencial: Caso a densidade de defeitos estiver fora dos limites de controle, o gerente do projeto deverá avaliar os produtos gerados na fase, visando determinar os que mais contribuíram para a variação verificada. Esta ação é fundamental nas fases iniciais do projeto visto que 81% dos defeitos no software têm sua origem na especificação.

Exemplo: Similar ao anterior aos exemplos anteriores.

Densidade de Defeitos Por Módulo do Software Objetivo: Identificar os módulos considerados como “propensos a erros”.

Método de Determinação: Quando da inspeção dos módulos componentes do software ( rotinas e programas) ou das Unidades de Implementação ( conjunto de •

O gráfico foi feito para fins de ilustração do exemplo, não baseando-se em dados reais.

módulos) , determinar as densidades de defeitos respectivas.As inspeções neste caso podem ser feitas com base nos projetos de programas ( em português estruturado por exemplo) ou com base nos resultados dos testes individuais de cada programa ou da Unidade de Implementação.

A instalação pode construir gráficos de controle exclusivamente para as inspeções de projetos de programas e de código, cujos resultados de densidade de defeitos constituiriam um “data set” específico , dentro dos padrões do processo como um todo.

Fonte de Informações: Processo de inspeção e documentos de estrutura do sistema que permita identificação de módulos ou Unidades de Implementação.

Forma de Apresentação: gráfica ou tabular.

Ação Gerencial: Módulos ou Unidades de Implementação que apresentarem variação fora dos limites de controle devem ser revisados.

Exemplo: Supondo a seguinte distribuição de densidade de defeitos conforme os módulos de um sistema hipotético.

Tabela 7-6

Módulos 1 2 3 4 5

Densidade 33.70 67.00 23.30 35.00 27.00

Caso os módulos 1,3,4 e 5 estivessem dentro dos limites de controle, a gerência deveria analisar detidamente o módulo 2 a fim de reduzir sua densidade de defeitos, colocando-a dentr dos limites de controle.

Eficiência da Remoção de Defeitos do Processo de Inspeção Objetivo: Medir a eficiência do processo de inspeção até a fase de teste integrado.

Método de Determinação: A medição da eficiência é dada pela seguinte expressão: ∑ dos Defeitos Identificados Até a Fase de Teste Integrado sobre o ∑ dos Defeitos Identificados Até a Fase de Teste Integrado + ∑ dos Defeitos Identificados Durante a Fase de Teste Integrado.

Fonte de Informação: Processo de inspeção e relatório de defeitos do teste.

Forma de Apresentação: sem forma específica.

Ação Gerencial: Caso a eficiência do conjunto de inspeções for baixa, o gerente deve procurar indícios de mudanças de requisitos não registradas e aceitas pela equipe sem a devida comunicação ou reforçar os recursos para a inspeção do teste integrado ou analisar os módulos com maior propensão a erros pois devem ser os causadores da baixa eficiência. Outra alternativa seria analisar a complexidade dos módulos. Conforme estatísticas , cerca de 12% dos módulos de um sistema representam 50% do esforço de manutenção.

Exemplo:

Considera-se como baixa eficiência , índice menor que 70%.

Supondo 1000 defeitos encontrados até a fase de teste integrado e 300 defeitos encontrados durante o teste integrado: A eficiência da remoção de defeitos da inspeção neste caso seria de 77%, portanto aceitável.

Aqui o gráfico de controle também se aplica caso a instalação registrar as eficiências obtidas por projetos passados.

Taxa de Exame Por Inspeções Objetivo: Verificar se a taxa de exame dos produtos inspecionados está dentro dos limites de controle da instalação.

Método de Determinação: Aqui também se aplica o gráfico de controle. A taxa de exame é medida em linhas por hora. Para cada inspeção deve-se determinar a taxa de exame. Após determinar a média e aplicá-la nas fórmulas de LSC e LIC já apresentadas anteriormente.

Fonte de Informações: Processo de inspeção.

Forma de Apresentação: gráfica.

Ação Gerencial: Esta análise serve de base para a avaliação do desempenho das inspeções. Geralmente produtos grandes despendem um maior tempo de exame assim como de preparação. A relação entre taxa de preparação e de exame é proporcional e linear. É muito provável que produtos de tamanho aproximado e que apresentaramm grande variação de densidade de defeitos, experimentaram taxas de exame diferentes. Isto pode ser um indicativo de que a inspeção não foi realizada dentro dos padrões preconizados.

Exemplo: 550 500 450 400 ▲ 350

LSC ▲

300

▲

250

▲

▲ média

200

▲

▲

100

▲ ▲

50 1

2

3

4

5 6 Figura 7-15

7

8

9

Neste exemplo as taxas de exame das inspeções 1 e 5 estão fora dos limites de controle padrões da instalação.

Taxa de Preparação Por Inspeção Objetivo: Verificar o padrão de desempenho da preparação das inspeções.

Método de Determinação: A taxa de preparação também é medida em linhas por hora. O gráfico de controle pode ser aplicado. O cálculo da média e limites segue a fórmula já tratada.

Fonte de Informações: O processo de inspeção e registros de tempos de preparação para cada produto inspecionado.

Forma de Apresentação: gráfica.

Ação Gerencial: Analisar a inspeção cuja taxa de preparação está fora dos limites de controle. Verificar o tamanho dos produtos e respectivas densidades de defeitos visando tomar a decisão de reinspecionar ou não o produto.

Exemplo: Similar ao anterior.

Tamanho do Material Inspecionado Por Inspeções Objetivo: Apoiar a análise do desempenho da inspeção, juntamente coma as análises das taxas de preparação e exame.

Método de Determinação: O tamanho do produto é expresso em número de linhas. Plotar um gráfico com o tamanho do material para cada inspeção correspondente. Uma forma de análise é a de estabelecer a média do tamanho do material inspecionado e um limite de + 2 desvios padrões a partir da média.

Tamanho que se distancia muito da média ou que ultrapassem os 2 desvios padrões podem ser objeto de análise mais apurada.

Fonte de Informações: Processo de inspeção e registro do tamanho do material inspecionado.

Forma de Apresentação: gráfica ou tabular.

Ação Gerencial: Esta análise auxilia na avaliação do desempenho das inspeções, juntamente com as informações sobre taxas de preparação e exame. Materiais de grande volume exigem maior tempo de preparação e exame. Caso esta relação não for verificada, há indícios de material “mal inspecionado”. Material “mal inspecionado “provavelmente significa baixa densidade de defeitso, com probabilidade de estas abaixo do LIC. Exemplo: 700

▲

600 + 2σ Tamanho

500

do Material

400

▲ ▲

▲

▲

300 ▲

200 100 1

2

3

5 Inspeções Figura 7-16

6

7

Medição Para a Análise de Complexidade O objetivo dessa medição é o de subsidiar a gerência quanto a definição de estratégias para a redução de complexidade dos módulos do software. A redução da complexidade dos módulos reduz a probabilidade da introdução de defeitos no produto.

Objetivo: Analisar a complexidade do projeto do módulo ( ou programa) visando otimização.

Método de Determinação: Método #1 - Complexidade Ciclomática Esta métrica, introduzida por McCabe 10, foi desenvolvida para quantificar a complexidade do fluxo de controle do programa.

A métrica deriva da representação gráfica do fluxo de controle do programa.

A fórmula para a complexidade ciclomática de McCabe é dada pela expressão: M = L - N + 2P onde: M = complexidade ciclomática L = número de ligações no gráfico P = número de chamadas (calls) para outros programas ou subrotinas McCabe recomenda que a complexidade ciclomática para um programa não deve ultrapassar 10.

Existem fortes evidências de que quanto maior a complexidade ciclomática, maior a taxa de erros introduzidos nos módulos 5.

Método #2 - Modelo de Card & Glass Card & Glass 5, desenvolveram outro modelo para medir a complexidade de um módulo. A quantificação da complexidade é dada pela expressão: 2

c= f

+ v ÷ (f + 1)

onde: c = complexidade do módulo f = “fanout” do módulo v = variáveis de I/O usadas pelo módulo

sendo que: ➽ “fanout” é a contagem do número de “calls”de um dado módulo 2 ➽ v = 2f (f + 1 ) De acordo com estes autores, o número de “fanouts” necessários para otimizar a complexidade varia de 0 a 3.

Com 3 “fanouts” a complexidade aceitável é 33.

Fonte de Informações: Documentos de projeto, de programas, listagens de programas, analisadores de complexidade.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: De acordo com o método #1, um módulo com complexidade ciclomática superior a 10 deve ser re-analisado ou reprojetado. O mesmo ocorre com complexidade superior a 33 no caso do modelo de Card & Glass.

As ações visando a redução da complexidade são: ➪ “fanout” deve ser mantido em tr6es ou menos ➪ minimizar as variáveis de I/O tratadas pelo módulo ➪ aumentar a eficiência do projeto pelo uso de inspeções, programação estruturada e gerência de configuração ( controle de versões).

Exemplo: Método#1 Supondo o seguinte fluxo de programa:

L=4 N= 5 P = 1 M = ( 4-5) + 2 = 1 Módulo está em nível aceitável de complexidade.

Método #2 Supondo um módulo com “fanout” = 5 2

v = 2 x 5 (5 + 1 ) v = 360 c = 25 + ( 360/6) = 85 Módulo que deverá ser revisto.

Estabelecimento de Objetivos de Intensidade de Falhas Objetivos de intensidade de falhas podem ser estabelecidos para o software quando da realização do teste integrado do mesmo.

Ao estabelecer estes objetivos pode-se determinar o número de falhas e tempo adicionais para atingimento do objetivo.

A determinação destes requisitos é dada pela disciplina de Confiabilidade ( Reliability), cuja aplicação na área de software foi desenvolvida e divulgada por Musa, Iannino & Okumoto 12 . Devido a complexidade do assunto, nos deteremos em algumas medições básicas derivadas dos modelos preconizados por estes autores.

Falhas Adicionais Esperadas Para Atingir o Objetivo de Intensidade Objetivo: Estimar o número de falhas adicionais a serem experimentadas pelo software até o atingimento do objetivo de intensidade de falhas.

Método de Determinação: O cálculo para determinação das falhas adicionais é dado pela expressão: ∆µ =

Vo λo

 λp - λf 

onde: ∆µ

número de falhas esperadas para atingimento do objetivo de intensidade de falhas Vo ➽ número de falhas observadas até um tempo T do teste λo ➽ intensidade de falhas inicial por CPU hora λp ➽ intensidade atual de falhas em CPU hora λf ➽ objetivo de intensidade de falhas em CPU hora Fontes de Informações: Registros de falhas experimentadas pelo software durante o teste integrado.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: O atingimento do objetivo de intensidade de falhas permite a release do software para o teste de aceitação pelo cliente/usuário ou, dependendo das circunstâncias, a entrega do produto para a operação normal.

Exemplo: Supondo a intensidade de falhas inicial em 10 CPU hora, um objetivo de intensidade de falhas de .10 CPU hora, 200 falhas observadas até o momento e a intensidade de falhas atual em 5 CPU hora: ➽

∆µ = 200 / 10  5 - .10  = 98 falhas adicionais Tempo de Execução Adicional Esperado Para Atingimento do Objetivo de Intensidade Objetivo: Estimar o tempo de execução adicional necessário para atingir o objetivo de intensidade de falhas.

Método de Determinação: O cálculo do tempo de execução adicional é dado pela expressão:

∆τ = onde:

Vo λo

Ln

λp λf

∆τ ➽ tempo de execução adicional Vo ➽ número de falhas observadas λo ➽ intensidade inicial de falhas Ln ➽ logaritmo neperiano λp ➽ intensidade de falha atual λf ➽ objetivo de intensidade Fontes de Informações: Registros de falhas durante a execução do software.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Idem ao item anterior.

Exemplo: Supondo os mesmos dados do exemplo anterior: ∆τ = 200/10 Ln ( 5/.1) = 20 Ln ( 50 ) = 20 x 3.91 = 78,20 CPU hora ⌦

Medições Para o Monitoramento do Progresso

O monitoramento do progresso de um software somente pode ser verificado através da conclusão dos produtos intermediários que, ao longo do processo , vão sendo disponibilizados. O término de um produto intermediário significa produto aprovado pelo processo de inspeção.

O monitoramento do progresso também está associado à gestão financeira e de recursos, pois variações no prazo têm impacto imediato quanto ao esforço e custos do projeto.

Outro aspecto a ser considerado é quanto ao replanejamento do projeto, o qual deriva da estimativa atualizada do tamanho do software e da estimativa atualizada do prazo.

Portanto , as medições quanto ao monitoramento do progresso do projeto abrangem os aspectos de: controle do progresso e replanejamento.

Controle do Progresso Os objetivos das medições são: ➪ ➪

Verificar o progresso na elaboração dos produtos previstos Acompanhamento físico do projeto

Progresso na Elaboração de Produtos Objetivo: Verificar o progresso na elaboração de produtos intermediários do projeto, bem como as variações que possam levar a um replanejamento do mesmo.

Método de Determinação: Em função do cronograma do projeto, deve-se identificar os prazos de liberações (entregas) dos produtos previstos conforme o que preconiza o processo de desenvolvimento selecionado para o software.

Plotar em um gráfico a previsão de entrega do produto, ao longo do tempo, juntamente com o esforço também previsto para o produto. Registrar no gráfico, o prazo efetivo de liberação do produto com o esforço correspondente realizado.

Fontes de Informações: Sistema automatizado de gerência de projetos ( “project tracking “), estimativas de prazos e esforço oriundas do planejamento e registros de prazo e esforço realizado.

Forma de Apresentação: gráfica.

Ação Gerencial: Caso houver variação positiva no que tange aos prazos planejados ( atuais) , o gerente do projeto deve verificar o esforço adicional necessário para manter o prazo sob controle ou decidir pelo replanejamento do projeto.

Exemplo: Supondo a estimativa inicial de prazo e esforço e respectivos produtos: Tabela 7-17

Produto

Prazo

Esforço

Projeto Preliminar Projeto do Produto Programas Testados Sistema Integrado

2 meses 3 meses 9 meses 4 meses

9 homens/mês 23 homens/mês 90 homens/mês 32 homens/mês

Esforço Acumulado 200 190 180 170 160 150 140 130 120 110 100 90 80 70 60 50 40 30 20 10 ▲ 1 2 3 4

Figura 7-17

● ▲

● ▲ ▲

5 6 7 8 9 10 11 12 13 14

Legenda: Produto Esperado ▲ Esforço Realizado x Prazo Produto Concluído ●

15

16

17 18 meses

Esforço Previsto x Prazo Esforço Acumulado x Prazo

Pelo exemplo podemos verificar que houve variação para a elaboração do produto previsto para o quinto mês e para o décimo quarto mês, com as consequências no esforço, que aumentou substancialmente. De forma simplificada , deveríamos duplicar o esforço na fase final, de 32 homens/mês para 64, ou seja, mais 8 pessoas deveriam ser agregadas ao projeto. Entretanto, em fases finais isto é muito difícil. Supondo que o prazo é factível de ser atingido em relação à fase de Integração e Teste , o projeto atrasaria pelo menos por 2 meses.

Acompanhamento Físico do Projeto Objetivo: Verificar o andamento do cronograma do projeto.

Método de Determinação: A maioria dos software-produto de gerenciamento de projetos, tal como o MS-Project , possuem as ferramentas necessárias, uma vez devidamente alimentado, para a geração de cronogramas e comparação do previsto contra o realizado. Este pacotes possuem vários tipos de saídas para a visualização do andamento físico, sendo um dos principais o gráfico de Gantt.

Fonte de Informações: Sistema gerenciador de projetos (“project tracking”).

Forma de Apresentação: gráfica.

Ação Gerencial: O gráfico de Gantt geralmente permite a visualização genérica do progresso do projeto. Mostra os prazos previstos e realizados e, se houver, a nova estimativa de prazo, ou seja, o prazo restante.

Exemplo: Figura 7-18

Fases jan

fev

mar

Meses abr mai

jun

jul

Planejamento

Especificação

Projeto

Codificação

Teste

Implantação

Legenda: Prazo Inicialmente Estimado Prazo Realizado Efetivamente Prazo Estimado Atualizado

Medições Para o Replanejamento Os objetivos dessas medições são: ➪ ➪ ➪

Possibilitar elaborar as estimativas atualizadas do prazo do projeto Avaliar as estimativas de prazo do projeto Atualizar a estimativa de tamanho do software

Estimativa Atualizada do Tamanho do Software

ago

Objetivo: Elaborar estimativa atualizada do tamanho do software visando o replanejamento do projeto.

Método de Determinação: Ao final da Especificação ( Projeto Lógico) e do Projeto Detalhado ( Projeto Físico) deve-se elaborar nova contagem dos Pontos de Função, considerando, no entanto, a metodologia # 1 de contagem.

Fonte de Informações: Documentos de especificação e do projeto detalhado.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Com a nova estimativa de tamanho, o gerente deve realizar nova estimativa de prazo, esforço e custo para o projeto.

Exemplo: Vide capítulo 6.

Estimativa Atualizada de Prazo Objetivo: Elaborar nova estimativa de prazo para o projeto e para as fases do projeto.

Método de Determinação: Deve ser utilizado o mesmo método já apresentado no capítulo 6. Com a nova estimativa do tamanho , ou se realiza a interpolação no “data set” de dados históricos de projetos ou emprega-se o modelo COCOMO, o qual inclusive permite realizar estimativas de prazo por fase. Com os novos valores de prazo, deve-se deduzir o prazo já realizado, determinando assim o prazo restante. Com esta abordagem, o prazo restante poderá ser estimado a partir do término da fase de especificação ou das fase de projeto detalhado. É importante notar que todas as estimativas apresentadas no capítulo 6 poderão ser re-elaboradas.

Fontes de Informação: Documentos do projeto e nova estimativa do tamanho.

Forma de Apresentação: gráfica Ação Gerencial: Conforme o nível da variação entre o estimado inicialmente e a nova estimativa, o gerente poderá alocar mais recursos ao projeto, por exemplo, programação, nos processos de inspeção, aumentar a frequência das inspeções ou realzar nova negociação com o cliente/usuário quanto ao replanejamento.

Neste caso deverá ser emitida versão atualzada do Planejamento do Projeto.

Exemplo: O prazo restante poderá ser apresentado em forma de gráfico de Gantt, conforme o exemplo da medição - Acompanhamento Físico do Projeto.

Exatidão da Estimativa de Prazo da Fase Objetivo: Analisar a variação do realizado com as estimativas e prover meios de controlar o processo de desenvolvimento.

Método de Determinação: A exatidão da estimativa de prazo da fase é dada pela expressão: Prazo Realizado Na Fase (meses/semanas etc.) ÷ Prazo Estimado Para a Fase. Caso a instalação tiver o grafico de controle relativo à exatidão de estimativas, o resultado poderá ser cotejado com os limites de controle.

Fonte de Informação: Registros de estimativas e cronograma atualizado.

Forma de Apresentação: gráfica caso comparar com os limites de controle.

Ação Gerencial: Caso o índice de exatidão estiver forma dos limites de controle ou muito distante da média geral ou específica para a fase em análise, o gerente deve determinar as causas da variação, as quais geralmente são qualitativas, ou

baseadas no perfil da equipe ( técnica e de usuários), ou no ambiente de trabalho, ou nos métodos utilizados, ou nos equipamentos e assim por diante.

Exemplo: Supondo a estimativa inicial para uma determinada fase em 5 meses e o prazo realizado em 7 meses. A exatidão da estimativa é de 1.4, o que significa que houve uma variação de + 40% no prazo estimado. Caso os limites de controle forem 30% e 20% , dever-se-ia analisar as causas da variação. ⌦

Medições Para a Gestão de Recursos e Financeira

Decidimos agrupar ambos conjuntos de medições pois os custos do projeto são determinados em grande parte pelo esforço alocado ao projeto.

O objetivo básico da gestão de recursos e financeira do projeto é perseguir a redução do seu custo global. É óbvio que a esse tipo de gestão é dependente da gestão da qualidade e do controle do progresso.

Da gestão da qualidade porque minimiza o esforço de retrabalho, consequentemente otimizando o atingimento dos prazos e reduzindo o custo do projeto, pela redução do custo do retrabalho.

Do controle do progresso pois fornece informações acerca das possibiidades de atraso, consequentemente das possibioidades de aumento de esforço e custo correspondente.

Medições Para o Monitoramento da Alocação de Recursos Os objetivos dessas medições são: ➪ ➪

Elaborar estimativas atualizadas de esforço Elaborar estimativas atualizadas de alocação de recursos

Estimativa Atualizada de Esforço Objetivo: Elaborar estimativa atualizada do esforço a fim de determinar nova alocação de recursos e subsidiar a nova estimativa de custo do projeto.

Método de Determinação: A partir da estimativa atualizada do tamanho do software e com o emprego do método COCOMO pode-se determinar a necessidade de esforço adicional. Para tanto deve-se deduzir da estimativa atualizada o esforço já realizado. O modelo COCOMO já emprega a distribuição de Rayleigh, portanto ela não necessita ser empregada.

Fonte de Informações: Estimativa atualizada do tamanho do software, registros do esforço realizado.

Forma de Apresentação: tabular.

Ação Gerencial: De posse da nova estimativa, o gerente deve determinar a necessidade por rever a alocação de recursos humanos ao projeto, nas fases subsequentes, bem como elaborar nova estimativa de custos.

Exemplo:

Supondo que a estimativa inicial fosse de 400 Pontos de Função em Cobol e que a nova contagem , realizada ao final do projeto lógico, seja de 500 Pontos de Função.

Utilizando a transformação de FP’s para instruções fontes e a fórmula de esforço do método COCOMO para projetos do tipo orgânico, teríamos respectivamente as seguintes previsões de esforço: 110,23 H/M para 400 PF’s e 140,10 H/M para 500 PF’s e a distribuição do esforço por fase conforme a tabela abaixo.

Tabela 7-18

Fase Planejamento Projeto do Produto Programação Integração e Teste

Estimativa Inicial 6,24 16.64 64,32 23,03

Estimativa Atual

Variação

86,27 31,41

+ 34% + 36 %

Haveria um acréscimo de 30,33 H/M de esforço em relação a estimativa inicial.

Estimativa Atualizada de Alocação de Recursos Objetivo: Elaborar estimativa atualizada do número de profissionais com alocação integral ao projeto, em função da estimativa atualizada de esforço.

Método de Determinação: A determinação do número de profissionais a serem alocados é dada pela expressão: Esforço Atualizado Por Fase do Projeto dividido pelo Prazo Atualizado da Fase.

Fonte de Informações: Estimativa atualizada de esforço e prazo.

Forma de Apresentação: tabular.

Ação Gerencial: Esta previsão atualizada do número de profissionais a serem alocados é útil quando estamos no início do projeto ou na fase de especificação e projeto detalhado. É útil também para determinarmos o número de programadores necessários. Porém para que a programação inicie sem problemas é importante administrarmos o gargalo representado pelo esforço necessário para a elaboração dos projetos dos programas. Entretanto na fase de integração e teste e mesmo de implantação não é recomendável adicionar mais recursos humanos ao projeto.

Neste caso a tendência é de atrasar mais ainda o projeto. Se seu projeto estiver na fase de programação e for feito uma nova estimativa de pessoal para as fases seguintes e essa estimativa indicar que o projeto deve alocar mais pessoal, negocie com a equipe atual o aumento da carga de trabalho ou assuma o atraso do projeto.

Exemplo: Vide capítulo 6 quanto a estimativa de determinação de pessoal por fase do projeto.

Exatidão da Estimativa de Esforço da Fase Objetivo: Analisar a variação do realizado com as estimativas e prover meios de controlar o processo de desenvolvimento.

Método de Determinação: A exatidão da estimativa de esforço da fase é dada pela expressão: Esforço Realizado Na Fase ( homems/mês) ÷ Esforço Estimado Para a Fase. Caso a instalação tiver o grafico de controle relativo à exatidão de estimativas, o resultado poderá ser cotejado com os limites de controle.

Fonte de Informação: Registros de estimativas , cronograma atualizado e registros de esforço realizado.

Forma de Apresentação: gráfica caso comparar com os limites de controle.

Ação Gerencial: Caso o índice de exatidão estiver forma dos limites de controle ou muito distante da média geral ou específica para a fase em análise, o gerente deve determinar as causas da variação, as quais geralmente são qualitativas, ou baseadas no perfil da equipe ( técnica e de usuários), ou no ambiente de trabalho, ou nos métodos utilizados, ou nos equipamentos e assim por diante.

Exemplo: Supondo a estimativa inicial para uma determinada fase em 30 homens/mês e o esforço realizado em 40 homem/mês. A exatidão da estimativa é de 1.3, o que significa que houve uma variação de + 30% no esforço estimado. Neste exemplo a variação está dentro dos limites de controle . Entretanto pode haver necessidade de replanejar o projeto caso o nível de variação para outras fases persistir.

Medições Para o Monitoramento Financeiro do Projeto Os objetivos dessas medições são: ➪ ➪ ➪

Acompanhar financeiramente o projeto Realizar estimativas atualizadas do custo do projeto Analisar o comportamento dos custos de retrabalho

Acompanhamento Financeiro do Projeto Objetivo: Acompanhar a evolução dos custos do projeto em relação ao orçado e verificar o valor ganho até estágio que se encontra o projeto no cronograma.

Método de Determinação: Comparar, ao longo do cronograma do projeto, os custos realizados com os custos orçados. Determinar o valor ganho subtraindo o custo orçado (atualizado) com o custo realizado.

Fonte de Informações: Sistema de gerenciamento de projetos ou registros das estimativas de custo e do custo realizado.

Forma de Apresentação: gráfica.

Ação Gerencial: Este acompanhamento é importante para o gerente definir estratégias que possam conduzir o projeto dentro dos limites orçamentários, bem como simular impactos financeiros no projeto decorrente de atrasos ou de aumento de esforço.

Exemplo: Com uma representação deste tipo a gerência rapidadmente visualiza: ➪ ➪ ➪

que houveram duas atualizações da estimativa inicial , uma na semana 25 e outra na 35. o progresso do custo real do projeto ao longo do tempo. as tendências do custo restante a ser realizado

➪

o progresso do valor ganho ou das economias obtidas custo 1500 Custo Estimado Total

1000

500 Custo Orçado 300

Custo Realizado Valor Ganho

100

0

5

15 20 25 30 Semanas desde o início do projeto Figura 7-19

35

40 Hoje

45

50

55

Estimativa Atualizada do Custo do Projeto Objetivo: Determinar o custo atualizado do projeto em função de um replanejamento ocorrido.

Método de Determinação: (Esforço Estimado Para as Fases Restantes x Custo Médio do Homem/Mês) + Parcela de Rateio de Outros Custos Diretos e Indiretos Alocados às Fases Correspondentes. A maioria dos pacotes de gerenciamento de projetos, uma vez que sejam devidamente alimentados, reprogramam o orçamento do projeto.

Fontes de Informação: Sistema de Controle de Custos ou composição percentual da parcela de rateio sobre o custo total do projeto mais o registro do custo médio do homem/mês ou o registro do custo de cada recurso humano alocado à fase correspondente do projeto. ( Vide capítulo 6 quanto a determinação do custo do projeto).

Forma de Apresentação: gráfica Ação Gerencial: Se sua empresa trabalhar na filosofia de transferência de preços entre unidades é necessário negociação com o cliente/usuário. Essa negociação pode ser conduzida com tranquilidade se o gerente do projeto seguir rigorosamente os preceitos da boa gerência de projetos, ou seja, registrar as ocorrências, as solicitações de mudanças no escopo do projeto, houverem as reuniões de avaliação de progresso, isto é, se puder comprovar as causas de aumento de esforço.

Exemplo: Pode ser utilizada uma representação similar a do exemplo anterior.

custo 1500 1000

500

300

Custo Orçado Custo Realizado

100

Integração & Teste Planejamento Programação

Implantação

Especificação Projeto Detalhado Figura 7-20

Neste exemplo , em função da estimativa atualizada de prazo e esforço, os custos são reprojetados a partir da fase de Programação.

Comportamento do Custo de Retrabalho Objetivo: Analisar o comportamento do custo de retrabalho ao longo do projeto.

Método de Determinação: O custo de retrabalho é determinado pela seguinte expressão: Esforço de Retrabalho x Custo Médio do Homem/Hora. O custo de retrabalho da fase é : ∑ do Esforço de Retrabalho na Fase x Custo do Homem/Hora.

Fonte de Informações: O processo de inspeção deve fornecer a informação sobre o esforço de retrabalho. Para tanto os registros correspondentes deverão ser realizados.

Forma de Apresentação: gráfica.

Ação Gerencial: O custo de retrabalho está associado ao nível de defeitos que são introduzidos nos produtos do software e que são detectados pelo processo de inspeção. A gestão da qualidade é que atua sobre os custos de retrabalho. Estes custos também podem ser controlados utilizando-se o gráfico de controle.Caso os custos se comportarem fora dos limites de controle ou se houver uma grande dispersão em relação à média, o gerente do projeto deve analisar as causas da variação. O gráfico de controle pode ser construído considerando cada fase do processo de desenvolvimento.

Exemplo: Podemos considerar dois tipos de representação gráfica do custo de retrabalho.

Figura 7-21 100 Planejamento 90

Especificação

80

Projeto Detalhado

70

Programação Teste

60 Implantação 50 40 30 20 10

Legenda: Custo Médio de Retrabalho Custo de Retrabalho Realizado Gráfico de Controle da Fase de Especificação Figura 7-22

50

▲

LSC

35

média LIC

⌦

Medições Para a Gestão de Mudanças

O objetivo básico dessas medições é o monitoramento das mudanças de requisitos solicitadas pelos clientes/usuários ao longo do desenvolvimento do software, bem como identificar as origens dessas mudanças.

A principal medição a ser realizada é relativa a estabilidade dos requisitos. Baixa estabilidade significa que o projeto entra em uma área de “perigo” , podendo comprometer as metas de prazo e custo inicialmente estipuladas.

Monitoramento de Mudanças nos Requisitos Objetivo: Monitorar a ocorrência de mudanças nos requisitos ao longo do desenvolvimento do projeto.

Método de Determinação: Aqui devemos utilizar dois indicadores, quais sejam:

(i) Estabilidade dos Requisitos na Fase e (ii) Crescimento/Mudanças dos Requisitos na Fase. Os requisitos, do ponto de vista do cliente/usuário, geralmente compreendem os aspectos funcionais do software em termos de entradas,saídas, consultas, interfaces ,desempenho e características gerais ( análogas as estabelecidas pelo método de Análise Por Pontos de Função). Considerando o progresso da especificação do software, podemos esperar uma estabilidade muito baixa na fase de Planejamento ou Ante-Projeto. Entretanto a estabilidade a partir da fase de especificação deve ser relativamente alta. Caso for baixa, significa que deveremos refazer grande parte da concepção lógica para atender as necessidades do projeto físico do software. Na fase de implementação a estabilidade tem que ser bastante alta.

Portanto deve-se estabelecer expressões diferenciadas para a fase de Projeto preliminar ou Ante-Projeto e para as demais.

No caso de medição da estabilidade dos requisitos: Para a fase de Projeto Preliminar/Ante-Projeto/Planejamento a expressão é: Mudanças dos Requisitos + Correção de Requisitos dividido pelo Número de Requisitos da Fase de Projeto Preliminar Esta medição somente pode ser feita na fase posterior ou de Especificação (Projeto Lógico).

Para as demais fases a expressão é: Número de Requisitos Adicionados na Fase Atual + Número de Requistos da Fase Anterior Alterados + Número de Requisitos da Fase Anterior Corrigidos dividido pelo Número de Requisitos da Fase Anterior Esta medição é feita na fase de projeto detalhado (Projeto Físico) para medir a estabilidade dos requisitos da fase de Especificação, na fase de Implementação para medir a estabilidade dos requisitos da fase de Projeto Detalhado e assim sucessivamente.

Quanto menor o índice ao longo do desenvolvimento, mais estáveis são os requisitos.

No caso de crescimento/mudanças dos requisitos na fase: As expressões são: Número de Requisitos Adicionados dividido pelo Número Total de Requisitos Número de Requisitos Alterados dividido pelo Número Total de Requisitos Estas medições fornecem uma idéia de crescimento funcional do software ou de adição de características de processamento ou de mudanças nos requisitos.

Fontes de Informação: Documentos de projeto , registros de requisitos e de inclusão/alteração/correção de requisitos.

Forma de Apresentação: tabular e gráfica.

Ação Gerencial: Não existem padrões na literatura sobre este índice. A instalação pode criar seus próprios padrões conforme for o tipo de plataforma de hardware e software e o processo de desenvolvimento. Espera-se baixa estabilidade de requisitos na fase de Projeto Preliminar, grande adição de requisitos na fase de Especificação, alta estabilidade dos requisitos para esta fase e demais. O monitoramento do crescimento ou de alterações de requisitos ao longo da fase permite agir tempestivamente antes do seu término a fim de identificar as causas/ origens do incremento ou da mudança. O monitoramento pode ser realizado considerando o calendário de cada fase do projeto.

Exemplo: Medindo a estabilidade da fase de Especificação: Supondo a adição de 20 requisitos, a alteração de 10 requisitos , a correção de 5 requisitos para um total de 80 requisitos: 1 - (20 + 10 + 5 / 80 ) = 56% Neste exemplo, cerca de 56% dos requisitos foram mantidos. Pode ser considerada como uma baixa estabilidade. No caso de valores negativos considera como estabilidade inexistente. Isto significa que a Especificação foi totalmente alterada.

Medindo o crescimento funcional/processamento e o índice de mudança: Supondo que até um tempo To, dentro da fase de especificação, 100 requisitos funcionais tenham sido definidos e aprovados pelo cliente/usuário e que entre o tempo To e T1 houve um incremento de 30 requisitos. Isto pode ser demonstrado graficamente para fins de monitoramento.

To

T1 130

Neste exemplo o incremento foi de 30%.

100

30

Figura 7-23

A mesma representação pode ser dada para a variação de mudanças nos requisitos.

Origens de Incremento/Mudanças nos Requisitos Objetivo: Identificar as origens de incremento e/ou mudanças nos requisitos.

Método de Determinação: Através dos registros de incrementos e de solicitações de mudanças nos requisitos pode-se identificar as fontes de alteração. Uma das alternativas é identificar os clientes/usuários que concentram a maior parte das solicitações. Dessa forma pode-se construir gráficos de frequência que evidenciem as principais fontes, com possibilidade de desdobrá-los a fim de identificar as verdadeiras causas.

Fontes de Informações: Registros de requisitos, solicitações de mudanças e de incremento.

Forma de Apresentação: gráfica.

Ação Gerencial: Uma vez identificadas as principais fontes de mudanças e/ou incrementos, o gerente do projeto deve tomar ações corretivas a fim de eliminar ou reduzir as fontes de variabilidade.

Exemplo:

Mudanças 50 30 20 10 Marketing

Produção Engenharia Figura 7-24

Vendas

Neste exemplo , para um sistema que envolva 4 áreas da empresa, a principal fonte de alterações é a área de marketing, seguida da produção. Este gráfico poderia ser desdobrado, classificando os motivos de alterações ou incremento cuja origem é o marketing e a produção. Analisando as causas, o gerente de projetos pode verificar se o usuário indicado a fornecer informações é o mais adequado, se as técnicas de envolvimento dos usuários para a especificação de requisitos estão sendo corretamento empregadas e assim por diante.

7.3.3 - Medições Para Atender a Gestão do Produto Durante o processo de desenvolvimento do software são realizadas medições as quais vão subsidiar o processo de gestão do próprio software. Estas medições são realizadas quando da release do software.

As principais medições são: ➪ ➪ ➪

Falhas esperadas para o software Intensidade atual de falha Estimativa atualizada do número de defeitos pós-release

As duas primeiras medições também são derivadas dos modelos de confiabilidade de Musa, Iannino & Okumoto.

Falhas Esperadas Para o Software Objetivo: Determinar o número de falhas esperadas para o software dentro de um período de tempo especificado.

Método de Determinação: O cálculo de falhas esperadas é dado pela seguinte expressão: µ(τ) =

1 Ln ( λoθτ + 1) θ

onde: µ(τ) ➽ θ ➽ λo τ Ln sendo que: θ

➽ ➽ ➽

número de falhas esperadas parâmetro de redução do número de falhas na medida em que o software vai sendo depurado intensidade inicial de falhas do software tempo de execução para o qual se pretende determinar o número de falhas logaritmo neperiano

é derivado da relação entre a intensidade inicial de falhas sobre o número de falhas detectado dentro de um período específico de medição Fontes de Informação: Registros de falhas quando da execução do teste integrado do software.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Dependendo da meta estabelecida quanto ao número de falhas aceitáveis para o software em relação a um período de tempo específico, a gerência poderá, estabelecer objetivos de redução do número de falhas quando o software estiver em operação, o que guiará os esforços de manutenção corretiva.

Exemplo: Supondo que a intensidade de falha inicial , medida no início do teste integrado, tenha sido de 10 falhas por CPU hora; que foram registradas 200 falhas durante o teste integrado; e que se pretende estabelecer o número de falhas esperadas para um tempo de execução de 1000 CPU hora: µ ( τ ) = 1 / .05 Ln ( 10 x .05 x 500 + 1 ) = 111 (aproximado) Esperaríamos, portanto, a ocorrência de 111 falhas para um período de 500 CPU hora.

Intensidade Atual de Falhas Objetivo: Determinar a intensidade atual de falhas do software quando de sua release.

Método de Determinação: O cálculo para a determinação da intensidade atual de falhas é dado pela expressão: λ(µ ) =

λo exp ( - θµ )

onde: λ (µ ) ➽ intensidade atual de falha λo ➽ intensidade inicial de falha θ ➽ parâmetro de redução da intensidade de falha µ ➽ número de falhas observadas durante o teste exp ➽ função exponencial Fontes de Informações: Registros de falhas na execução do teste integrado.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: A gerência pode confrontar a intensidade atual com objetivos de intensidade para o produto, estipulados no início do projeto. Caso houver vairação para mais, a gerência pode estabelecer metas quando da operação do produto a fim de guiar a manutenção corretiva.

Exemplo: Supondo a intensidade inicial em 10 falhas por CPU hora e 100 falhas observadas e um parâmetro de redução de falhas em torno de 0.05: λ (µ ) = 10 exp ( - .05 x 100 ) = 0.07 falhas por CPU hora Estimativa Atualizada do Número de Defeitos Pós-Release Objetivo: Determinar o número de defeitos pós-release quando do término do projeto.

Método de Determinação: Método #1 Esta método parte da equação de regressão linear onde: Número de Defeitos Pós-Release = F ( Tamanho do Software) Neste caso o tamanho do software, ao final do projeto, é calculado pela metodologia #2 do Pontos de Função.

Método #2 Este método contempla a seguinte expressão: Número de Defeitos Pós-Release = Número de Defeitos Pré-Release x ( 100 - Eficiência Média da Remoção de Defeitos) / Eficiência Média da Remoção de Defeitos Fontes de Informação: Registros das inspeções e o índice de eficiência média da remoção de defeitos do processo de desenvolvimento, constante no banco de dados de métricas da instalação.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Esta estimativa permite à gerência estabelecer os recursos necessários para a correção dos defeitos. Lembramos que falhas são reflexos de defeitos porém, nem todos os defeitos geram falhas.

Exemplo: Método # 1 Usar a equação de regressão linear, similarmente ao exemplo apresentado no capítulo 6 quanto à estimativa de defeitos pré-release.

Método # 2 Supondo que foram registrados 800 defeitos pré-release e que a eficiência média de remoção de defeitos do processo é de 60%: Número de Defeitos Pré-Release = 800 ( 100 - 60 ) / 60 = 533 7.3.4 - Medições Para Atender o Aperfeiçoamento do Planejamento de Projetos e do Processo de Desenvolvimento da Instalação Ao final do processo de desenvolvimento devem ser feitas algumas medições para que dêem subsídios ao aperfeiçoamento contínuo dos processos de planejamento de projetos e de desenvolvimento da instalação.Essas medições vão atualizar o banco de dados de métricas, bem como estabelecer os novos padrões da instalação, os quais serão utilizados para o planejamento e desenvolvimento de novos projetos.

Essas medições compreendem: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Verificação da Exatidão das Estimativas Tamanho do Software Entregue Produtividade do Desenvolvimento Custo do Ponto de Função de Desenvolvimento Crescimento Funcional do Software Durante o Desenvolvimento Reutilização do Código Complexidade Relativa do Software Custo da Qualidade Distribuição do Esforço Por Fase Distribuição do Custo Por Fase Distribuição dos Defeitos Por Fase Densidade de Defeitos do Software Índice de Tecnologia de Desenvolvimento Empregado Índice de Tecnologia de Gestão Empregado Demais Medições Qualitativas

A seguir detalharemos cada uma dessas medições.

Ao contrário das medições elencadas para a gestão do próprio processo de desenvolvimento, nesta seção não discutiremos as ações gerenciais relativas a cada medição, tendo em vista que as mesmas são tratadas a nível tático.

Verificação da Exatidão das Estimativas Essas medições objetivam a determinação da exatidão das estimativas visando realimentar o processo de planejamento para fins de adequação dos modelos de estimativas.

Exatidão da Estimativa de Prazo Objetivo: Determinar o grau de acerto da estimativa inicial de prazo elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de prazo é dada pelas seguintes expressões: Caso do Prazo estimado for menor que o prazo realizado ExP = (PE/PR) x 100 onde: PE ➽ Prazo Estimado PR ➽ Prazo Realizado Caso do prazo estimado for maior que o prazo realizado ExP =  1-  ( PE/PR ) -1   x 100 De acordo com essas fórmulas a exatidão da estimativa = a 100%, significa que o prazo estimado foi igual ao prazo realizado Fontes de Informações: Sistema de gerenciamento de projetos.

Forma de Apresentação: nenhuma específica.

Exemplos: Supondo o prazo estimado em 10 meses e o realizado em 12 meses, a exatidão da estimativa é: Exp = 83% Ou seja a estimativa representa 83% do prazo efetivamente relizado, com uma variação de 17% a mais.

Supondo o prazo estimado em 12 meses e o realizado em 10 meses, a exatidão da estimativa é: Exp = 80% O prazo realizado representa 80% do prazo estimado, com uma variação de 20% para menos. ( Geralmente é um fato muito difícil de ocorrer) Exatidão da Estimativa de Tamanho do Software Objetivo: Determinar o grau de acerto da estimativa inicial de tamanho elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de tamanho é dada pela pelas mesmas fórmulas, substituindo-se as variáveis.

Fontes de Informações: Cálculo do tamanho do software realizado no planejamento e ao término do projeto.

Forma de Apresentação: nenhuma específica.

Exemplo:

Similar ao anterior.

Exatidão da Estimativa de Custo Objetivo: Determinar o grau de acerto da estimativa inicial de custo elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de custo é dada pela pelas mesmas fórmulas, substituindo-se as variáveis.

Fontes de Informações: Sistema de gerenciamento de projetos.

Forma de Apresentação: nenhuma específica.

Exemplo: Similar ao da exatidão da estimativa de prazo.

Exatidão da Estimativa de Esforço Objetivo: Determinar o grau de acerto da estimativa inicial de esforço elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de esforço é dada pela pelas mesmas fórmulas, substituindo-se as variáveis.

Fontes de Informações: Sistema de gerenciamento de projetos.

Forma de Apresentação: nenhuma específica.

Exemplo: Similar ao da exatidão da estimativa de prazo.

Exatidão da Estimativa de Defeitos Pré-Release Objetivo: Determinar o grau de acerto da estimativa inicial de defeitos pré-release elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de defeitos pré-release é dada pela pelas mesmas fórmulas, substituindo-se as variáveis.

Fontes de Informações: Sistema de gerenciamento de projetos, processo de inspeção.

Forma de Apresentação: nenhuma específica.

Exemplo: Similar ao da exatidão da estimativa de prazo.

Exatidão da Estimativa de Custo de Retrabalho Objetivo: Determinar o grau de acerto da estimativa inicial de custo de retrabalho elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de custo de retrabalho é dada pela pelas mesmas fórmulas, substituindo-se as variáveis.

Fontes de Informações: Sistema de gerenciamento de projetos , processo de inspeção.

Forma de Apresentação: nenhuma específica.

Exemplo: Similar ao da exatidão da estimativa de prazo.

Exatidão da Estimativa de Instruções Fontes

Objetivo: Determinar o grau de acerto da estimativa inicial do número de instruções fontes elaborada quando do planejamento do projeto.

Método de Determinação: A exatidão da estimativa de instruções fontes é dada pela pelas mesmas fórmulas, substituindo-se as variáveis.

Fontes de Informações: Estimativa inicial e contagem das instruções fontes ao final do projeto.

Forma de Apresentação: nenhuma específica.

Exemplo: Similar ao da exatidão da estimativa de prazo.

Tamanho do Software Entregue Ao final do projeto os Pontos de Função devem ser calculados a fim de determinar o tamanho efetivo do software.

No caso de ser sistema de processamento em tempo-real, uma das alternativas é o emprego da variação da metodologia #1 da Análise Por Pontos de Função denominada de “Feature Points”, a qual foi desenvolvida por Capers Jones 9.

Cálculo do Ponto de Função Pela Metodologia #1 Objetivo: Determinar o tamanho do software a ser entregue para os clientes/usuários.

Método de Determinação: metodologia #1.

Fontes de Informações: Funções implementadas no software.

Forma de Apresentação: Formulário de cálculo do método.

Exemplo: Vide capítulo 6 .

Cálculo de Feature Points Para Sistemas de Processamento em Tempo Real Objetivo: Determinar o tamanho do software em feature points.

Método de Determinação: A diferença fundamental entre o Function Points Analisys e o Feature Points está na consideração que este faz em relação aos algoritmos empregados pelo software, bem como na utilização dos pesos que definem a complexidade das funções ( entradas, saídas, consultas, arquivos lógicos internos e arquivos de interfaces externas).

Os procedimentos para cálculo do Feature Points são: Contagem das Funções Utiliza-se a mesma abordagem tratada pela metodologia #1.

Definição da Complexidade A complexidade é definida pelos aspectos da lógica e de dados do software.Para tanto deve ser determinado o nível de complexidade da lógica e dos dados, conforme a seguinte escala: Complexidade da Lógica 1. Algoritmos e cálculos simples 2. Maior parte dos algoritmos e de cálculos são simples

3. Algoritmos e cálculos de complexidade média 4. Alguma dificuldade e cálculos complexos 5. Muitos cálculos e algoritmos complexos e difíceis Complexidade dos Dados 1. Estrutura de dados simples, com poucas variáveis e baixa complexidade 2. Numerosos variáveis mas com relacionamentos de dados simples 3. Arquivos/Tabelas múltiplas, campos e interações de dados 4. Estruturas e interações de dados complexas 5. Estrutura e interações de dados muito complexas Soma das Complexidades Lógica e de Dados Exemplo da soma das complexidades: Complexidade Lógica Algoritmos e cálculos simples 1 Complexidade dos Dados Estruturas e interações de dados complexas 1 Soma = 2 Definição do Multiplicador de Complexidade Tabela 7-19

Soma das Complexidades 2 3 4 5 6 7 8 9 10

Multiplicador de Complexidade 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4

Determinar o Número de Algoritmos Determinar o Nível de Complexidade dos Algoritmos A complexidade dos algoritmos é determinada pelo número de regras e pelo número de fatores ou elementos de dados requeridos. O algoritmo a seguir exemplifica estes conceitos: “ Se funcionário é igual a gerente e salário for maior que 3000 então deve ser avaliado o desempenho”. Este exemplo contém uma regra e dois fatores: funcionário e salário. A Figura 7-25 mostra a relação entre número de fatores por regra e o número de regras em um algoritmo, as quais determinam o nível de complexidade do algoritmo.

Empregar a Tabela de Transformação Tabela 7-20

Parâmetro Algoritmos Entradas Saídas Consultas Arquivos Lógicos Internos Arquivos de Interfaces

Ocorrências

Peso

x x x x x x

Total

1 4 5 4 7 7

= = = = = =

Total Não Ajustado Multip. de Complexidade Feature Point Ajustado

Fontes de Informação: Software a ser entregue.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo 3 algoritmos com, respectivamente, pesos 1,2 e 3; 10 entradas, 10 saídas, 10 consultas, 5 arquivos , 2 interfaces e soma de complexidade 6.

Número de Fatores 10

9

9

10

8

8

7

7

6

6 5

5

4

4

3

3

2

2

1

1 1

2

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

Regras

Figura 7-25

Aplicando a tabela de transformação teríamos a seguinte contagem de Feature Points: Tabela 7-21

Parâmetro Algoritmos

Entradas Saídas Consultas Arquivos Interfaces Total Não Ajustado

Ocorrências 1x 1x 1x 10 x 10 x 10 x 5x 2x

Pesos 1= 2= 3= 4= 5= 4= 7= 7=

Total 1 2 3 40 50 40 35 14 185

Multip. Complexidade

1.0

Feature Points Ajust.

185

Produtividade do Desenvolvimento Objetivo: Determinar a produtividade do desenvolvimento do software.

Método de Determinação: O cálculo da produtividade é dado pela expressão: Tamanho do Software em Pontos de Função ÷ ∑ Esforço do Projeto.

Fontes de Informação: Cálculo final dos FP’s e registros de esforço do projeto.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo um software de tamanho 1000 Pontos de Função, cujo projetodespendeu cerca de 50 homens/mês, a produtividade será de 20 PF’s/H/M. Custo do Ponto de Função de Desenvolvimento Objetivo: Determinar o custo unitário do ponto de função do projeto.

Método de Determinação: O cálculo é dado pela expressão: Custo Total do Projeto ÷ Tamanho Final do Software em Pontos de Função.

Fontes de Informações: Sistema de gerenciamento de projetos ou de controle de custos de projetos e cálculo final dos pontos de função do projeto.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo um custo total em torno de $ 120.000,00 e o tamanho final em 1000 pontos de função, o custo unitário do ponto de função de desenvolvimento seria de $ 120,00.

Crescimento Funcional do Software Durante o Desenvolvimento Objetivo: Determinar a variação do crescimento funcional do software ao longo do projeto.

Método de Determinação: O cálculo é dado pela expressão: ( FPF - FPI ) ÷ FPI  x 100 onde: FPF ➽ Pontos de Função Final Calculado FPI ➽ Pontos de Função Estimados Inicialmente Fontes de Informação: Documento de planejamento do projeto e cálculo final do tamanho do software.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo o FPI em 1000 e o FPF em 1300, o crescimento funcional seria de +30%.

Reutilização do Código Objetivo: determinar a taxa de reutilização de código do projeto.

Método de Determinação: A taxa de reutilização pode ser calculada tomando como base pontos de função ou número de instruções fontes. O cálculo para ambos é igual conforme a expressão a seguir: (TCR ÷ TSU) x 100 onde: TCR ➽ Tamanho do Código Reutilizado TSU ➽ Tamanho do Sistema na Unidade de Medida Escolhida Fontes de Informações: Registros de reutilização de componentes de software, cálculo do tamanho do software ao final do projeto ou sistema de controle de versões de software e de biblioteca de componentes reutilizáveis.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo o TCR de 300 e p TSU de 1000, a taxa de reutilização seria de 30%.

Complexidade do Software Objetivo: Determinar a complexidade do software como um todo.

Método de Determinação: O modelo de complexidade foi desenvolvido por Card & Glass 5 sendo a complexidade determinada pelas expressões a seguir: Ct = St + Dt onde: Ct St Dt sendo que:

➽ ➽ ➽

complexidade do software complexidade estrutural complexidade de dados

St

➽

∑ fi /n

Dt

➽

∑  vi /  fi + 1   / n

fi vi

➽ ➽

fanout do módulo i variáveis de I/O do módulo i

2

e:

Fontes de Informações: Projetos de rotinas automatizadas.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo um sistema com 5 módulos, cada módulo com 2 fanout’s e 44 variáveis de I/O. St = 100 / 5 = 20 Dt = 73,33/5= 14.66 Ct = 34,66 Custo da Qualidade Objetivo: Determinar o custo da qualidade do projeto.

Método de Determinação: Como discutido no capítulo 3, os custos da qualidade são classificados em custos de prevenção, custos de avaliação, custos de falhas

internas e custos de falhas externas. Na realidade, o custo da qualidade do projeto é o somatório dos custos destas categorias. Mais detalhadamente, o custo da qualidade é determinado pela expressão: ( CTR+ CFE ) + ( CIN + CTT) + ( CRE) + ( CMI) onde: CT R ➽ CFE ➽

Custo de treinamento para a equipe Custo de aquisição/alocação de ferramentas de apoio ao desenvolvimento e gestão do projeto CIN ➽ Custo das inspeções, excluindo os de retrabalho CTT ➽ Custo de testes do sistema, excluindo o custo de remoção de falhas de execução do software CRE ➽ Custo de retrabalho CMI ➽ Custo de manutenção inicial,quando da entrega do produto Fontes de Informações: Acompanhamento financeiro do projeto e processo de inspeção.

Forma de Apresentação: É interessante mostrar a relação entre os custos de prevenção com os custos de retrabalho e os custos da qualidade do projeto com o custo total do projeto a fim de permitir análises de sensibilidade. Dessa forma é útil a apresentação gráfica ou tabular desses resultados.

Exemplo: Tabela 7-22

Tipo Custo Total do Projeto CTP CustoTotal da Qualidade CTQ Custo de Prevenção CP Custo de Avaliação CA Custo de Retrabalho CR

CP/CR 4000 1000 100 200 700

CA/CR

CTQ/ CTP 25%

14% 29%

Distribuição do Esforço Por Fase Objetivo: Determinar o comportamento da distribuição do esforço por fase do projeto.

Método de Determinação: Para cada fase do projeto determinar o percentual do esforço conforme a expressão: Efasei ÷ ∑ Efasei ou seja, dividir o esforço da fase específica pelo esforço total do projeto.

Fontes de Informação: Sistema de gerenciamento de projetos ou registros de esforço do projeto.

Forma de Apresentação: gráfica.

Exemplo:

co 20% Nort 40%

Lest e Oest e

Leste Oeste Nort co

Planejamento - 10% Projeto do Produto - 30% Programação - 40% Integração e Teste 20%

Distribuição do Custo Por Fase Objetivo: Determinar o comportamento da distribuição do custo por fase do projeto.

Método de Determinação: Para cada fase do projeto determinar o percentual do custo conforme a expressão: Cfasei ÷ ∑ Cfasei ou seja: Dividir o custo da fase específica pelo custo total do projeto.

Fontes de Informação: Sistema de gerenciamento de projetos ou registros de custo do projeto.

Forma de Apresentação: gráfica.

Exemplo: Similar ao exemplo anterior.

Distribuição dos Defeitos Por Fase Objetivo: Determinar o comportamento da distribuição dos defeitos por fase do projeto.

Método de Determinação: Para cada fase do projeto determinar o percentual dos defeitos conforme a expressão: Dfasei ÷ ∑ Dfasei ou seja: Dividir os defeitos da fase específica pelo total de defeitos observados no projeto.

Fontes de Informação: Processo de inspeção.

Forma de Apresentação: gráfica.

Exemplo: Similar ao exemplo anterior.

Densidade de Defeitos do Software Objetivo: Determinar a densidade de defeitos do software sendo entregue.

Método de Determinação: Como estamos tratando do produto em si, que é constituído por instruções fontes ou por funções, a densidade de defeitos deve ser determinada dividindo-se o número de defeitos restantes esperados pelo tamanho do software em pontos de função ou pelo número de instruções fontes. Para que se defina os defeitos restantes pode-se empregar a fórmula do índice de eficiência da remoção de defeitos ( vide exemplo da Estimativa Atualizada do Número de

Defeitos Pós-Release, no item 7.3.3) ou obter os dados através da última inspeção do processo antes da entrega efetiva do software. A rigor esta medição é preliminar, pois somente com a coleta de dados sobre os defeitos comunicados pelos usuários com a operação do software é que poderemos de fato, estabelecer esta medida. Lembre-se que no caso de utilizar instruções fontes é importante normalizar por1000 a densidade de defeitos.As expressões a seguir definem esta medição.

Considerando densidade por 1000 instruções fontes: ( NDRS x 1000 ) ÷ NKDSI = defeitos por 1000 linhas onde: NDRS NKDSI

➽ ➽

Número de Defeitos Restantes do Software Número Total de Instruções Fontes do Software

Considerando a densidade por pontos de função: NDRS ÷ Número de Pontos de Função = defeitos por PF. Fontes de Informação: Registros de defeitos identificados pelo processo de inspeção e índice padrão da eficiência de remoção de erros.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo 100 defeitos restantes esperados, tamanho em pontos de função em torno de 274 e 25 KDSI e software desenvolvido em Cobol: ( 50 x 1000 ) ÷ 25.000 = 2 defeitos por 1000 linhas 50 ÷ 274 = .18 defeitos por ponto de função Índice de Tecnologia de Desenvolvimento Empregado O índice de tecnologia de desenvolvimento diz respeito ao nível de utilização de ferramentas de apoio ao desenvolvimento, bem como às abordagens metodológicas utilizadas pelo projeto. Mede o nível de sofisticação da tecnologia de desenvolvimento aplicada ao projeto. Este índice pode ser correlacionado com as medidas de qualidade e produtividade a fim de auxiliar na modelagem do melhor ambiente de desenvolvimento.

O índice tecnológico tem vários componentes, quais sejam: ➪ ➪ ➪ ➪ ➪ ➪

Ambiente de desenvolvimento Emprego de metodologia de desenvolvimento Ferramentas de apoio ao desenvolvimento Tipo de CASE utilizado Técnicas de especificação e desenvolvimento Utilização de métodos de identificação e remoção de erros

Objetivo: Determinar o nível de sofisticação da tecnologia de desenvolvimento empregada.

Método de Determinação: Cada componente pode ser traduzido por uma variável ordinal, composta por ítens que definem níveis de sofisticação. Cada componente tem um peso e cada item tem uma nota. O índice é dado pela média ponderada ou: ( ∑ Pesos x Notas ) / ∑ Pesos = Ambiente de Desenvolvimento ( peso 5 ) a) Não há apoio eletrônico para elaboração dos documentos do projeto; não há biblioteca técnica disponível para as equipes de projeto; sem automação do controle de versões dos componentes do software; um terminal ou micro para cada quatro analistas/programadores; ferramentas mínimas de depuração; as equipes de projetos não possuem área reservada; não existe áreas para armazenagem de materiais, listagens; não existem salas de reunião disponíveis para revisões técnicas e não há monitoramento de defeitos. ( Nota 1 ) b) Algum suporte de edição de textos para a documentação de projetos; pequena e escassa biblioteca técnica; controle das versões para o código-fonte; a documentação é controlada manualmente; um terminal/micro para cada analista/programador; algumas ferramentas de depuração; escritórios compartilhados por três ou quatro analistas/programadores; uma ou duas salas de reunião; sistema manual de registro de erros. ( Nota 3 ) c) Apoio informatizado para a documentação do projeto; boa biblioteca técnica a disposição para as equipes de projetos; controle de versões de componentes de software automatizado; um terminal/micro para cada analista/programdor, com terminais extras como “back-up”; ferramentas de depuração; bibliotecas de testes; espaço adequado aos analistas/programadores com áreas de armazenagem adequadas; salas de reunião adequadas. ( Nota 5 ) Emprego de Metodologia de Desenvolvimento ( peso 5 ) a) O projeto não utilizou nenhuma metodologia de desenvolvimento (Nota 1) b) O projeto usou apenas um roteiro básico, com fases e etapas (Nota 2 ) c) Além das fases e etapas, haviam produtos a serem gerados em cada fase ( Nota 3) d) A metodologia empregada, além de C, indicava técnicas a serem utilizadas, bem como recomendações e esquema de gerenciamento (Nota 4) e) A metodologia empregada automatizava todo o ciclo de desenvolvimento (Nota 5) Ferramentas de Apoio ao Desenvolvimento ( peso 5 ) ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒

Verificador de sintaxe Depurador interativo Prototipador Gerador de telas Gerador de relatórios Gerador de gráfico Gerador de código-fonte Otimizadores

❒ ❒ ❒ ❒ ❒ ❒ ❒

Linguagens com facilidades de depuração Gerador de dados para teste Dicionário de dados Documentador automático Analisador de código Utilitários de otimização de banco de dados Controle automatizado de versões

0 a 2 itens assinalados 3 a 5 itens assinalados 6 a 8 itens assinalados 9 a 12 itens assinalados 13 a 15 itens assinalados

nota 1 nota 2 nota 3 nota 4 nota 5

Tipo de CASE ( Computer Aided Software Engineering) Empregado ( peso 4 ) a) O projeto não empregou CASE ( Nota 1 ) b) “lower CASE “ ( Nota 2) c) “upper CASE” (Nota 3) d) “integrated CASE” (Nota 5) Técnicas de Especificação e Desenvolvimento ( peso 5 ) a) O projeto utilizou apenas análise estruturada ( Nota 1) b) O projeto utilizou , além de a, modelagem de dados ( Nota 2 ) c) O projeto utilizou além de b, prototipação e JAD ( Nota 3 ) d) O projeto utilizou análise essencial , JAD e prototipação ( Nota 4 ) e) O projeto utilizou análise orientada a objetos ( Nota 5 ) Utilização de Métodos de Identificação e Remoção de Erros ( peso 5 ) ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒

Revisão dos requisitos Revisão do projeto lógico Revisão do projeto do projeto físico de banco de dados Revisão dos projetos de rotinas automatizadas Inspeção e revisão do código Verificação e validação independente Teste de exatidão de algoritmos Teste de programas individuais Teste de unidade de implantação Teste integrado Teste de desempenho Teste de aceitação Teste de campo Organização de teste independente Análise de módulos com erros crônicos

❒

Investigação da satisfação do usuário

0 a 3 itens assinalados 4 a 6 itens assinalados 7 a 9 itens assinalados 10 a 12 itens assinalados 13 a 16 itens assinalados

nota 1 nota 2 nota 3 nota 4 nota 5

O conjunto de valores possíveis está entre: 1 e 5 Fontes de Informações: Avaliação final do projeto.

Forma de Apresentação: nenhuma específica.

Exemplo: Convidamos o leitor a aplicar o instrumento em um de seus projetos. Índice de Tecnologia de Gestão Aplicado ao Projeto Este índice tem uma função similar ao anterior, a diferença é que ele mede o nível de sofisticação da gestão do projeto.

Os componentes deste índice são: ➪ Estimativas de prazos, custos e recursos ➪ Elaboração de cronogramas e orçamentos ➪ Pert/CPM ➪ Acompanhamento físico/financeiro ➪ Controle de custos ➪ Ferramenta de monitoramento de defeitos ➪ Comunicação eletrônica entre membros da equipe ➪ Controle de mudanças e de configuração Estimativas de Prazos, Custos e Recursos ( peso 5 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5 ) Elaboração de Cronogramas e Orçamentos ( peso 5 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5 ) Pert/CPM ( peso 3 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 )

d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5 ) Acompanhamento Físico/Financeiro ( peso 5 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5) Controle de Custos ( peso 5 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5) Ferramenta de Monitoramento de Defeitos ( peso 5 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5) Comunicação Eletrônica Entre Membros da Equipe ( peso 3 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5) Controle de Mudanças e de Configuração ( peso 4 ) a) Não tem ( nota 1) b) Manual ( nota 2 ) c) Parcialmente automatizada ( nota 3 ) d) Grande parte automatizada ( nota 4 ) e) Totalmente automatizada ( nota 5) O conjunto de valores possíveis está entre: 1 e 5.

Outras Medições Qualitativas As medições qualitativas são realizadas para fornecer indicativos de “causas” para a melhor ( pior) qualidade e produtividade do projeto, visando subsidiar a gerência

de desenvolvimento com informações úteis para que possa aperfeiçoar continuamente o processo de desenvolvimento de software da instalação. Essas medições qualitativas podem ser empregadas juntamente com os índices de tecnologia de desenvolvimento e de gestão a fim de fornecer um quadro amplo dos aspectos subjetivos do processo.

As medições qualitativas compreendem: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Perfil da equipe técnica do projeto Novidades das especificações do software Experiência da equipe na área de aplicação do software Experiência da equipe na área de aplicação do software Envolvimento dos usuários Novidade da tecnologia para a equipe Experiência dos usuários com projetos de sistemas Experiência da equipe com métodos de remoção de erros Geografia do desenvolvimento Coesão técnica apresentada durante o projeto Principais ocorrências

Perfil da Equipe Técnica do Projeto Em relação ao ambiente de desenvolvimento: ❒ ❒ ❒ ❒ ❒ ❒

Experiência nas ferramentas de apoio ao desenvolvimento Experiência nos métodos e técnicas de análise e projeto Experiência nas linguagens de programação Experiência em métodos e técnicas de revisões e inspeções Experiência em técnicas de teste de sistemas Experiência no hardware de desenvolvimento

Estabelecer o percentual, conforme o total dos membros da equipe em termos de: Pouca experiência - até 2 itens assinalados :_____% Média experiência - 3 e 4 itens assinalados:_____% Grande experiência - 5 e 6 itens assinalados:_____% Novidades das Especificações do Software a) Nenhuma novidade b) Pouca novidade c) Média novidade d) Grande novidade e) Especificações totalmente desconhecidas pela equipe Experiência da Equipe na Área de Aplicação do Software a) Nenhuma experiência

b) Pouca experiência c) Média experiência d) Grande experiência e) Domínio da área de aplicação Experiência dos Usuários na Área de Aplicação do Software a) Nenhuma experiência b) Pouca experiência c) Média experiência d) Grande experiência e) Domínio da área de aplicação Envolvimento dos Usuários a) Nenhum envolvimento b) Pouco envolvimento c) Médio envolvimento d) Grande envolvimento e) Total participação, inclusive com usuários alocados “full-time” ao projeto Novidade da Tecnologia Para a Equipe a) Tecnologia de hardware e software desconhecida pela equipe b) Poucos elementos da tecnologia dominados pela equipe c) Domínio mediano da tecnologia d) Maioria dos componentes da tecnologia dominados pela equipe e) Domínio completo da tecnologia Experiência dos Usuários Com Projetos de Software a) Nenhuma experiência com projetos de software b) Pouca experiência c) Alguns membros com experiência d) A maioria com experiência em projetos de software e) Todos os usuários com experiência em projetos de software Experiência da Equipe Com Métodos de Remoção de Erros a) Nenhuma experiência b) Pouca experiência c) Média experiência d) Grande experiência e) Domínio completo Geografia do Desenvolvimento a) Projeto foi desenvolvido em um único local b) Projeto foi desenvolvido em mais de um local na mesma cidade

c) Projeto foi desenvolvido com participação de várias fornecedores numa mesma cidade d) Projeto foi desenvolvido por equipes distribuídas em diversas cidades e) Projeto foi desenvolvido com participação de equipes distribuídas em diversos países Coesão Técnica Apresentada Durante o Projeto a) Nenhuma coesão técnica entre os membros b) Pouca coesão técnica c) Média coesão técnica d) Grande coesão técnica e) Coesão técnica total Principais Ocorrências Ocorrências referem-se às contingências voluntárias ou involuntárias que podem acontecer no decorrer do projeto e que se caracterizam como eventos impactantes no projeto, em termos de prazos, custos e qualidade.

As principais ocorrências devem ser registradas para que a análise posterior do projeto, assim como a análise do processo de software possa ser realizada, confrontando resultados com possíveis causas.

Contingências são eventos que podem ocorrer no início, no meio ou no final do projeto e que, geralmente demandam ação gerencial imediata para manter o projeto sob controle.

Exemplos de contingências que impactam negativamente o projeto: ➪ ➪ ➪ ➪ ➪ ➪

Mudança no ambiente de hardware/software durante o desenvolvimento Alta rotatividade na equipe técnica do projeto Não alocação dos recursos ao projeto conforme o planejado Mudança constante nos membros da equipe de usuários Mudanças de escopo do projeto quando este está na fase de projeto físico Motivos de força maior, tais como greves

Ao final deste capítulo gostaríamos de alertar o leitor que apenas apresentamos as medições que consideramos as mais importantes.

Nosso objetivo foi o de mostrar as possibilidades de medir o processo de software, apesar do desconhecimento e da desconfiança que existe na área de informática quanto a este tópico. É importante considerar também que, em termos práticos, os gerentes e engenheiros de software devem selecionar somente aquelas medições que são críticas e que estejam de acordo com os objetivos que se pretende atingir. É impraticável, a não ser em grandes corporações de classe mundial em excelência, empregar todas as medições,talvez com o tempo consiguamos.

REFERÊNCIAS 1.

2.

BEIZER, Boris. Software Testing Techniques. Van Nostrand Reinhold, New York,1990.

BOEHM, Barry. Software Engineering Cliffs,New Jersey,1981.

Economics.

Prentice-Hall,

Englewood

3. BROOKS,Frederick P. The Mythical Man-Month. Addison-Wesley,Reading,MA,1975.

4. BUSH,Marilyn. Formal Inspections - Do They Really Help? NSIA Sixth Annual National Joint Conference on Software Quality and Productivity, Williamsburg,VA, april 1990.

5. CARD,David & GLASS, P.L. Measuring Software Design Quality. PrenticeHall,Englewood Cliffs,New Jersey, 1990.

6. EBENAU,R.G. & STRAUSS, S.H. Software Inspection Process. McGraw-Hill,New York,1994.

7. FEIGENBAUM,Armand V. Total York,1986.

Quality Control. McGraw-Hill, 3rd

edition,New

8. FREEDMAN, D.P. & WEINBERG,G.M. Manual de Walkthroughs: inspeções e revisões técnicas de especificações de sistemas e programas. McGraw-Hill,São Paulo,1993.

9. JONES,Capers. Applied Software Measurement.McGraw-Hill, New York, 1991.

10.McCABE, T. A Complexity Measure. IEEE Transactions on Software 1976.

Engineering,Dec

11.McCORMIK,K. Results of Using Inspections for the AT&T ICIS Project. Second Annual Symposium on EDP Quality Assurance, March 1993.

12.MUSA, J.D. et al. Software Reliability. McGraw-Hill, New York,1990.

13.RUSSEL,Glen W. Experience With Inspections in Development.IEEE Software, vol 17, No1, January 1991.

Ultralarge

Scale

Capítulo

8 APLICAÇÃO DAS MEDIÇÕES NA GESTÃO DO PRODUTO Os principais fatores motivadores para que sejam aplicadas medições na gestão do produto são: ➪ ➪ ➪ ➪

Melhorar continuamente a qualidade do produto Melhorar continuamente a qualidade do atendimento às solicitações dos clientes/usuários Fornecer a base necessária para o gerenciamento das manutenções e projetos de melhorias do software Monitorar a qualidade do produto ao longo de sua vida útil

O processo de gestão do produto possui características, tanto do planejamento de projetos como do desenvolvimento de software.

Durante a gestão do produto, as manutenções corretivas, adaptativas e projetos de melhorias também devem ser planejadas. Se levarmos em consideração que na média, cerca de 70% dos recursos de desenvolvimento estão alocados à manutenção e implementação de pequenas melhorias nos produtos de software, o planejamento torna-se então, crítico.

A execução do planejado ou de solicitações inesperadas, as quais normalmente são maioria, requerem um monitormento constante, visando não só a qualidade como também a liberação de recursos humanos, obtendo assim maior capacidade de atendimento, tanto para novos projetos como para a manutenção/melhoria dos produtos em operação.

Este capítulo culmina com o conjunto de medições necessárias, a nível operacional, para o gerenciamento efetivo do software em seu ciclo de vida.

Analogamente aos capítulos anteriores, que trataram mais objetivamente sobre a aplicação das medições, neste capítulo procuramos descrever, sob nosso ponto de vista, no que consiste o processo de gestão do produto, suas fases e particularidades e por fim, as medições julgadas importantes para o gerenciamento.

8.1 - O Processo de Gestão do Produto O processo de gestão do produto pode ser vislumbrado como possuindo os mesmos elementos da gestão do processo de desenvolvimento. A diferença fundamental é que aqui estamos preocupados em realizar as manutenções corretivas e adaptativas, assim como as melhorias no produto , sejam elas representadas por pequenos incrementos ou por melhorias significativas.

Apesar dessa diferença, devemos igualmente gerir a qualidade do produto, a qualidade do atendimento, visando a contínua satisfação dos clientes/usuários, a gestão do progresso do atendimento das solicitações , a gestão financeira e de recursos do atendimento e de mudanças.

A Figura 8-1 nos dá esta visão.

Gestão da Qualidade

Controle do Progresso

Gestão Financeira

Gestão das Mudanças

MEDIÇÕES E ANÁLISES

Planejamento

Manutenção Corretiva

Manutenção Adaptativa

Projetos de Melhoria

ATENDIMENTO

INSPEÇÃO E AVALIAÇÃO

MONITORAMENTO Figura 8-1 Modelo de Gestão do Produto

➪

Planejamento do Atendimento

O planejamento do atendimento compreende dois momentos. Um momento no qual o atendimento ao produto é planejado considerando o período de um ano e o outro diz respeito ao planejamento do atendimento de uma solicitação específica, a qual pode abranger vários serviços,isto é, uma série de manutenções corretivas ou adaptativas ou de melhorias ou até mesmo combinações entre elas.

Igualmente ao que é feito para o planejamento de projetos, o planejamento de atendimento deve estimar prazos, custos e recursos e outros atributos requeridos para a posterior confrontação com o realizado. ➪

Manutenção Corretiva

Devido aos atributos da release entregue logo após o término do projeto, podese prever a necessidade de manutenções corretivas no produto no que tange a frequência provável de atendimento. Geralmente essas manutencões são derivadas de solicitações não programadas.

As manutenções corretivas normalmente têm sua ênfase logo no início da operação do software ou quando da entrega de nova release. Também podem ser ocasionadas pelas manutenções adaptativas.

O processo de manutenção corretiva usualmente abrange as seguintes etapas: IDENTIFICAÇÃO DO DEFEITO OU FALHA

ENTENDIMENTO DO PROBLEMA

ACERTOS EM PROGRAMAS E/ OU ESTRUTURA DE DADOS

TESTE DOS ACERTOS

LIBERAÇÃO DOS ACERTOS Figura 8-2 Etapas da Manutenção Corretiva

➪

Manutenção Adaptativa

Estas manutenções são em decorrência de mudanças em legislação, procedimentos de órgãos reguladores, otimização do software e mudança da tecnologia.

As manutenções adaptativas podem ser programadas. Em alguns setores econômicos que têm forte ingerência regulatória, como o setor financeiro, há manutenções adaptativas que são impossíveis de serem programadas, pois são decorrência de mudanças na legislação ou em procedimentos expedidos por autoridade monetária.

➪

Projetos de Melhoria

Projetos de melhoria referem-se a incrementos de novas funções no software ,a fim de atender a evolução do negócio da empresa. A maioria dos projetos de melhoria podem ser programados. Projetos de melhoria não programados evidencia falta de alinhamento entre a área de informática e seus clientes/usuários.

Em projetos de melhoria também é possível o emprego do processo de inspeção.

Dependendo do rigor metodológico utilizado pela empresa , o projeto de melhoria pode implicar na reformulação do modelo de dados, na reformulação do modelo operacional do projeto, na reformulação do projeto físico do banco de dados e assim sucessivamente. Neste caso é imperioso o emprego de inspeção e tratar o projeto como se fosse de desenvolvimento.

O processo simplificado de projetos de melhoria é mostrado pela Figura 8-3 a seguir.

ANÁLISE DOS INCREMENTOS ANÁLISE DE IMPACTO NA ESTRUTURA DE DADOS E FUNCIONAL REFORMULAÇÃO DO MODELO DE DADOS E FUNCIONAL REFORMULAÇÃO DO PROJETO FÍSICO DO BANCO DE DADOS PROJETO DAS ROTINAS AUTOMATIZADAS CODIFICAÇÃO E TESTE INDIVIDUAL DE PROGRAMAS TESTE DAS UNIDADES DE IMPLEMENTAÇÃO TESTE INTEGRADO DA NOVA RELEASE TESTE DE ACEITAÇÃO PELO CLIENTE/USUÁRIO LIBERAÇÃO DA NOVA RELEASE Figura 8-3 Etapas de Projetos de Melhoria

Os demais componentes são similares aos do processo de desenvolvimento.

Entretanto, na gestão do produto, a qualidade e os aspectos financeiros devem ser monitorados ao longo da vida útil do software,não somente no que diz respeito a um atendimento específico.

Outro conceito fundamental é o de release. Dependendo da extensão, uma ou mais manutenções adaptativas geram uma nova release do software. Um projeto de melhoria, por sua vez, gera necessáriamente uma nova release.

Portanto, ao longo de sua vida útil, um produto de software pode ter uma série de releases. É importante, no contexto desta abordagem, o controle das releases em termos de documentos e componentes de software, a fim de evitar retrabalho. SE houverem mudanças, temos que ter a possibilidade de recuperar algumas “features” de releases anteriores.

Estes pontos definem a essência da gestão do produto.

As medições para o processo de gestão do produto também se dividem conforme o mecanismo de medição, mostrado pela Figura 8-4. ➊ PROCESSO DE SOFTWARE

GESTÃO DO PROCESSO

➋ PROCESSO DE PLANEJAMENTO DE PROJETOS

➌ PROCESSO DE SOFTWARE

Figura 8-4 Medições na Gestão do Produto

As medições que devem ser realizadas para a gestão do produto concentramse então em: ➪ ➪ ➪

Medições para o próprio processo de gestão do produto Medições para subsidiar o aperfeiçoamento do planejamento de projetos Medições para subsidiar o aperfeiçoamento do desenvolvimento de software

processo

de

processo

de

A estrutura lógica de apresentação das medições neste capítulo segue a utilizada pelo capítulo anterior.

8.2 - Medições Para a Gestão do Produto As medições relativas a gestão do produto podem ser classificadas em: ➪ ➪ ➪ ➪

Medições para o planejamento anual de atendimento Medições para o planejamento de atendimento específico Medições para o monitoramento do atendimento Medições para o monitoramento do produto

8.2.1 - Medições Para o Planejamento Anual de Atendimento do Produto O planejamento anual de atendimento do produto de software, tenta prever as quantidades de esforço e recursos necessárias, bem como estabelecer o custo anual previsto deste atendimento. O somatório dos custos de todos os atendimentos mais os custos previstos para os projetos, configuram o orçamento da área de desenvolvimento.

Adicionalmente tenta estimar alguns atributos relativos a qualidade do produto, para fins de comparação e controle. É importante estabelecer dois momentos para o planejamento anual de atendimento.

Um momento é quando se deve planejar o atendimento logo após a entrada da release em operação, ou seja, não se tem informações ( “data set”) sobre o desempenho do atendimento ao produto específico. Para fins de apresentação do método de determinação, chamaremos de momento #1.

Um segundo momento é quando já existe uma história de atendimento e, portanto, há informações históricas quantitativas sobre o produto. Chamaremos este de momento #i , pois ocorre repetidas vezes.

No primeiro momento as informações que vão subsidiar o planejamento são as relativas a produtos similares em termos de tamanho e plataforma de hardware/software, em virtude de que não existem dados históricos.

No segundo momento deve-se utilizar as informações que demonstram a própria evolução do produto.

Ao apresentarmos as medições, enfocaremos ambos momentos.

Estimativa de Esforço de Atendimento Objetivo: Determinar o esforço necessário para o atendimento satisfatório às solicitações de manutenção e evolução do produto por parte dos clientes/usuários considerando um período de 12 meses.

Método de Determinação: Aqui devemos considerar os dois momentos.

Momento #1 A estimativa de esforço anual de atendimento é dada pela expressão:

EAM =CFM ÷ PAM onde: CFM

➽

PAM

➽

Crescimento funcional médio anual do produto, obtido para produtos similares em termos de tamanho,plataforma e área de aplicação na empresa Produtividade média anual do atendimento, que é dada pelas produtividades médias das manutenções corretivas,adaptativas e projetos de melhoria

Momento #I Para o momento #I, há duas alternativas, sendo uma dada pelo método COCOMO. Método #1 A estimativa de esforço anual de atendimento é dada pela expressão: CMP ÷ PMP = EAM onde: CMP PMP

➽ ➽

Crescimento funcional médio anual do próprio produto Produtividade média anual do atendimento ao próprio produto

Método #2 Pelo método COCOMO ( modelo básico), a estimativa do esforço anual de atendimento é dada pelas expressões: (1)

ACT = ( IFA + IFM ) ÷ KDSI

➽ ➽ ➽ ➽

Tráfego anual de mudança ( Annual Traffic Change) Instruções fontes adicionadas Instruções fontes modificadas Tamanho do software a ser mantido

(2)

EAM = 1.0 ( ACT) (EPR)

➽

Esforço do projeto original

onde: ACT IFA IFM KDSI onde: EPR

Fontes de Informações: “Data set” com informações sobre os padrões de produtos similares ou com informações sobre o próprio produto.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Com a informação da estimativa de esforço, estimar o número de profissionais a serem alocados em tempo integral ao atendimento e o custo anual previsto.

Exemplo: Momento #1 Supondo que o crescimento anual médio para produtos similares seja de 200 Pontos de Função e que a produtividade média de atendimento seja de 20 FP’s por homem/mês, o esforço anual previsto seria de 10 H/M.

Momento#i Método #1 Supondo que o crescimento anual médio do produto seja de 100 Pontos de Função e que a produtividade média de atendimento seja de 15 FP’s por homem/mês, o esforço anual previsto seria de 6,67 H/M. Método #2 Supondo que a média anual de IFA seja de 3000 e a média de IFM seja de 2000; considerando que o software tenha 50 KDSI , cujo esforço original para seu desenvolvimento tenha sido de 146 H/M ,o EAM seria de 14,60 H/M. Estimativa do Número de Profissionais Para o Atendimento Objetivo: Determinar o número de profissionais que deverão ser alocados em tempo integral para o atendimento ao produto.

Método de Determinação: A determinação é dada pela expressão: NPA = EEA ÷ 12 onde: EEA ➽ Esforço estimado anual de atendimento 12 ➽ Número de meses do ano Fontes de Informação: Estimativa de esforço anual de atendimento.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Definir a alocação do recurso tendo em vista o perfil necessário.

Exemplo: Supondo o esforço anual em 24 H/M , o número de profissionais seria 2 alocados em tempo integral.

Estimativa do Custo de Atendimento Objetivo: Determinar o orçamento anual de atendimento para um produto específico.

Método de Determinação: Aqui há duas alternativas.

Método #1: O custo anual de manutenção é dado pela expressão: CMFP x CFM = onde: CMFP ➽ Custo médio do Ponto de Função de atendimento CFM ➽ Crescimento funcional médio do produto em FP’s O CMFP é obtido pela média das médias do custo de FP’s de manutenção corretiva, manutenções adaptativas e projetos de melhoria.

Método #2: O custo anual de manutenção é dado pela expressão: CMHM x EEA onde: EEA

➽

Esforço estimado anual de atendimento

CMHM ➽

Custo Médio do Homem/Mês

Fontes de Informações: Dados de custo da mão de obra e estimativa anual de esforço.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Registrar o orçamento para fins de controle.

Exemplo: Método #1 Supondo o custo médio do ponto de função do atendimento em torno de $ 204 e o CFM em torno de 300, o custo anual seria de $ 61.200.

Método #2 Supondo o custo médio homem/mês em torno de $ 16 e o esforço estimado em 24 H/M ou $ 3840, o custo anual seria de $ 61.440.

Estimativa Esperada de Defeitos do Atendimento Objetivo: Determinar o número de defeitos esperados durante o atendimento anual.

Método de Determinação: O cálculo do número de defeitos é dado pela expressão: EED = DDR x CFM onde: DDR

➽

Densidade de defeitos da release

O DDR é a densidade da release atual, calculada após o término do projeto ou por medições que devem ser realizadas nos momentos #I. Fontes de Informações: Banco de dados de métricas o qual contém dados sobre as densidades atuais de defeitos dos produtos.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Com esta estimativa, o gerente do produto pode calcular o esforço e respectivo custo de retrabalho esperado e, portanto, os custos da má qualidade de falhas externas.

Exemplo: Densidade em Pontos de Função: Supondo a densidade em 0,5 defeitos por ponto de função e o CFM em 200, então o número de defeitos esperados seria em torno de 100.

Densidade em 1000 Linhas de Instruções Fontes: Supondo a densidade de 12 por 1000 e um CFM de 18.000 linhas de instruções fontes( transformados a partir dos pontos de função), a densidade seria de 216.

Esforço Esperado de Retrabalho Objetivo: Determinar o esforço de retrabalho durante o atendimento anual.

Método de Determinação: O esforço de retrabalho pode ser calculado através da equação de regressão dada pela expressão: Esforço de Retrabalho = f ( CFM)

Para tanto é preciso que a instalação tenha no seu banco de dados de métricas, informações sobre o esforço de retrabalho correspondente a um ponto de função de atendimento.

Fontes de Informação: Banco de dados de métricas.

Forma de Apresentação: nenhuma especifica.

Ação Gerencial: Com base nesta informação o gerente poderá estimar o custo de retrabalho esperado.

Exemplo: Vide exemplo referente a estimativa do número de defeitos pré-release apresentado no capítulo 6.

Custo Esperado do Retrabalho do Atendimento Objetivo: Determinar o custo esperado do retrabalho do atendimento.

Método de Determinação: Pode ser determinado também por regeressão linear ou multipicando-se o esforço estimado de retrabalho pelo custo do homem/mês ou homem/hora.

Fontes de Informação: Registros de custos de mão de obra e estimativa de esforço de retrabalho.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Informação a ser utilizada para o controle dos custos relativos à qualidade do produto.

Exemplo: Supondo o esforço esperado de retrabalho em 5 H/M ou 800 homens/hora e o custo do homem/hora em $20, teríamos cerca de o custo de $ 16.000 como custo de retrabalho.

8.2.2 - Medições Para o Planejamento de Atendimento Específico Essas medições referem-se ao planejamento manutençõescorretivas, adaptativas e projetos de melhoria.

do

atendimento

das

Como vimos anteriormente, as manutenções corretivas, visto serem de natureza não programada , torna quase impraticável o planejamento de seu atendimento. A única possibilidade é prevermos a probabilidade da ocorrência de solicitações dessa natureza, com base no histórico de atendimento, bem como definirmos as falhas esperadas em função da intensidade atual de falhas.

⌦

Planejamento do Atendimento a Manutenções Corretivas

A probabilidade da ocorrência de eventos ( solicitações de manutenções corretivas) pode ser caracterizada pela distribuição de probabilidade de Poisson e pela distribuição exponencial.• A distribuição de Poisson pode ser usada para determinar a probabilidade de uma dado número de sucessos quando os eventos ocorrem em um continuum de tempo ou espaço. Por exemplo, a chegada de solicitações de manutenções corretivas enquadra-se neste processo.

Se os eventos ou sucessos ocorrem num processo de Poisson, então o comprimento de tempo ou espaço entre dois eventos sucessivos segue uma distribuição exponencial.

A distribuição exponencial se aplica se desejarmos saber o tempo até a ocorrência do primeiro evento, o tempo decorrido até acontecer o primeiro evento, considerando um ponto aleatoriamente selecionado e, o tempo entre dois eventos sucessivos.

A determinação da probabilidade de um dado número X de sucessos em uma distribuição de Poisson é possível pela seguinte expressão: x -λ

P(Xλ ) = λ e ÷ X! onde : λ e

➽ ➽

número médio de sucessos no tempo ou espaço algarismo neperiano constante = 2,7183

No caso da distribuição exponencial, a determinação das probabilidades é dada pelas expressões: -λ (1) P(T≤t)=1-e -λ (2) P(T>t)=e onde: (1) ➽ é utilizada para determinar a probabilidade da ocorrência do primeiro evento dentro de um intervalo de tempo especificado.

(2) ➽ é utilizada para determinar a probabilidade de que o primeiro evento não ocorrerá dentro do intervalo de tempo especificado.

No caso em que o tempo de atendimento às solicitações de manutenções corretivas se comportarem como uma distribuição normal de probabilidade é possível estimar a probabilidade de que um atendimento específico seja concluído dentro do tempo solicitado pelo cliente/usuário.

•

Vide Kazmier 5 para maiores detalhes sobre essas distribuições de probabilidade.

Para se determinar a probabilidade, na distribuição normal, emprega-se a seguinte fórmula: z=(X-µ)÷σ onde: µ σ

➽ ➽

é a média da distribuição de probabilidade é o desvio padrão da distribuição

A seguir daremos alguns exemplos de aplicação. ➲

Utilização dos Modelos de Probabilidade

Probabilidade da Ocorência do Primeiro Evento Supondo que, em média, 5 solicitações de manutenção corretiva para um software sejam recebidas a cada 5 dias. Qual a probabilidade de que, a partir do término da manutenção corretiva, se passem 10 dias antes do recebimento da próxima solicitação? ( Distribuição Exponencial) λ para 5 dias é 1 λ para 10 dias é 2 -2 ( T > 10 ) = e = 0,13534 Neste exemplo a probabilidade seria de aproximadamente 13%.

Probabilidade De Que Sejam Recebidos Mais do Que X Solicitações Supondo que as solicitações de manutenções corretivas chegam aleatoriamente numa média de 10 para cada 20 dias. Qual a probabilidade de que sejam recebidas mais do que 30 solicitações em um mês?( Aproximação pela normal da distribuição de Poisson) Em virtude de que a média para um período de 30 dias é maior do que λ = 10, podemos empregar a distribuição normal para aproximar o valor da probabilidade de Poisson.• Neste caso µ = λ = 15 ( 10 ÷ 20 = .5; .5 x 30 = 15) σ=

λ = 3.87

z = (30,5 - 15) ÷ 3,87 ≅ 4.0 P(X ≥ 30,5 ) = P ( z ≥ + 4) = 0,5000 - 0,4999 = 0,0001 Neste caso a probabilidade de ocorrer mais de 30 solicitações em um mês é quase inexistente.

•

Existem tabelas padrões para as distribuições de Poisson e Normal dado λ e X.

Probabilidade do Recebimento de Um Número X de Solicitações Em média, são recebidas 5 solicitações de manutenção corretiva num período de uma semana. Qual a probabilidade de que, em uma semana selecionada aleatoriamente, sejam recebidas exatamente 6 solicitações? ( Distribuição de Poisson) 6

P (X = 6  λ = 5.0)

-5

⇒  (5) e  ÷ 6! ≅ 0.15 ou 15%

Probabilidade de Tempo de Atendimento - Exemplo 1 O tempo necessário para o atendimento a uma solicitação de manutenção corretiva é normalmente distribuída com média µ = 16 horas e desvio padrão σ = 4 horas. O cliente/usuário deseja um prazo de no máximo 10 horas. Qual a probabilidade de que a solicitação seja atendida no prazo exato de 10 horas?

(Distribuição Normal) z = ( 10 - 16 ) ÷ 4 = - 1,50 P ( X = 10) = 0,4332 ou 43% Probabilidade de Tempo de Atendimento - Exemplo 2 Considerando os mesmos parâmetros de média e desvio padrão do exemplo anterior, foi comunicado ao cliente/usuário que a solicitação de manutenção corretiva será atendida no prazo de 18 horas. Qual a probabilidade de que este compromisso não possa ser cumprido?

P ( X > 18 ) = z = (18 - 16) ÷ 4 = 0,50 = 0,5000 - 0,1915 = 0,3085 ou 31% Probabilidade do Tempo de Atendimento - Exemplo 3 Considerando os mesmos parâmetros de média e desvio padrão do exemplo exemplo 1, qual a probabilidade da solicitação ser atendida em menos de 10 horas?

P ( X < 10 ) = z = ( 10 - 16 ) ÷ 4 = -1,50 = 0,5000 - 0,4332 = 0,0668 ou ≅ 7%.

Ação Gerencial: O emprego de modelos de distribuição de probabilidade possibilita ao gerente balancear a carga de trabalho alocada aos software que se encontram em operação, assim como, através do bom senso que as probabilidades proporcionam, determinar compromissos que tenham a maior probabilidade de sucesso.

Falhas Esperadas do Software As falhas esperadas do software são determinadas a partir da intensidade de falha atual do produto.

Essas falhas podem ser determinadas utilizando-se as mesmas fórmulas empregadas no capítulo 7 quando da exposição das medições para estabelecer a intensidade de falha da primeira release do software. ⌦

Planejamento do Atendimento às Manutenções Adaptativas

As manutenções adaptativas podem ser vistas sob diversas formas, quais sejam: ➪ ➪ ➪

Reprojetar o software para adaptá-lo a um novo produto Alterar partes do código para acomodar novas características Integrar o código adaptado ao software e testar a nova release

Um dos únicos modelos que proporcionam a medição do esforço, prazo e custo de uma manutenção adaptativa é o COCOMO 1.

Estimativa do Esforço da Manutenção Adaptativa Objetivo: Determinar o esforço necessário para o atendimento a uma manutenção adaptativa.

Método de Determinação: A estimativa é dada pelas seguintes expressões: (1)

AAF = 0.40 (DM) + 0.30 (CM) + 0.30 (IM)

AAF DM

➽ ➽

CM IM

➽ ➽

fator de ajustamento de adaptação percentagem do projeto original ou atual que é modificado ( medido subjetivamente) percentagem do código que é modificado percentagem do esforço requerido para integrar e testar a adaptação, comparada com o esforço realizado para integrar e testar o software quando do seu desenvolvimento

(2)

EDSI = (ADSI) x ( AAF ÷ 100)

onde:

onde: EDSI ➽ ADSI ➽

número equivalente de instruções fontes número de instruções fontes entregues adaptadas do software Fontes de Informação: Análise da adaptação.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Com a informação do esforço, o gerente do projeto pode estimar o prazo requerido para o atendimento e os custos correspondentes.

Exemplo: Supondo uma modificação de 20% em relação ao projeto original do software; sendo que 30% do código deverá ser alterado e; 30% é o esforço requerido para integrar as adaptações ao software e testar a nova release. O software a ser adaptado tem 20 KDSI e é de modo orgânico.

(1) Cálculo do AAF 0.40 (20) + 0.30 (30) + 0.30 ( 30) = 26 (2) Cálculo do EDSI 20000 x ( 26 ÷ 100) = 5200 ou 5,2 KDSI (3) Cálculo do esforço

1,05•

Esforço = 2,4 (5,2)

= 13,55 H/M

Estimativa do Prazo da Manutenção Adaptativa Objetivo: Determinar o prazo necessário para o atendimento à manutenção adaptativa.

Método de Determinação: Utiliza-se a equação do COCOMO para estimar o prazo.

Fontes de Informações: Estimativa de esforço.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Utilizar a informação para calcular o orçamento do atendimento.

Exemplo: Supondo o esforço estimado do exemplo anterior, teríamos o prazo: 0,38

Prazo = 2.5 ( 13,55)

= 6,73 meses

Estimativa do Número de Profissionais Necessários Objetivo: Determinar o número de profissionais a serem alocados para o atendimento à manutenção adaptativa.

Método de Determinação: O número de profissionais é definido dividindo-se o esforço pelo prazo estimado.

Fontes de Informação: Estimativas de esforço e prazo.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Definir os recursos humanos e perfis necessários e alocá-los ao atendimento.

Exemplo: Conforme as estimativas de esforço e prazo, o número de profissionais necessários para o atendimento seria de 2.01 ou 2.

•

Equação de esforço do COCOMO, modo Básico.

Estimativa do Custo Manutenção Adaptativa Objetivo: Determinar o orçamento do atendimento à solicitação de manutenção adaptativa.

Método de Determinação: O custo é calculado multiplicando-se o custo médio do homem/mês pelo esforço estimado.

Fontes de Informações: Estimativa de esforço.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Negociar orçamento com cliente/usuário e alocar a verba necessária.

Exemplo: Supondo um custo médio de homem/mês a $ 3000, teríamos para um esforço de 6,73 H/M, um custo de $ 20.190 relativo ao atendimento.

Estimativa do Número de Defeitos A determinação do número de defeitos segue o mesmo raciocínio que o utilizado para o planejamento anual do atendimento. A diferença é que devemos multiplicar a densidade atual de defeitos do software, em 1000 linhas de instruções fontes, pelo EDSI ( número equivalente de instruções fontes).

Por exemplo, se a densidade atual é de 12 por 1000 e tivermos 5200 EDSI, o número de defeitos esperados seria de aproximadamente 62.

Estimativa de Esforço de Retrabalho da Manutenção Adaptativa Aqui o raciocínio é o mesmo dos exemplos anteriores relativos às estimativas de esforço de retrabalho, ou seja, esforço de retrabalho é função do tamanho da adaptação medida em EDSI e com possibilidade de ser transformada em pontos de função.

Por exemplo, 5200 EDSI em COBOL significam aproximadamente cerca de 57 pontos de função ( 91 linhas de instrução fonte representa 1 ponto de função).

Podemos portanto, utilizar a equação de regressão linear. Seria importante manter dados acerca do esforço médio de retrabalho correspondente à adaptação de 1 ponto de função.

Estimativa do Custo do Retrabalho da Manutenção Adaptativa O custo do retrabalho é o esforço multiplicado pelo custo médio do homem/mês ou do homem/hora. A forma de determinação é análoga aos exemplos anteriores para cálculo do custo de retrabalho. É bom recordar que este custo é crítico para o controle dos custos da má qualidade durante a manutenção/evolução do produto.

⌦

Planejamento de Projetos de Melhoria

O planejamento de projetos de melhoria contempla os mesmos elementos de estimativas realizados quando da ocasião do planejamento do projeto, ou seja, o tamanho do projeto de melhoria, o prazo , esforço, número de profissionais necessários,custo , defeitos esperados, esforço e custo de retrabalho.

Estimativa do Tamanho do Projeto de Melhoria Objetivo: Determinar o tamanho do projeto de melhoria em termos de pontos de função.

Método de Determinação: A característica do projeto de melhoria é a adição, remoção e/ou alteração de funções. Para tanto, utiliza-se da contagem dos pontos de função para projetos de melhoria ( “enhancement project”), tal como definido no “Couting Practice Manual “ do IFPUG 3.

A determinação dos pontos de função para projetos de melhoria é dada pela fórmula: EFP =  ( ADD + CHGA + CFP ) x VAFA  + ( DEL x VAFB) onde: EFP ADD CHGA CFP VAFA

é a contagem de pontos de função do projeto funções não ajustadas incluídas no software funções não ajustadas modificadas no software funções adicionadas como conversão (se houver) é o fator de ajustamento do projeto de melhoria após o término do projeto DEL ➽ funções não ajustadas deletadas do software VAFB ➽ é o fator de ajustamento do projeto de melhoria antes do seu início Para estimativa considera-se VAFA = VAFB. A determinação da complexidade das funções e dos pontos de função seguem os mesmos procedimentos aplicados pela metodologia#1 Nota: o modelo de ajustamento do COCOMO também pode ser utilizado para projetos de melhoria. ➽ ➽ ➽ ➽ ➽

Fontes de Informações: Análise de impacto do projeto de melhoria.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Com a estimativa do tamanho, as demais estimativas podem ser realizadas.

Exemplo: Supondo a adição de 20 PF’s, 10 PF’s modificados, nenhuma função convertida, uma fator de ajustamento de 1.05 e 5 PF’s deletados: EFP =  ( 20 + 10 + 0 ) x 1.05  + ( 5 x 1.05) = 36,75

Estimativa de Esforço do Projeto de Melhoria Emprega-se o mesmo raciocínio utilizado para a estimativa do esforço do projeto de software .

Uma alternativa é a conversão dos pontos de função em número de linhas de instruções fontes e aplicar os algoritmos do método COCOMO. Demais Estimativas As estimativas restantes de prazo, custo, número de profissionais necessários, defeitos esperados, esforço e custo de retrabalho seguem os procedimentos já discutidos para o planejamento de projetos ( capítulo 6) e para o planejamento anual de atendimento.

8.2.3 - Medições Para o Monitoramento do Atendimento O objetivo dessas medições é prover informações para a gestão do atendimento, considerando o conjunto de manutenções corretivas, adaptativas e projetos de melhoria. O atendimento normalmente é considerado no jargão da área de informática como “backlog” .

Essas medições concentram-se em: ➪ ➪ ⌦

Monitoramento do atendimento às solicitações de manutenções corretivas e pequenas manutenções adaptativas Monitoramento das manutenções adaptativas de porte significativo e dos projetos de melhoria Medições Para o Monitoramento do Atendimento às Manutenções Corretivas

Monitoramento do Backlog Objetivo: Avaliar o volume de solicitações recebidas e fechadas durante o mês.

Método de Determinação: Demonstrar graficamente o atendimento ao “backlog “ do software ao longo do tempo.

Fontes de Informações: Registros de solicitações recebidas e registros de solicitações fechadas.

Forma de Apresentação: gráfica.

Ação Gerencial: Esta medição permite ao gerente visualizar o nível de atendimento ao produto, comparando-a com a demanda de serviços requerida pelos clientes/usuários. Permite obter indícios de problemas em determinados módulos do software, verifificar fatores cíclicos, e “pistas” sobre a origem das solicitações.

Exemplo:

Número de Solicitações 100 80 40 20 0

1

2

3

4

5 6 Figura 8-5

7

8

9

meses

Legenda: Solicitações Recebidas Solicitações Fechadas Backlog Acumulado

Tempo Médio de Atendimento das Solicitações Objetivo: Determinar o tempo médio do atendimento às solicitações de manutenções ao longo do tempo.

Método de Determinação: A determinação do tempo médio mensal de atendimento é dada pela expressão: TMA = ∑ TASL ÷ NSLM onde: TASL ➽ NSLM ➽

Tempo de atendimento de cada solicitação abertas no mês Número de solicitações fechadas no mês

Fontes de Informações: Registros de atendimento de solicitações Forma de Apresentação: gráfica.

Ação Gerencial: Estabelecer o padrão de tempo do atendimento para as solicitações.

Exemplo: Tempo em Dias 20 15 10 5 0 1

2

3

4

5

6

meses

Figura 8-6

Tempo Médio do Backlog Em Aberto Objetivo: Determinar o tempo médio de permanência das solicitações no “backlog”.

Método de Determinação: A determinação do tempo médio de permanência é dada pela expressão: TMB = ∑ TPSLA ÷ NSLA onde: TPSLA ➽ NSLA ➽ Esta média é cumulativa.

Tempo de permanência da solicitação no backlog Número de solicitações em aberto no período

Fontes de Informações: Registros do atendimento às solicitações.

Forma de Apresentação: gráfica.

Ação Gerencial: O objetivo é diminuir ao máximo o tempo de pemanência pelo aumento da produtividade do atendimento ou pela eliminação das causas das solicitações.

Exemplo: Número de dias 50 40 30 20 10 0 1

2

3 Figura 8-7

4

5

6 meses

Origem das Solicitações Objetivo: Identificação da origem das solicitações de atendimento em relação aos clientes/usuários do software.

Método de Determinação: Registrar as frequências das solicitações por origem ao longo do tempo. As frequências podem ser plotadas de forma cumulativa até o ponto no tempo que se deseja medir ou serem plotadas mensalmente, a fim de permitir a visualização de tendências.

Fontes de Informações: Registros de atendimento.

Forma de Apresentação: gráfica.

Ação Gerencial: A identificação dos clientes/usuários que mais solicitam serviços de manutenção pode indicar potenciais problemas do não atendimento do software às necessidades dos mesmos; neste caso o gerente deverá determinar as causas e desenvolver e implementar contra-medidas para eliminá-las.

Exemplo:

% Número de Solicitações 50 40 30 20 10 0 Market.

Prod.

Figura 8-8

Financ.

Neste exemplo , para um tempo T qualquer , a maior frequência tem sido da área de marketing da empresa. Portanto deveriam ser analisadas as causas.

Frequência do Tipo de Solicitação Objetivo: Analisar a frequência das solicitações conforme o tipo, se corretiva ou adaptativa.

Método de Determinação: Registrar a frequência das solicitações por tipo ao longo do tempo. As frequências podem ser plotadas de forma cumulativa até o ponto no tempo que se deseja medir, ou serem plotadas mensalmente, a fim de permitir a visualização de tendências.

Fontes de Infomações: Registros de atendimento.

Forma de Apresentação: gráfica.

Ação Gerencial: A identificação dos tipos de solicitações pode indicar problemas potenciais no software no que tange a módulos com erros crônicos ou aqueles que são mais suscetíveis à adaptações.

Exemplo: Similar ao exemplo anterior em termos de representação gráfica.

Frequência de Solicitações Por Módulo do Software Objetivo: Determinar os módulos com indícios de serem módulos com erros crônicos ou aqueles mais suscetíveis à adaptações frequentes.

Método de Determinação: Registrar a frequência das solicitações por módulo do software, separando em corretivas e adaptativas. Considerar a frequência cumulativa até oponto no tempo que se deseja avaliar.

Fontes de Informações: Registros de atendimento.

Forma de Apresentação: gráfica.

Ação Gerencial: Caso for identificada uma incidência significante de solicitações que afetam um ou mais módulos do software, o gerente deverá tomar decisão quanto a refazer o módulo para eliminar defeitos ou falhas ou adequá-lo às necessidades dos clientes/usuários.

Exemplo:

% Solicitações Por Módulo/Manutenções Corretivas 100 80 60 40 20 0 A

B Figura 8-9

C

D

Módulos

Neste exemplo os módulos A e B representam 60% de todas as solicitações de manutenções corretivas e são, portanto, candidatos a uma análise mais profunda.

A mesma representação pode ser feita para as manutenções adaptativas.

Produtividade da Manutenção Corretiva/Adaptativa Objetivo: Determinar a produtividade das manutenções corretivas e adaptativas de pequeno porte.

Método de Determinação: A produtividade para manutenções corretivas, já que as mesmas são de difícil dimensionamento através da técnica de Pontos de Função, pode ser expressa em Linhas de Instruções Fontes por homem/hora.Deve-se considerar as linhas que compõem a parte do software a ser corrigida. É apropriado verificar a produtividade média ao longo do tempo.

Uma possibilidade é transformar as linhas de instruções fontes em pontos de função conforme a tabela de transformação apresentada no capítulo 6.

Fontes de Informação: Registros de atendimento.

Forma de Apresentação: gráfica.

Ação Gerencial: Avaliar a produtividade ao longo do tempo e contrapor com os padrões da produtividade para este tipo de atendimento e verificar causas das variações.

Exemplo: Produtividade Média em Instruções Fontes por Homem/Hora 50 40 30 20 10 0 1

2

3 Figura 8-10

4

5

6 meses

⌦

Monitoramento das Manutenções Adaptativas de Porte e de Projetos de Melhoria

As medições relativas a estes tipos de atendimento são análogas às empregadas para o processo de desenvolvimento de software, ou seja: Gestão da Qualidade Progresso na remoção de defeitos Defeitos restantes Desvio da estimativa de defeitos Composição dos tipos de defeitos Composição das classes de defeito Densidade de defeitos da inspeção Eficiência da Remoção de Defeitos do Processo de Inspeção Taxa de exame por inspeções Taxa de preparação por inspeção Tamanho do material inspecionado por inspeções Complexidade dos Módulos Objetivos de intensidade de falhas Monitoramento do Progresso Progresso na elaboração de produtos Acompanhamento físico Gestão de Recursos e Financeira Estimativa atualizada do tamanho do software Estimativa atualizada de prazo Estimativa atualizada de esforço Estimativa atualizada de alocação de recursos Acompanhamento financeiro do projeto Estimativa atualizada do custo do projeto

Comportamento do custo do retrabalho Gestão de Mudanças Monitoramento de mudanças nos requisitos Origens dos incrementos/mudanças 8.2.4 - Medições Para o Monitoramento da Evolução do Produto As medições para o monitoramento do projeto concentram-se na avaliação contínua da melhoria da qualidade, da produtividade e dos aspectos de custo do produto ao longo de sua vida útil. As informações são coletadas durante o atendimento às solicitações.

A gestão da qualidade do produto tem como referencial as medições acerca da densidade de defeitos , intensidade de falhas e índice de manutenção, todas vistas ao longo da vida útil do software. O objetivo neste caso é o de aperfeiçoar constantemente a qualidade do produto.

A gestão da qualidade está relacionada à produtividade e ao comportamento dos custos. A intenção é que a relação qualidade ➽ produtividade ➽ custos seja validada.

Dessa forma, a produtividade também deve ser monitorada e o reflexo sobre os custos analisado.

As análises desses fatores devem realimentar a execução do atendimento, objetivando aumentar a satisfação dos clientes/usuários conforme custos econômicos da qualidade. ⌦

Gestão da Qualidade do Produto

Monitoramento da Densidade de Defeitos do Produto Objetivo: Verificar o estágio atual da qualidade do produto, bem como inferir tendências acerca da densidade de defeitos.

Método de Determinação: O tratamento da densidade de defeitos do produto ao longo do tempo deve considerar cada release do software, seja ela motivada por manutenções adaptativas ou projetos de melhoria. Dessa forma, ao final de cada manutenção adaptativa ou projeto de melhoria, deve-se determinar a densidade de defeitos da release. A densidade de defeitos deve ser plotada contra as releases, evidenciando progresso ou não da qualidade, bem como indicando o padrão da densidade. Para fins de controle podemos utilizar também a ferramenta - gráfico de controle estatístico, confrontando as densidades de defeitos de cada release com os limites de controle da densidade média relativa a todos os produtos da instalação. A densidade de

defeitos deve ser estabelecida por 1000 linhas de insruções fontes ou por pontos de função.

Fontes de Informação: Registros de densidade de defeitos coletados ao término das manutenções adaptativas e projetos de melhoria.

Forma de Apresentação: gráfica.

Ação Gerencial: A ação gerencial requerida para produtos com densidade de defeitos fora dos limites de controle é a avaliação dos fatores possíveis de causa para a variação, que podem ser equipamentos/ambiente operacional, métodos empregados, perfil da equipe técnica e de usuários e assim por diante.Caso a gerência já tenha implementado novas técnicas para a melhoria da qualidade e as mesmas não surtiram efeito, o que é evidenciado por releases com alta densidade de defeitos, deve-se realizar nova análise das causas, ou seja, girar o ciclo PDCA de Deming.

Exemplo: Densidade de Defeitos Por 1000 Linhas 50 40 30 20 10 0 1

2

3 4 Releases Figura 8-11

5

6

Neste exemplo a densidade de defeitos sofre queda da release 1 para a 3, tem uma subida substancial da release 3 para a 4 e cai novamente, estabilizando-se na release 6, o que significa que os métodos de controle da qualidade surtiram efeito positivo.

O gráfico de controle pode ser empregado para produtos que já estejam relativamente maduros, ou seja, a partir de uma determinada release, as demais podem ser plotadas no gráfico.

Monitoramento da Intensidade de Falhas do Produto Objetivo: Verificar o nível de intensidade de falhas do produto ao longo do tempo.

Método de Determinação: A intensidade de falhas do produto também pode ser monitorada da mesma forma como a densidade de defeitos. Ao término de cada manutenção adaptativa e projetos de melhoria a intensidade deve ser calculada e plotada graficamente para demonstrar o comportamento do produto quanto a este fator. Aqui também o gráfico de controle pode ser útil.

Fontes de Informações: Cálculo da intensidade de falhas ao final de cada release.

Forma de Apresentação: gráfica.

Ação Gerencial: A ação gerencial requerida para produtos com intensidade de falhas fora dos limites de controle é a avaliação dos fatores possíveis de causa para a variação, que podem ser equipamentos/ambiente operacional, métodos empregados, perfil da equipe técnica, estado do código e assim por diante.Caso a gerência já tenha implementado novas técnicas para a melhoria da qualidade e as mesmas não surtiram efeito, o que é evidenciado por releases com alta intensidade de falhas, deve-se realizar nova análise das causas, ou seja, girar o ciclo PDCA de Deming.

Exemplo: Similar ao exemplo apresentado para densidade de defeitos. Índice de Manutenção do Produto Objetivo: Identificar o impacto das manutenções adaptativas e projetos de melhoria sobre os módulos do software em termos da propagação e abrangência, bem como as frequências de manutenção por módulo.

Método de Determinação: A partir dos registros de solicitações e atendimento, identificar o manuseio de módulos por manutenção ou projeto de melhoria, assim como a frequência das manutenções por módulo do software. Considerar esta análise ao longo do tempo. A análise pode considerar as manutenções isoladamente ou no conceito de release.

Fontes de Informações: Registros de atendimento às solicitações.

Forma de Apresentação: gráfica.

Ação Gerencial : A análise do índice de manutenção do produto e seu impacto subsidia decisões quanto a refazer um ou vários módulos do produto ou até mesmo decidir sobre o seu descarte ou substituição.

Exemplo: Módulos Manuseados Por Release 50 40 30 20 10 0 1

2

3

4 Releases Figura 8-12

5

6

Neste exemplo, há um crescimento significativo no número de módulos manuseados, na medida em que novas releases do produto vão sendo liberadas. Isto pode significar um produto altamente instável e que necessita sofrer uma revisão profunda. Produtos instáveis possuem alta densidade de defeitos.

Para representar a incidência de manutenções por módulos do produto, podese empregar a mesma representação gráfica mostrada no exemplo da medição - Frequência de Solicitações Por Módulos do Software.

⌦

Medições Relativas à Produtividade e aos Custos

Produtividade de Manutenções Adaptativas e Projetos de Melhoria Objetivo: Determinar a produtividade das manutenções adaptativas e projetos de melhoria e analisar tendências.

Método de Determinação: A produtividade é determinada pela relação do número de pontos de função mantidos ( na adaptação ) ou incrementados pelo projeto de melhoria sobre o esforço correspondente, registrado quando do término do atendimento. A produtividade pode ser comparada com os padrões da instalação ou entre releases.

Fontes de Informação: Registros de esforço e do tamanho do software após o atendimento.

Forma de Apresentação: gráfica.

Ação Gerencial: Identificar as causas de baixa produtividade. Realizar experimentos com utilização de novas técnicas de manutenção.

Exemplo: Produtividade da Manutenção Projetos de Melhoria 50 40 30 20 10 0 1

2

3 Releases Figura 8-13

4

5

Custos do Ponto de Função de Manutenção Adaptativa e Projetos de Melhoria Objetivo: Determinar o custo do ponto de função de manutenções adaptativas e projetos de melhoria.

Método de Determinação: O custo do ponto de função é determinado através da divisão do custo da manutenção ou do projeto de melhoria pelo número de pontos de função ajustados. O custo pode ser representado por período de tempo para cada tipo de atendimento e por release.

Fontes de Informações: Registros de custos da manutenção ou projeto de melhoria e o cálculo dos pontos de função relativos à manutenção ou projeto de melhoria.

Forma de Apresentação: gráfica.

Ação Gerencial: Verificar causas de aumento do custo do ponto de função.

Exemplo:

Custo do Ponto de Função 300 200 100 50 0 1

2

3 Figura 8-14

4

5

6 meses

Legenda: Custo do PF Manutenções Adaptativas Custo do PF de Projeto de Melhoria

A representação desta medição pode ser feita considerando-se releases. Neste caso deve-se diferenciar o tipo de release ( oriunda de adaptações ou de projetos de melhoria).

8.3 - Medições Para o Aperfeiçoamento dos Processos de Planejamento de Projetos,de Desenvolvimento de Software e de Gestão de Produtos As medições realizadas para o monitoramento do produto, bem como as que devem ser feitas ao final de cada atendimento, formam o conjunto de informações que vão apoiar o aperfeiçoamento do processo de planejamento de projetos, do processo de desenvolvimento de software e do próprio processo de gestão do produto. Essas medições também devem compor o banco de dados de métricas de forma que os padrões da instalação sejam estabelecidos.

Essas medições compreendem: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Eficiência da Remoção de Defeitos Verificação da Exatidão das Estimativas Tamanho Atual do Software Crescimento Funcional Relativo do Software Crescimento Funcional Médio do Software Complexidade Atual do Software Custo da Qualidade Índice de Tecnologia de Manutenção/Melhoria Empregado Índice de Tecnologia de Gestão Empregado Demais Medições Qualitativas

A seguir detalharemos cada uma dessas medições.

Eficiência da Remoção de Defeitos do Processo Objetivo: Determinar a eficiência da remoção de defeitos do processo de desenvolvimento.

Método de Determinação: A eficiência da remoção de defeitos é dada pela expressão: ∑ DPR ÷ (

∑ DPR + ∑ DPO )

onde: DPR

Defeitos Pré-Release identificados durante o desenvolvimento DPO ➽ Defeitos Pós-Release identificados durante a operação do software até um período de tempo determinado O tempo de operação do software, para fins de registro dos defeitos pós-release, vai depender do tempo necessário para que todas as suas funções sejam utilizadas pelos clientes/usuários.

Fontes de Informação: Processo de inspeção durante o desenvolvimento e registros de solicitações de manutenções corretivas.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo que foram identificados 700 defeitos pré-release e 400 pós-release; a eficiência seria de 64%, ou seja, o processo de desenvolvimento do software específico conseguiu identificar e remover cerca de 64% dos defeitos introduzidos no software. ➽

Este valor hipotético poderia ser comparado com o padrão da eficiência da remoção de defeitos da instalação, que é a média das eficiências de todos os projetos que foram desenvolvidos para a mesma plataforma de hardware/software e utilizando a mesma metodologia de desenvolvimento.

Verificação da Exatidão das Estimativas Essas medições têm a finalidade de verificar a variação das estimativas realizadas pelo planejamento de atendimento anual e pelo planejamento de atendimento específico.

Os algoritmos genéricos para determinação da exatidão da estimativa são dados pelas expressões: No caso da estimativa for menor que o realizado: ExE = ( E/R) x 100 No caso da estimativa for maior que o realizado ExE =  1 -  ( E/R ) -1  x 100 onde: ExE E R

➽ ➽ ➽

Exatidão da estimativa Valor do item estimado Valor obtido do item ao final do processo

Este algoritmo é o mesmo explicitado para as medições de exatidão das estimativas apresentadas no item 7.3.4.

A seguir são listadas as medições possíveis de serem realizadas quanto a este tópico.

Exatidão da Estimativa de Esforço Anual de Atendimento Exatidão da Estimativa do Número de Profissionais Para o Atendimento Anual Exatidão da Estimativa do Custo Anual de Atendimento Exatidão da Estimativa de Defeitos Esperados do Atendimento Anual Exatidão da Estimativa do Esforço de Retrabalho do Atendimento Anual Exatidão da Estimativa do Custo de Retrabalho do Atendimento Anual Exatidão da Estimativa do Esforço da Manutenção Adaptativa Exatidão da Estimativa do Prazo da Manutenção Adaptativa Exatidão da Estimativa do Número de Profissionais Necessários Para a Manutenção Adaptativa Exatidão da Estimativa do Custo da Manutenção Adaptativa Exatidão da Estimativa do Número de Defeitos da Manutenção Adaptativa Exatidão da Estimativa do Esforço do Retrabalho da Manutenção Adaptativa Exatidão da Estimativa do Custo de Retrabalho da Manutenção Adaptativa Exatidão da Estimativa do Tamanho da Manutenção Adaptativa Exatidão da Estimativa do Tamanho do Projeto de Melhoria Exatidão da Estimativa do Esforço do Projeto de Melhoria Exatidão da Estimativa do Prazo do Projeto de Melhoria Exatidão da Estimativa do Número de Profissionais Necessários Para o Projeto de Melhoria Exatidão da Estimativa do Custo do Projeto de Melhoria Exatidão da Estimativa do Número de Defeitos do Projeto de Melhoria Exatidão da Estimativa do Esforço do Retrabalho do Projeto de Melhoria Exatidão da Estimativa do Custo de Retrabalho do Projeto de Melhoria Tamanho Atual do Software Durante os projetos de manutenção adaptativa e de projetos de melhoria o tamanho do software pode ter alterado, em termos de inclusão de funções, substituição de funções, remoção de funções e alteração de funções.

Quando houver estes eventos pode-se utilizar a a metodologia #1 preconizada pelo IFPUG para fins de contagem do tamanho atual do software.

No caso de somente haver inclusão de funções, pode-se calcular o tamanho do ponto de função pelo uso da expressão: ( FPRA + FPAD ) x NFA = TAS onde: FPRA ➽ FPAD ➽ NFA ➽

Tamanho em pontos de função da release anterior Tamanho do projeto de melhoria em pontos de função Fator de ajustamento da nova release

Crescimento Funcional Relativo do Software Objetivo: Determinar o crescimento funcional relativo do software em função de manutenções adaptativas e projetos de melhoria.

Método de Determinação: A determinação do crescimento funcional relativo do software é dada por: CRTS = ( IPFMP ÷ FPRA ) x 100 onde: IPFMP ➽

Incremento do software em pontos de função a partir da manutenção adaptativa ou do projeto de melhoria FPRA ➽ Tamanho em pontos de função da release anterior Fontes de Informação: Contagem do tamanho atual do software e tamanho da release anterior.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo que foram adicionados 100 pontos de função a partir de uma manutenção adaptativa ou projeto de melhoria em uma release de tamanho 1200, o crescimento funcional relativo seria de 8,33%.

Crescimento Funcional Médio do Software Objetivo: Determinar o crescimento funcional médio do software ao longo do tempo.

Método de Determinação: O CFM é determinado pela expressão: CFM = ∑ CRFA ÷ n onde: CRFA ➽ Crescimento funcional anual n ➽ número de anos do atendimento sendo que: CFRA é determinado pelo crescimento funcional do software ao longo de um ano.

Fontes de Informação: Contagem dos pontos de função das releases.

Forma de Apresentação: nenhuma específica.

Exemplo: Supondo que num período de 4 anos foram observados CRFA’s respectivos de 20%, 30% 40% e 20%. O CFM seria portanto de 27,5 %.

Complexidade Atual do Software Para a determinação da complexidade atual do software, pode-se utilizar o modelo preconizado por Card & Glass 2.

A complexidade deverá ser recalculada em razão das alterações de complexidades dos módulos manutenidos e/ou em razão de novos módulos adicionados.

Para fonte de referência quando do cálculo da complexidade atual, é importante a manutenção do Diagrama Hierárquico do Sistema (DHS) atualizado.

Custo da Qualidade A fórmula do cálculo do custo da qualidade é análoga à apresentada para a determinação do custo da qualidade de projetos de software, conforme o capítulo 7.

O custo da qualidade pode ser calculado para cada atendimento , principalmente no tocante à manutenção adaptativa e projetos de melhoria.

O somatório do custo da qualidade de cada atendimento, considerando o período de um ano, nos fornece o custo da qualidade do atendimento anual ao produto.

Este custo pode ser comparado com o custo do atendimento, para verificar a relação entre ambos.

O objetivo é que os custos de falhas internas ( retrabalho) sejam minimizados. Índice de Tecnologia de Manutenção/Melhoria Empregado Igualmente ao índice de tecnologia de desenvolvimento, este índice também tem por objetivo determinar o nível de sofisticação da tecnologia aplicada durante o atendimento (manutenção adaptativa ou projeto de melhoria).

Entretanto há algumas diferenças entre a medição para manutenção adaptativa e projetos de melhoria.

Para projetos de melhoria devemos utilizar os mesmos componentes que o índice de tecnologia de desenvolvimento. Portanto o instrumento de medição é o mesmo.

O método de determinação também baseia-se no somatório de pesos multiplicados por notas e dividido pelo somatório dos pesos, isto é , uma média ponderada.

A seguir apresentaremos o instrumento de medição para manutenções adaptativas.

Ambiente da Manutenção ( peso 5) a) Não há apoio eletrônico para elaboração dos documentos do projeto; não há biblioteca técnica disponível para as equipes de projeto; sem automação do controle de versões dos componentes do software; um terminal ou micro para cada quatro analistas/programadores; ferramentas mínimas de depuração; as equipes de projetos não possuem área reservada; não existe áreas para armazenagem de materiais, listagens; não existem salas de reunião disponíveis para revisões técnicas e não há monitoramento de defeitos. ( Nota 1 ) b) Algum suporte de edição de textos para a documentação de projetos; pequena e escassa biblioteca técnica; controle das versões para o código-fonte; a documentação é controlada manualmente; um terminal/micro para cada analista/programador; algumas ferramentas de depuração; escritórios

compartilhados por três ou quatro analistas/programadores; uma ou duas salas de reunião; sistema manual de registro de erros. ( Nota 3 ) c) Apoio informatizado para a documentação do projeto; boa biblioteca técnica a disposição para as equipes de projetos; controle de versões de componentes de software automatizado; um terminal/micro para cada analista/programdor, com terminais extras como “backup”; ferramentas de depuração; bibliotecas de testes; espaço adequado aos analistas/programadores com áreas de armazenagem adequadas; salas de reunião adequadas. ( Nota 5 ) Utilização de Ferramentas de Apoio à Manutenção ( peso 5) ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒

Verificador de sintaxe Depurador interativo Prototipador Gerador de telas Gerador de relatórios Gerador de gráfico Gerador de código-fonte Otimizadores Linguagens com facilidades de depuração Gerador de dados para teste Dicionário de dados Documentador automático Analisador de código Utilitários de otimização de banco de dados Controle automatizado de versões Ferramenta de apoio à reestruturação do código

0 a 3 itens assinalados 4 a 6 itens assinalados 7 a 9 itens assinalados 10 a 13 itens assinalados 14 a 16 itens assinalados

nota 1 nota 2 nota 3 nota 4 nota 5

Utilização de Técnicas e Métodos de Remoção de Erros (peso 5) ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒

Revisão dos requisitos Revisão da alteração na estrutura lógica do sistema Revisão da alteração no projeto físico de banco de dados Revisão dos projetos de rotinas automatizadas Inspeção e revisão do código Verificação e validação independente Teste de exatidão de algoritmos Teste de programas individuais Teste de unidade de implantação Teste integrado Teste de desempenho

❒ ❒ ❒ ❒ ❒

Teste de aceitação Teste de campo Organização de teste independente Análise de módulos com erros crônicos Investigação da satisfação do usuário

0 a 3 itens assinalados 4 a 6 itens assinalados 7 a 9 itens assinalados 10 a 12 itens assinalados 13 a 16 itens assinalados

nota 1 nota 2 nota 3 nota 4 nota 5

Reutilização de Código e Módulos ( peso 5 ) a) Nenhuma reutilização ( nota 1 ) b) Até 15% de reutilização ( nota 2 ) c) Entre 16 a 25% de reutilização (nota 3) d) Entre 26% a 50% de reutilização ( nota 4) e) Acima de 50% ( nota 5) Índice de Tecnologia de Gestão Empregado Tanto para as manutenções adaptativas como projetos de melhoria a forma de medição é a mesma que a empregada para projetos de software ( vide capítulo 7).

Demais Medições Qualitativas Essas medições fornecem as “pistas” necessárias para a identificação das causas de baixa qualidade e produtividade.

As medições qualitativas, tanto para manutenções adaptativas como para projetos de melhoria compreendem: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Perfil da equipe técnica alocada à manutenção/projeto de melhoria Novidades das especificações da adaptação/projeto de melhoria Experiência da equipe com o software Envolvimento dos usuários Experiência da equipe com métodos de remoção de erros Geografia do desenvolvimento Coesão técnica apresentada durante o projeto Estrutura e estado do código base do software Principais ocorrências

Perfil da Equipe Técnica Alocada Em relação ao ambiente de desenvolvimento/manutenção: ❒

Experiência nas ferramentas de apoio ao desenvolvimento

❒ ❒ ❒ ❒ ❒

Experiência nos métodos e técnicas de análise e projeto Experiência nas linguagens de programação Experiência em métodos e técnicas de revisões e inspeções Experiência em técnicas de teste de sistemas Experiência no hardware de desenvolvimento

Estabelecer o percentual, conforme o total dos membros da equipe em termos de: Pouca experiência - até 2 itens assinalados :_____% Média exoeriência - 3 e 4 itens assinalados:_____% Grande experiência - 5 e 6 itens assinalados:_____% Novidades das Especificações da Adaptação/Melhoria a) Nenhuma novidade b) Pouca novidade c) Média novidade d) Grande novidade e) Especificações totalmente desconhecidas pela equipe Experiência da Equipe Com o Software a) Nenhuma experiência b) Pouca experiência c) Média experiência d) Grande experiência e) Domínio da área de aplicação Envolvimento dos Usuários a) Nenhum envolvimento b) Pouco envolvimento c) Médio envolvimento d) Grande envolvimento e) Total participação, inclusive com usuários alocados “full-time” ao projeto Experiência da Equipe Com Métodos de Remoção de Erros a) Nenhuma experiência b) Pouca experiência c) Média experiência d) Grande experiência e) Domínio completo Geografia do Desenvolvimento a) Projeto foi desenvolvido em um único local b) Projeto foi desenvolvido em mais de um local na mesma cidade c) Projeto foi desenvolvido com participação de várias fornecedores numa mesma cidade

d) Projeto foi desenvolvido por equipes distribuídas em diversas cidades e) Projeto foi desenvolvido com participação de equipes distribuídas em diversos países Coesão Técnica Apresentada Durante o Projeto a) Nenhuma coesão técnica entre os membros b) Pouca coesão técnica c) Média coesão técnica d) Grande coesão técnica e) Coesão técnica total Origem do Código Base• ❑ ❑ ❑ ❑ ❑

Desenvolvido internamente na empresa Desenvolvido em outro local da empresa Desenvolvido sob encomenda por contrato Adquirido de terceiros Código base veio de várias fontes

Idade do Código Base ❑ ❑ ❑ ❑ ❑

Menos de um ano Entre um e dois anos Entre dois e quatro anos Entre quatro e seis anos Acima de seis anos

Estado do Código Base ❑ ❑ ❑ ❑ ❑

Estabilizado Estabilizando-se Instável Propenso a erros Extremamente instável

Ocorrências Aqui também sugerimos o registro das ocorrências principais relativas à manutenção adaptativa e projetos de melhoria, as quais fornecem informações qualitativas para avaliar os resultados do atendimento.

Este capítulo culmina a apresentação das medições operacionais do software , conforme classificação discutida no capítulo 4.

•

Os itens de 8 a 10 foram adaptados de Capers Jones 4

O próximo capítulo apresenta o tratamento dado às medições operacionais, cuja transformação vão determinar as medições para o gerenciamento do ambiente de software como um todo.

REFERÊNCIAS 1.

BOEHM, Barry. Software Cliffs,New Jersey,1981.

Engineering

Economics.Prentice-Hall,

Englewood

2. CARD,D.N. & GLASS, P.L. Measuring Software Design Quality.PrenticeHall,Englewood Cliffs,New Jersey, 1990.

3.

IFPUG. Function Point Westerville,Ohio,1994.

Counting

Practice

Manual

-

Release

4.0.

4. JONES, Capers. Applied Software Measurement. McGraw-Hill,New York,1991.

5. KAZMIER, L.J. Estatística Aplicada a Economia e Administração. McGraw-Hill,São Paulo, 1982.

Capítulo

9 GESTÃO DO AMBIENTE DE SOFTWARE A gestão do ambiente do software consiste na gestão do ponto de vista de um gerente de desenvolvimento ou um gerente de informática. Não somente está vinculado a um projeto ou a um produto específico, mas também no conjunto dos projetos e produtos da instalação como um todo. É o nível tático de gestão.

Neste nível a preocupação é avaliar a qualidade dos processos de planejamento de projetos, de desenvolvimento de software e de gestão dos produtos em utilização, visando atingir patamares cada vez mais elevados de qualidade sob o conceito de melhoria contínua.

Para tanto, as medições operacionais devem ser agregadas a fim de permitir: a análise de tendências de determinados indicadores, que pode subsidiar ações para reversão ou sustentação dessas tendências; a análise de impactos da introdução de novas tecnologias sobre a qualidade e produtividade, que pode auxiliar na decisão sobre quais combinações de elementos de tecnologia garantem melhores resultados; a análise de atributos, que permite a comparação da qualidade e produtividade entre plataformas, metodologias, áreas de aplicação, habilidades técnicas de pessoal e assim sucessivamente.

O tratamento dado para a agregação das medições operacionais também tem a finalidade de criar os padrões de medidas de acordo com os três fatores, ou seja, plataforma de hardware/software , metodologia de desenvolvimento ( tipo de processo) e área de aplicação do software na empresa ( há áreas cuja dinâmica tornam as soluções informatizadas muito voláteis), sujeitas à mudanças constantes.

Criando os padrões de medidas para a instalação, a gerência fica em posição de monitorar o comportamento dos projetos e produtos individualmente, de compará-los e verificar a adequabilidade dos respectivos processos e necessidades de implementar melhorias e analisar resultados.

Devemos atentar para o fato de que um dos maiores problemas para a gerência do desenvolvimento é o controle da alocação de pessoal entre os diversos projetos e serviços. Se faz imprescindível, para organizações de porte médio e grande, uma sistemática de controle de alocação. Este controle deverá permitir saber quem está alocado em que, por quanto tempo, quem já está comprometido com projetos ou serviços planejados para começar e quais as folgas ( intervalos de datas) disponíveis relativas a cada recurso humano.

Nossa experiência tem demonstrado que cerca de 50% ( ou mais) do tempo produtivo de um gerente de desenvolvimento é despendido cuidando de assuntos relativos a pessoal e sua alocação, incluindo questões burocráticas.

A essência da gestão do ambiente de software é mostrada pela Figura abaixo.

GESTÃO OPERACIONAL Planejamento de Projetos

Desenvolvimento do Software

Gestão do Produto

Estímulos Externos Monitora Demanda de Serviços

Gere Recursos Analisa Tendências

Analisa Capacidade

Analisa Impactos Decisão/ Ação

Analisa Atributos Modelagem Ambiente

Consolida Medições Operacionais

Cria os Padrões

GESTÃO DO AMBIENTE Figura 9-1

Através de estímulos externos, oriundos de várias áreas da organização, as demandas por serviços são geradas no que diz respeito a novos projetos de software, manutenções corretivas, manutenções adaptativas e projetos de melhoria.

A primeira providência é analisar a capacidade de atendimento do ambiente de desenvolvimento a fim de planejar a alocação de recursos, sejam eles internos ou externos ( empresas terceirizadas).

O controle do progresso dos projetos e serviços de manutenção/melhoria e do planejamento dos projetos e serviços que ainda não tiveram o seu início, juntamente com o quadro de alocação de recursos atual e previsto, fornecem a base para a análise de capacidade.

A análise de capacidade de atendimento não se limita somente aos aspectos quantitativos mas também aos aspectos qualitativos dos recursos. Na nossa área, quantidade não representa condição para aumento da produção. Pode ser até fator de aumento dos custos, visto a intensa necessidade por treinamento formal e “on the job”.

A experiência observada em vários ambientes de desenvolvimento tem demonstrado que um técnico com potencial somente domina uma metodologia de desenvolvimento após o terceiro projeto. Conforme for o porte dos projetos isto pode representar mais de três anos. Com a cultura gerencial de resultados imediatos instalada no Brasil, a qualidade dos recursos torna-se mais importante.

O Monitoramento diz respeito à verificação do andamento físico e financeiro dos projetos , serviços e produtos, considerando também os aspectos de qualidade dos mesmos, comparação com os padrões da instalação , subsidiando decisões e respectivas ações para correção de rumos. Esta abordagem permite a gestão por exceção.

A Gestão dos Recursos refere-se a alocação e realocação de recursos entre os projetos e serviços, considerando recursos humanos, recursos computacionais, investimentos em novas tecnologias, metodologias, ambiente físico de trabalho, treinamento, organização dos recursos e etc.

A Análise de Tendências é realizada a partir da consolidação das medições operacionais e tenta prever o comportamento futuro de determinados atributos do ambiente como um todo e de produtos de software específicos.

A Análise de Impacto é realizada para verificar o acerto ( ou não) de decisões quanto à introdução de novas tecnologias de desenvolvimento sobre a qualidade, a produtividade e aspectos financeiros (custos) relativos aos principais processos.

A Análise de Atributos refere-se a elaboração de comparações entre plataformas e tecnologias de desenvolvimento , considerando também a qualidade, produtividade e aspectos financeiros.

Estes componentes do modelo do gestão do ambiente, tomados no conjunto, fornecem os elementos necessários para os processos de tomada de decisão que, por sua vez, produzirão ações para o apoio e a correção de rumos da gestão operacional. ⌦

Medições Para o Monitoramento do Ambiente

Essas medições concentram-se na verificação dos projetos de software e no atendimento aos produtos que, em determinado momento, estão fora dos padrões em termos da qualidade , atendimento ao prazo , produtividade e custos.

Verificação de Projetos/Produtos Com Desvio do Padrão de Qualidade Objetivo: Verificar projetos e produtos que apresentam densidade de defeitos fora dos limites de controle.

Método de Determinação: Comparar a densidade de defeitos dos projetos, conforme a fase que se encontram, e dos produtos de acordo com as releases, com os padrões respectivos de densidade de defeitos, considerando os atributos principais de plataforma de hardware/software, metodologia de desenvolvimento e área de aplicação do software.

Fontes de Informações: Processos de inspeção realizados nos projetos e produtos.

Forma de Apresentação: gráfica ou tabular.

Ação Gerencial: Realizar análise dos resultados das inspeções para verificar incidência de tipos de defeitos e identificar causas prováveis. Auditar métodos de gestão dos projetos e produtos, utilização da metodologia de desenvolvimento e qualificação do pessoal alocado.

Exemplo: Análise de Projetos - considerando os atributos plataforma,metodologia e área de aplicação. Para esta análise a instalação deveria delimitar os limites de controle por fase do projeto.

Densidade em 1000 linhas

Tabela 9-1

Projeto

Fase

Densidade Até a Fase

Limites de Controle

Variação da Média

Projeto A Projeto B Projeto C Projeto D

Especificação Especificação Projeto Detalhado Projeto Detalhado

70 60 50 10

50 a 20 50 a 20 40 a 15 40 a 15

+133% +100% +150% -50%

Análise de Produtos - aqui pode-se delimitar limites de controle de acordo com o número da release.

Densidade em 1000 linhas

Tabela 9-2

Produto

Release

Densidade da Release

Limites de Controle

Variação da Média

Produto A Produto B Produto C Produto D

5 3 2 4

20 30 30 25

5 a 12 8 a 20 12 a 25 7 a 14

+150% +114% +67% +108%

Verificação dos Projetos Com Desvio da Estimativa de Prazos Objetivo: Verificar os projetos que apresentam desvio acentuado da estimativa de prazo conforme o planejado.

Método de Determinação: Através da exatidão das estimativas dos prazos das fases dos projetos e da estimativa atualizada, podemos selecionar aqueles que apresentaram o desvio mais acentuado e que merecem atenção gerencial.

Fontes de Informações: Registros de controle do progresso dos projetos , medições quanto à exatidão das estimativas e estimativas atualizadas de prazos.

Forma de Apresentação: gráfica ou tabular.

Ação Gerencial: Identificar as causas de atraso e definir, junto com o gerente do projeto, estratégias alternativas para eliminar o atraso ou diminuir a variação prevista entre o realizado e o planejado.

Exemplo: Esta medição também pode ser aplicada para manutenções adaptativas e projetos de melhoria de porte significativo.

Tabela 9-3

Projeto

B C D

Fase

Descrição Especif.

Especif.

Proj.Detal.

Planej.

2 1 3

Estimativa do Término do Projeto

Realiz.

4 3 5

ExE 50% 33% 60%

Incial 10 7 11

Variação em Relação à Estimativa Inicial

Atual 12 9 13

+20% +29% +18%

Neste exemplo consideramos uma propagação linear do atraso o que nem sempre ocorre.

Verificação dos Tempos do Atendimento às Manutenções Corretivas Objetivo: Identificar e analisar o desempenho do atendimento de manutenções corretivas e adaptativas de pequeno porte em termos da variação em relação aos limites de controle e à média dos tempos padrões de atendimento.

Método de Determinação: Para cada produto/release ou de forma agregada, devemos estabelecer os limites de controle em relação aos tempos de atendimento padrões da instalação para manutenções corretivas. A partir dos registros de atendimento podemos selecionar os casos que sofreram desvios em relação aos padrões.

Fontes de Informações: Tempos padrões e registros do atendimento.

Forma de Apresentação: gráfica ou tabular.

Exemplo: Considerando o tempo de atendimento médio agregado da instalação para manutenções corretivas e a medição realizada em um mês específico.

Tempos Padrões em Dias 30

▲ ▲ ▲ LSC

20 ▲

▲ µ

10

LIF

0 Solicitações Produtos

▲

S1 PA

S8 PD

S12 PA

S20 PC

S23 PD

S26 PF

Figura 9-2

Neste exemplo, as solicitações S1,S8,S12,S20,S23 e S26 estão fora dos limites de controle. Cada uma relativa a um produto específico.

Verificação dos Desvios de Custos Estimados

Objetivo: Verificar os projetos e produtos que se encontram com valor ganho negativo, bem como aqueles cuja estimativa atualizada de custo ultrapassa os padrões de tolerância.

Método de Determinação: Valor ganho é a diferença entre o orçamento estimado e o realizado até um determinado ponto no tempo. Geralmente esta medida deve ser tratada de forma acumulada até o ponto de medição. Projetos ou produtos com valor ganho negativo são os que o custo realizado ultrapassou o custo orçado e estimado. Para produtos, entretanto, a avaliação deve ser feita numa base anual.

Fontes de Informações: Estimativas de custos de projetos e de atendimento anual ao produto e registros de realização orçamentária respectivos.

Forma de Apresentação: gráfica e tabular.

Ação Gerencial: Identificar e analisar as causas do valor ganho negativo, negociar com clientes/usuários ou a administração a atualização dos valores dos projetos e do orçamento de atendimento ao produto.

Exemplo: Análise de Valor Ganho de Projeto

1200 Estimativa Atualizada - Custo Total

1000 Estimativa Inicial -Custo Total

Custo Realizado

Custo Orçado

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Semanas Hoje Figura 9-3

Análise de Valor Ganho de Produtos - Considerando um ano específico Produto A

Produto B

Produto C

Produto D

Produto E Legenda: Orçado Realizado

Figura 9-4

Pode-se utilizar a representação anterior para avaliar o percentual do orçamento já realizado durante o atendimento ao produto. ⌦

Medições Para a Gestão dos Recursos

Neste nível a principal medição a ser realizada é sobre a capacidade de atendimento dado um determinado nível de demanda por serviços.

Análise da Capacidade de Atendimento Objetivo: Verificar a capacidade de atendimento da instalação dado um nível de demanda por serviços, considerando novos projetos, manutenções corretivas,adaptativas e projetos de melhoria.

Método de Determinação: A determinação da capacidade, dado um intervalo de tempo estipulado , é dada pela expressão: CAT τ = CATI -( CAA + CAC ) onde: CAT τ CATI CAA CAC

➽ ➽ ➽ ➽

Capacidade de atendimento no período de tempo τ Capacidade total instalada Capacidade alocada no período Capacidade comprometida no período

A capacidade é em homens/hora, de preferência. Também deve-se estratificar a capacidade em termos de recursos de análise, programação e assim por diante e conforme o tipo de alocação, se projetos, manutenções, projetos de melhoria.

Para a determinação da capacidade de atendimento a uma demanda é imprescindível o controle da alocação dos recursos no âmbito da área de desenvolvimento.

Para cada serviço demandado, deve-se confrontar o esforço estimado para o mesmo com a CAT τ prevista para o período de tempo correspondente.

Fontes de Informações: Estimativas de esforço e prazo para cada serviço demandado e registros sobre a alocação de pessoal.

Forma de Apresentação: nenhuma específica.

Ação Gerencial: Caso a capacidade de atendimento for inferior à demanda existente para um período de tempo específico, o gerente deverá negociar com os clientes/usuários novas datas para início ou redefinir, junto à administração, as prioridades ou solicitar autorização para contratação de terceiros.

Exemplo: Supondo uma demanda de 300 horas de análise para um período de tempo específico, sendo que para este período tem-se 2000 horas alocadas a projetos, 1000 horas comprometidas e a capacidade total instalada é de 3200.

3200 - ( 2000 + 1000) = 200 Neste caso haveria necessidade por mais 100 homens/hora para atender a demanda. ⌦

Análise de Tendências

A análise de tendências procura prever o comportamento futuro dos principais atributos do processo de planejamento de projetos, desenvolvimento de software e gestão do produto. Os principais são os que se relacionam com o planejamento, a qualidade, produtividade e custos.

Os principais atributos são: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Produtividade do desenvolvimento Produtividade de manutenções adaptativas Produtividade de projetos de melhoria Exatidão das estimativas Distribuição do esforço por fase Distribuição do prazo por fase Densidade de defeitos Eficiência da remoção de defeitos Custo do ponto de função de desenvolvimento Custo do ponto de função de manutenção Custo do ponto de função de projetos de melhoria

Na realidade todas as medições podem sofrer uma análise dessa natureza.

A análise de tendência é desenvolvida através da técnica estatística de Análise de Séries Temporais.• Esta técnica permite identificar e segregar fatores relacionados com o tempo e que influenciam valores observados em uma série histórica. Estes fatores podem subsidiar a projeção dos valores da série temporal.

O método considera quatro fatores que inflenciam o comportamento dos valores em uma série temporal, quais sejam: ➪

Tendência Secular

Refere-se ao movimento de longo prazo nos valores da série temporal, considerando um grande período de tempo. ➪

Flutuações Cíclicas

São movimentos oscilatórios, para cima ou para baixo, em relação à tendência dos valores da série histórica. ➪

Variações Sazonais

São movimentos oscilatórios que ocorrem dentro de um período de tempo e que se repetem a cada novo ciclo. ➪

•

Movimentos Irregulares

Vide Kazmier 1 para exemplos de aplicação deste técnica estatística de previsão.

Variações nos valores da série temporal que não podem ser atribuídas a eventos cíclicos ou sazonais.

Para aplicação da análise da tendência nos atributos acima listados, sugerimos tratar os fatores de tendência secular e flutuações cíclicas. Estas podem ser derivadas de um conjunto de variáveis do ambiente de desenvolvimento ( habilidades do pessoal técnico, metodologia de desenvolvimento, ferramentas de apoio ao desenvolvimento, características do projeto, habilidades dos clientes/usuários) não relacionadas com aspectos sazonais.

Movimentos irregulares podem ser consequência de rupturas significantes no método de trabalho e na tecnologia empregada.

No ambiente de desenvolvimento de software, esse tipo de ruptura, ou quebra de paradigmas, invalida uma série histórica como base para análise de tendências.

Nova série histórica deve ser construída a partir desta ruptura.

Considerando que não há rupturas e que registramos os valores daqueles atributos ao longo do tempo, classificando-os por plataforma de desenvolvimento, metodologia de desenvolvimento e área de aplicação, podemos aplicar a análise de série temporais.

Análise da Tendência da Produtividade do Desenvolvimento Objetivo: Projetar, para períodos futuros, a tendência da produtividade do desenvolvimento de software para uma determinada combinação de plataforma,metodologia e área de aplicação.

Método de Determinação: No caso da produtividade devemos considerar valores médios observados dentro de um período de tempo, preferencialmente trimestral.Esses valores médios são determinados a partir da produtividade, em Pontos de Função por H/M, calculada para os projetos que tiveram seu término num trimestre qualquer e que compõem a série histórica. A produtividade média é obtida pelo somatório das produtividades individuais de cada projeto dividido pelo número de projetos.

A tendência é determinada pelas expressões: (1) Yι = a + bX onde: Yι a

➽ ➽

é o valor da produtividade esperada no período X representa a intersecção da linha de tendência com os valores da série histórica b ➽ representa a declividade da linha de tendência __ 2 _2 (2) b= ( ∑XY - nXY ) ÷ ( ∑ X - n X ) X

➽

Y

➽

onde: é o período para o qual se deseja projetar um valor da série é o valor da série histórica

_ _ (3) a = Y - bX As variações cíclicas da série histórica são determinadas pela expressão: ( 4 ) 100 x ( VSH ÷ VTE ) onde: VSH VTE

valor observado da série histórica valor da tendência para o mesmo período de VSH, pela aplicação da expressão (1) Esta expressão é conhecida como “relativos de ciclo”, o qual evidencia os picos e sulvos da componente cíclica da série temporal.

Fontes de Informações: Série histórica das produtividades médias trimestrais dos projetos de software. Esta série histórica pode estar armazenada no “banco de dados de métricas” e ser tratada por pacote estatístico.

Forma de Apresentação: gráfica.

Ação Gerencial: Caso a tendência for de diminuição da produtividade, o gerente deve identificar, analisar e remover as causas da baixa produtividade, visando reverter a tendência. A análise das variações cíclicas pode fornecer subsídios, embora tardiamente, para determinar fatores que influenciaram positivamente ou negativamente a produtividade.

Exemplo: Supondo a seguinte série histórica sobre produtividade: 2 Período Numeração do Produtividade Y XY X Período - X 1/91 2/91 3/91 4/91 1/92 2/92 3/92 4/92 1/93 2/93 3/93 4/93 1/94

➽ ➽

0 1 2 3 4 5 6 7 8 9 10 11 12

30 28 33 27 30 25 26 23 20 18 20 23 17

0 28 66 81 120 125 156 161 160 162 200 253 204

0 1 4 9 16 25 36 49 64 81 100 121 144

Tabela 9-5

Aplicando as expressões (2) e (3) , temos para a linha de tendência, expressão (1), os seguintes valores: Yι = 31,34 - 1,12 X Para projetarmos a tendência para o período 2/94 , cujo X é 13, obtemos o seguinte valor: Yι = 31,34 - 1,12 ( 13) = 16,78 A representação gráfica para os períodos 13,14 seria:

Y 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 1/91 2/91 3/91 4/91 1/92 2/92 3/92 4/92 1/93 2/93 3/93 4/93 1/94 2/94 3/94 Figura 9-5

Para elaborarmos o “diagrama de ciclo” , devemos determinar os relativos de ciclo, conforme a expressão (4). A Tabela 9-6 , a seguir, mostra os cálculos.

Tabela 9-6 X 0 1 2 3 4 5 6 7 8

Y 30 28 33 27 30 25 26 23 20

Yι 31,34 30,22 29,10 27,98 26,86 25,74 24,62 23,50 22,38

100 x (Y/ Yι) 100 x 30/31,34 100 x 28/30,22 100 x 33/29,10 100 x 27/27,98 100 x 30/26,86 100 x 25/25,74 100 x 26/24,62 100 x 23/23,50 100 x 20/22,38

Relativo de Ciclo 95,72 92,65 113,40 96,50 111,69 97,13 105,61 97,87 90,17

X 11 12 9 10

Y 23 17 18 20

Yι 19,02 17,90 21,26 20,14

100 x (Y/ Yι) 100 x 23/19,02 100 x 17/17,90 100 x 18/21,26 100 x 20/20,14

Relativo de Ciclo 120,93 94,97 84,67 99,30

A representação gráfica do ciclo é:

Relativo do Ciclo Em % 121 120 119 118 117 116 115 114 113 112 110 109 108 107 106 105 104 103 102 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 1/91 2/91 3/91 4/91 1/92 2/92 3/92 4/92 1/93 2/93 3/93 4/93 Figura 9-6

Como podemos observar pelo gráfico, os períodos 1/93 e 3/93 foram os que sofreram as maiores variações em relação à tendência da série histórica.

Demais Análises de Tendências A técnica de análise de série temporais se aplica igualmente aos demais atributos mencionados anteriormente, levando em conta os períodos trimestrais como sugerido, apesar de que a técnica pode ser empregada para qualquer período desejado. ⌦

Análise de Impacto

A análise de impacto procura avaliar as variações da qualidade, produtividade e aspectos de custos dos processos de desenvolvimento e gestão do software, em função

de mudanças operadas no ambiente, tais como introdução de nova tecnologia de desenvolvimento, tecnologia de gestão, ferramentas de apoio ao desenvolvimento, investimentos em treinamento e assim sucessivamente.

Esta análise tem por objetivo verificar se as mudanças implantadas alcançaram os resultados esperados, principalmente no que diz respeito a melhoria da qualidade, aumento da produtividade e redução de custos.

A análise pode ser representada graficamente , evidenciando o impacto ao longo do tempo.

O exemplo a seguir apresenta este tipo de representação.

Supondo que em um determinado ponto no tempo, os projetos de software passem a empregar ferramenta CASE. Nossa intenção seria verificar o impacto na produtividade de desenvolvimento. Devemos então, considerar a produtividade antes e depois da introdução desta nova tecnologia.

Produtividade 30 Antes do CASE

Depois do CASE

25 20 15 10 5 1

2

3

4

5

6

7

8 9 10 Figura 9-7

11

12

13 Período de Tempo

Poderíamos também estabelecer gráficos de controle, evidenciando as mudanças dos limites de controle superiores e inferiores. Este exemplo hipotético mostra que logo após a introdução do CASE houve uma diminuição da produtividade, isto devido ao período necessário para a aprendizagem da equipe técnica com a nova ferramenta.

Depois deste período de aprendizagem, há um aumento constante e vertiginoso da produtividade.

O mesmo tipo de análise pode ser feita para qualquer uma das medidas dos processos de desenvolvimento e de gestão do produto, óbviamente no nível tático de agregação, o qual trata basicamente com valores médios das medidas operacionais. ⌦

Análise de Atributos

A análise de atributos procura comparar os indicadores de qualidade, produtividade, custos e outros ( a critério ) entre plataformas de hardware/software,

metodologias de desenvolvimento, tecnologias de gestão, habilidades e perfis de pessoal e outras medidas subjetivas ou qualitativas.

O objetivo é obter, com base nas análises comparativas, informações que subsidiem decisões acerca da alocação de projetos de desenvolvimento conforme a combinação de plataforma,metodotologia, tecnologia e perfil de pessoal mais adequada para atingir metas estipuladas de qualidade, produtividade e custos.

Esta análise também pode ser representada graficamente, superpondo valores dos indicadores de acordo com diferentes combinações de atributos.

O exemplo a seguir demonstra esta representação gráfica para a análise de atributos, considerando também a medição de produtividade.

Esta abordagem de análise pode ser utilizada para comparar densidade de defeitos, custos do ponto de função , exatidão de estimativas de prazo, eficiência da remoção de defeitos etc.

Produtividade 30 25 20 15 10 5 1

2

3

4

5

6 7 Figura 9-8

8

9 Período de Tempo

Plataforma Mainframe,Metodologia Estruturada,baixo índice de tecnologia de gestão Plataforma Cliente-Servidor,Análise Essencial,JAD e Prototipação, alto índice de gestão

⌦

Modelagem do Ambiente de Desenvolvimento

A modelagem do ambiente de desenvolvimento já é mais complexa que a análise atributos, pois aplica modelos de regressão múltipla, a fim de determinar quais os fatores que contribuem para o ambiente de alta qualidade e produtividade.

A regressão múltipla serve para definir modelos de relações causais.

Num modelo deste tipo, a qualidade e produtividade são determinadas como variáveis dependentes, enquanto os demais fatores são variáveis independentes.

O primeiro passo é definir quais as variáveis que, com base na experiência da instalação, tem demonstrado que afetam positivamente a variável dependente. Segundo,

devemos ter informações sobre a ocorrência dos valores dessas variáveis.

Terceiro,elaborar as equações de regressão e testar, com o apoio de pacotes estatísticos, os modelos construídos.

Por exemplo, considerando que a produtividade é função de ferramentas de desenvolvimento, reutilização de código,ferramentas para teste,experiência e perfl da equipe e uso de métodos de gestão de projetos, poderíamos elaborar a seguinte equação: Produtividade = f ( Ferramentas de desenvolvimento,reutilização,ferramentas para teste,experiência da equipe,experiência do usuário,uso de métodos de gestão) Supondo que ao processarmos o modelo encontrássemos o resultado: Produtividade = f( ferramentas de desenvolvimento,reutilização e experiência da equipe) Isto significaria que quanto maior o nível de sofisticação e adequabilidade das ferramentas de desenvolvimento, quanto maior o nível da reutilização e quanto maior a experiência da equipe de projeto, maior será a produtividade.

O emprego da regressão múltipla permite que testemos o modelo passo a passo ( “step by step”), com possibilidade de isolar as influências das variáveis independentes em relação à dependente.

Na medida em que as variáveis independentes vão sendo colocadas na equação de regressão é possível verificar se o modelo está se degradando.

A medida de degradação do modelo é dado por um indicador denominado de “coeficiente de determinação ajustado”, cuja diminuição indica degradação do modelo pela inclusão de uma variável. Neste caso descarta-se a variável do modelo e assim sucessivamente até que tenhamos o modelo definitivo.

Uma vez que o modelo esteja determinado, com as variáveis que efetivamente contribuem para alta qualidade e produtividade, o gerente de desenvlvimento pode modelar o seu ambiente para que as variáveis estejam presentes em todos os projetos.• As medições sobre índice de tecnologia de desenvolvimento, índice de tecnologia de gestão e demais medições qualitativas fornecem a maioria das variáveis a serem tratadas no modelo. Geralmente variáveis deste tipo, qualitativas, são variáveis ordinais e devem ser tratadas por métodos estatísticos não-paramétricos.

REFERÊNCIAS 1. KAZMIER. L. J. Estatística Aplicada A Economia e Administração. McGraw-Hill, São Paulo , 1982.

•

Vide Kugler & Fernandes 2 para exemplo de como aplicar a regressão linear para modelagem utilizando a técnica de “path analisys”.

2. KUGLER, J.L.C. & FERNANDES,A.A. Planejamento e Controle de Sistemas de Informação. Livros Técnicos e Científicos S.A. , Rio de Janeiro, 1984.

Capítulo

10 APLICAÇÃO DAS MEDIÇÕES EM DECISÕES ECONÔMICAS RELATIVAS A SOFTWARE Uma das dimensões da gestão do software é a econômica. Como exposto no capítulo 2, o conceito da qualidade fornece esta conotação pois o esforço de atingir patamares mais evoluídos de qualidade recai também sobre a gestão dos custos de não conformidade ou má qualidade. Ou seja, qualidade aumenta lucratividade pela diminuição dos custos de falhas internas e externas e pelo aumento da satisfação dos clientes.

Na área de software a gestão econômica tem sido muito negligenciada.

Infelizmente a única preocupação, principalmente nas organizações brasileiras, tem sido o atingimento do prazo, independente dos outros fatores. Geralmente experimenta-se altos custos de falhas internas e externas ( manutenção ou atendimento de campo) fazendo com que grande parte dos recursos fique alocado às atividades de manutenção, limitando a capacidade da empresa em desenvolver novas soluções, tornando-a assim menos competitiva.

Entretanto, na medida em que a organização começa a aplicar medições e reter as informações sobre os seus resultados, são estabelecidas as condições necessárias para que decisões econômicas relativas ao software sejam tomadas.

Neste capítulo procuraremos mostrar algumas aplicações de decisão econômica que podem ser feitas com base nos resultados das medições.

Concentraremos nossa discussão nos seguintes tópicos: ➲ ➲ ➲ ➲ ➲ ➲ ➲

Decisão de Comprar/Desenvolver Internamente Planejamento de Custos de Manutenção Anual de Software Viabilidade de Utilização de Inspeções de Projeto• Viabilidade de Utilização de Análise Essencial Viabilidade de Utilização de Projeto Estruturado Viabilidade de Utilização de Análise de Complexidade Viabilidade de Utilização de Inspeção de Código

10.1 - Decisão de Comprar/Desenvolver Internamente Algumas vezes nos deparamos com este tipo de decisão, entre comprar um pacote pronto ou desenvolver internamente o software.

•

Vide GRADY 1 para aplicações e justificativas dessas análises econômicas.

Obviamente que neste caso devemos levar em consideração o “custo oportunidade “ que é o custo que a empresa terá caso perder uma oportunidade para realizar um negócio lucrativo.

A base para a análise compreende: ➩ Tamanho em Pontos de Função do Software (Pacote) ➩ Custo do Ponto de Função de Desenvolvimento conforme a plataforma de hardware/software ➩ Custo oportunidade Suposições: Tamanho em Pontos de Função do Pacote Custo do Pacote Custo do Ponto de Função de desenvolvimento Custo Oportunidade

= 1000 = $ 100.000 = $ 200 = $ 100.000

Aplicação das Suposições: ➨

Custo de desenvolver internamente o software Custo do ponto de função de desenvolvimento x tamanho em pontos de função do pacote + custo oportunidade $ 200 x 1000 + $ 100.000 = $ 300.000

➨

Ganhos com a compra do pacote Custo de desenvolver internamente - custo do pacote $ 300.000 - $ 100.000 = $ 200.000

Neste exemplo optaríamos por comprar o pacote ao invés de desenvolvê-lo internamente.

10.2 - Planejamento de Custos de Manutenção Anual de Software A base para a análise compreende: ➩ ➩

Custo do Ponto de Função de Manutenção/Melhoria conforme cada plataforma de hardware/software Média Anual de Pontos de Função mantidos/acrescidos para cada software

Suposições: Tabela de custos do ponto de função de manutenção/melhoria conforme plataforma:

Plataforma 1

Plataforma 2

$ 80.00

$ 90.00

Plataforma 3

$ 85.00

Supondo a distribuição quantitativa de software por plataforma: Tabela 10-1

Plataforma 1 Software

A B C

Média Anual

200 100 100

Plataforma 2 Software

Média Anual

D E F

150 200 250

Plataforma 3 Software

G H I

Média Anual

100 150 300

Aplicação das Suposições: Tabela 10-2

Plataforma 1 Software Resultado 200x$80 = $16.000 A 100x$80 = $ 8.000

B C Total

100x$80 = $ 8.000

Plataforma 2 Software Resultado 150x$90 = $13.500 D

E F

200x$90 = $18.000 250x$90 = $22.500

$ 32.000

Plataforma 3 Software Resultado 100x$85 = $8500 G

H I

$ 54.000

150x$85 = $12.750 300x$85 = $25.500

$ 46.750

Neste exemplo, o nosso orçamento anual para a manutenção/melhoria do conjunto de software da instalação seria de $ 132.750.

10.3 - Análise de Viabilidade da Utilização de Inspeções de Projeto A base para a análise compreende: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Tamanho do projeto em milhares de instruções fontes ( KNCSI- Thousands of Non-Commentary Source Instructions) Média de defeitos por KNCSI Média de defeitos gerados no projeto Número ótimo de inspetores durante uma inspeção Razão do tempo de preparação em relação ao tempo de inspeção Número de defeitos encontrados por hora de inspeção Percentagem média de defeitos encontrados nas inspeções de projeto Razão do custo para encontrar e remover defeitos durante o teste em relação ao custo para encontrar e remover defeitos na fase de projeto Número de profissionais em tempo integral dedicados ao projeto Custo médio do homem/hora

Suposições: ➩ ➩

Tamanho do projeto em KNCSI 80 KNCSI Média de defeitos por KNCSI 7 defeitos por KNCSI

➩ ➩ ➩ ➩ ➩ ➩

➩ ➩

Média de defeitos gerados no projeto 35% do total dos defeitos introduzidos no software Número ótimo de inspetores durante uma inspeção De 4 a 5 inspetores Razão do tempo de preparação em relação ao tempo de inspeção Em torno de 1.75 Número de defeitos encontrados por hora de inspeção 2.5 defeitos por hora de inspeção Percentagem média de defeitos encontrados nas inspeções de projeto 55% do total dos defeitos de projeto Razão do custo para encontrar e remover defeitos durante o teste em relação ao custo para encontrar e remover defeitos na fase de projeto 6.25 vezes mais Número de profissionais em tempo integral dedicados ao projeto 8 profissionais Custo médio do homem/hora $ 16.00

Aplicação das Suposições Defeitos esperados para o projeto como um todo (80.000 ÷ 1000) x 7 = 560 Defeitos esperados para a fase de projeto 560 x .35 = 196 defeitos Esforço para encontrar os defeitos na inspeção do projeto a. b. c. d.

( 196 defeitos x .55) ÷ 2.5 defeitos/hora = 43.12 ou 43 43 horas x 5 inspetores = 215 homens/hora para inspeção 215 x 1.75 = 376.25 ou 376 homens/hora de preparação 215 + 376 = 591 homens/hora de esforço de inspeção

Esforço para encontrar o mesmo número de defeitos durante o teste 591 homens/hora x 6.25 = 3693.75 ou 3694 homens/hora Resultados Ganho em esforço 3694 - 591 = 3103 Ganho no prazo do projeto 3103 ÷ ( 8 profissionais x 160 horas ) = 2.4 meses

Ganho financeiro 3103 x $ 16.00 = $ 49.648.00 10.4 - Análise de Viabilidade da Utilização de Análise Essencial A base para a análise compreende: ➩

➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Os diagramas e dicionário de dados produzidos proporcionam informações úteis aos analistas no sentido de verificar problemas que são encontrados na fase de teste Tamanho do projeto em milhares de instruções fontes Esforço total do projeto Média de defeitos pré-release por KNCSI Tempo necessário para encontrar e remover defeitos introduzidos na análise essencial durante o teste Percentual médio de tempo despendido na fase de análise de requisitos Percentual médio de tempo despendido na fase de teste Percentual médio de defeitos, em relação ao total de defeitos, com possibilidade de serem introduzidos pela análise Percentual de defeitos introduzidos pela especificação, sem a utilização de ferramentas de apoio à análise Percentual de defeitos introduzidos pelo projeto, sem a utilização de ferramentas de apoio à análise Percentual de eliminação de defeitos com a utilização de ferramentas Redução do tempo para teste em função dos diagramas de análise Aumento do tempo de análise de requisitos em função da utilização de diagramas de análise Número de profissionais alocados em tempo integral ao projeto Custo médio do homem/hora

Suposições: ➩ ➩ ➩ ➩

➩

➩

Tamanho do projeto em KNCSI 100 Esforço total do projeto 45714 homens/hora Média de defeitos pré-release por KNCSI 7 defeitos Tempo necessário para encontrar e remover defeitos introduzidos na análise essencial durante o teste 15 horas por defeito Percentual médio de tempo despendido na fase de análise de requisitos 18% Percentual médio de tempo despendido na fase de teste 29%

➩

➩

➩

➩ ➩ ➩

➩ ➩

Percentual médio de defeitos, em relação ao total de defeitos, com possibilidade de serem introduzidos pela análise 20% Percentual de defeitos introduzidos pela especificação, sem a utilização de ferramentas de apoio à análise 10% Percentual de defeitos introduzidos pela projeto, sem a utilização de ferramentas de apoio à análise 10% Percentual de eliminação de defeitos com a utilização de ferramentas 75% Redução do tempo para teste em função dos diagramas de análise 5% Aumento do tempo de análise de requisitos em função da utilização de diagramas de análise 10% Número de profissionais alocados em tempo integral ao projeto 10 Custo médio do homem/hora $ 16.00

Aplicação das Suposições: Determinação do número total de defeitos esperados (100.000 ÷ 1000) x 7 = 700 Defeitos esperados com possibilidade de serem introduzidos pela análise 700 x .20 = 140 defeitos introduzidos pela análise de requisitos: 700 x .10 = 70 defeitos introduzidos pelo projeto : 700 x .10 = 70 Acréscimo de esforço na fase de análise de requisitos 45714 homens/hora x .18% = 8228. 52 ou 8229 8229 x .10% = 822.9 ou 823 homens/hora Esforço para encontrar e remover 75% dos defeitos durante o teste .75 x 140 = 105 defeitos 105 defeitos x 15 horas = 1575 homens/hora

Resultados: Ganho no esforço de teste 1575 homens/hora - 823 homens/hora = 752 homens/hora

Decréscimo do esforço de teste 45714 homens/hora x .29 = 13257.06 ou 13257 13257 x .05 = 662.85 ou 663 Ganho total de esforço 752 + 663 = 1415 Ganho financeiro 1415 x $ 16.00 = $ 22.640,00 Ganho no prazo do projeto 1415 ÷ ( 10 x 160 ) = .88 meses 10.5- Análise de Viabilidade da Utilização de Projeto Estruturado A base para a análise compreende: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Tamanho do projeto em KNCSI Esforço total do projeto Média de defeitos pré-release por KNCSI Tempo para encontrar e remover defeitos introduzidos pelo projeto durante a fase de teste Tempo médio despendido na fase de projeto estruturado, em relação ao total Tempo médio despendido na fase de teste, em relação ao total Percentual dos defeitos introduzidos pelo projeto estruturado em relação ao total Percentual de eliminação de defeitos com utilização de ferramentas de apoio à elaboração do projeto Acréscimo de tempo no projeto em função do emprego de ferramentas Decréscimo de tempo na fase de teste em função do emprego de diagramas Número de profissionais em tempo integral alocado ao projeto Custo médio do homem/hora

Suposições: ➩ ➩ ➩ ➩

➩

➩ ➩

➩

➩ ➩

➩ ➩

Tamanho do projeto em KNCSI 80 Esforço total do projeto 36572 Média de defeitos pré-release por KNCSI 7 Tempo para encontrar e remover defeitos introduzidos pelo projeto durante a fase de teste 12 horas por defeito Tempo médio despendido na fase de projeto estruturado, em relação ao total 19% do total Tempo médio despendido na fase de teste, em relação ao total 29% do tempo total Percentual dos defeitos introduzidos pelo projeto estruturado em relação ao total 25% do total Percentual de eliminação de defeitos com utilização de ferramentas de apoio à elaboração do projeto 75% dos defeitos Acréscimo de tempo no projeto em função do emprego de ferramentas 5% de acréscimo Decréscimo de tempo na fase de teste em função do emprego de diagramas 5% de decréscimo Número de profissionais em tempo integral alocado ao projeto 9 Custo médio do homem/hora $ 16.00

Aplicação das Suposições: Total de defeitos esperados pelo projeto ( 80.000 ÷ 1000 ) x 7 = 560 Defeitos esperados a serem introduzidos pelo projeto estruturado 560 defeitos x .25 x .75 = 105 Acréscimo de esforço no projeto estruturado 36572 x .19 x .05 = 347.43 ou 348 Tempo para encontrar e remover os mesmos 105 defeitos no teste 105 x 12 horas = 1260 homens/horas

Decréscimo do esforço na fase de teste 36572 x .29 x .05 = 530.29 ou 530 homens/horas Resultados: Ganho em esforço para remover defeitos 1260 homens/horas - 348 homens/hora = 912 homens/horas Ganho no esforço total 912 homens/horas + 530 homens/horas = 1442 homens/hora Ganho financeiro 1442 x $ 16 = $ 23.072,00 Ganho no prazo do projeto 1442 ÷ ( 9 x 160 ) = 1 mês 10.6 - Análise da Viabilidade da Utilização da Análise de Complexidade A base da análise compreende: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Tamanho do projeto em KNCSI Esforço total do projeto Média de defeitos pré-release por KNCSI Percentual médio de defeitos da fase de projeto Percentual médio de defeitos da fase de codificação Razão de custo para encontrar e remover defeitos introduzidos na fase de codificação, durante o teste Tempo médio para encontrar e remover defeitos Percentual de defeitos com possibilidade de serem encontrados e removidos com utilização de ferramentas na fase de projeto Percentual de defeitos com possibilidade de serem encontrados e removidos com utilização de ferramentas na fase de codificação Número de profissionais alocados em tempo integral ao projeto Custo médio do homem/hora

Suposições: ➩ ➩

Tamanho do projeto em KNCSI 50 Esforço total do projeto 22857

➩ ➩ ➩ ➩

➩ ➩

➩

➩ ➩

Média de defeitos pré-release por KNCSI 7 Percentual médio de defeitos da fase de projeto 35% do total Percentual médio de defeitos da fase de codificação 45% do total Razão de custo para encontrar e remover defeitos introduzidos na fase de codificação, durante o teste 2.5 Tempo médio para encontrar e remover defeitos no teste 10 horas por defeito Percentual de defeitos com possibilidade de serem encontrados e removidos com utilização de ferramentas na fase de projeto 25% dos defeitos Percentual de defeitos com possibilidade de serem encontrados e removidos com utilização de ferramentas na fase de codificação 25% dos defeitos Número de profissionais em tempo integral 6 Custo médio do homem/hora $ 16.00

Aplicação das Suposições: Defeitos de projeto e de código que se supõe encontrar com as ferramentas 350 defeitos x .35 x .25 = 31 defeitos de projeto 350 defeitos x .45 x .25 = 39 defeitos de codificação Para encontrar e remover 70 defeitos adicionais durante a codificação (70 x 10 horas ) ÷ 2.5 = 280 homens/hora Esforço para encontrar e remover defeitos durante o teste 280 x 2.5 = 700 Resultados: Ganho de esforço 700 - 280 = 420 homens/horas Ganho financeiro 420 x $ 16.00 = $ 6720

Ganho no prazo do projeto 420 ÷ ( 6 x 160 ) = .4 meses 10.7 - Análise de Viabilidade da Utilização da Inspeção de Código A base para a análise compreende: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Tamanho do projeto em KNCSI Esforço total do projeto Média de defeitos pré-release por KNCSI Razão para encontrar defeitos no teste em relação à codificação Número ótimo de inspetores numa inspeção Razão de tempo de preparação pelo tempo de inspeção Percentual médio de defeitos encontrados pela inspeção de código Número ótimo de linhas inspecionadas por hora Número de linhas de comentários em relação às de instruções fontes Número de profissionais alocados em tempo integral Custo médio do homem/hora

Suposições: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Tamanho do projeto em KNCSI 50 Esforço total do projeto 22857 Média de defeitos pré-release por KNCSI 7 Razão para encontrar defeitos no teste em relação à codificação 2.5 Número ótimo de inspetores numa inspeção 4a5 Razão de tempo de preparação pelo tempo de inspeção 1.75 Percentual médio de defeitos encontrados pela inspeção de código 60% Número ótimo de linhas inspecionadas por hora 250 Número de linhas de comentários em relação às de instruções fontes 2 linhas de comentários para cada 10 de instruções fontes Número de profissionais alocados em tempo integral 6 Custo médio do homem/hora $ 16.00

Aplicação das Suposições: Defeitos esperados para o projeto como um todo 350 Tempo estimado para inspecionar todo o código 50.000 x 1.2 (linhas de comentários) = 60.000 60.000 ÷ 250 linhas/hora = 240 horas 240 horas x 5 inspetores = 1200 homens/hora para inspeção 1200 x 1.75 = 2100 homens/hora para preparação 1200 + 2100 = 3300 homens/hora para toda a inspeção Esforço para encontrar os mesmos defeitos no teste 60% dos defeitos de 350 = 210 defeitos ( 3300 x .6 ) x 2.5 (razão de custo) = 4950 Resultados: Ganho de esforço 4950 - 3300 = 1650 homens/horas Ganho financeiro 1650 x $ 16.00 = $ 26.400,00 Ganho de prazo no projeto 1650 ÷ ( 6 x 160 ) = 1.7 meses REFERÊNCIAS 1. GRADY,R.B. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall, Englewood Cliffs, New Jersey,1992.

Capítulo

11 APLICAÇÃO ESTRATÉGICA DAS MEDIÇÕES - MELHORIA CONTÍNUA DO PROCESSO A aplicação estratégica das medições reside em três pontos fundamentais, quais sejam: ➪ ➪ ➪

Benchmarking Melhoria Contínua Avaliação Econômica e de Resultados

Benchmarking , de acordo com Kearns 5 , é o processo contínuo de medir os produtos, serviços e práticas da empresa em relação aos principais competidores ou em relação àquelas companhias reconhecidas como líderes na indústria.

O Benchmarking tem uma ligação bastante estreita com o processo de melhoria contínua, visto que a realização de um esfoço para atingir o nível de excelência de um competidor ou de outras empresas não-competidoras, no que diz respeito a determinadas áreas de negócio ou a práticas, enquadra-se na filosofia do Kaizen.

Felizmente, para a área de informática, existem dois modelos de certificação de qualidade em software que servem de base para realizar Benchmarking. São eles o modelo SEI - Capability Maturity Model do Software Engineering Institute da CarnegieMellon University e o modelo ISO 9000-3. Ambos são considerados como modelos de Sistemas da Qualidade.

A melhoria contínua baseia-se na filosofia do Kaizen e tem como elementos fundamentais para a gestão de processos, a aplicação das ferramentas da qualidade, isto é, folha de verificação, gráfico de pareto, diagrama de causa e efeito ( “Ishikawa diagram”), carta de tendência, histograma,gráfico de dispersão e o gráfico de controle estatístico. Outro instrumento importante é a utilização do Ciclo de Deming ou PDCA Plan-Do-Check-Action, o qual é o cerne da melhoria contínua.

A avaliação econômica tenta valorar o acervo do software na empresa como um todo e por suas áreas, conforme o uso dos recursos pelas diversas divisões e departamentos. A avaliação dos resultados tenta medir o retorno para a empresa do acervo de software em termos de lucratividade, “market share” etc.

Este capítulo divide-se portanto, nestes três temas, procurando demonstrar o que denominamos de medições estratégicas.

11.1 - O Processo de Benchmarking O processo de Benchmarking procura comparar aspectos quantitativos e qualitativos do ambiente de software da empresa.

A comparação quantitativa reside nos atributos de qualidade,produtividade e custos de projetos de software e de gestão do produto.

Esta análise é importante na medida estratégicamente da tecnologia da informação.

em

que

a

empresa

depende

Em alguns tipos de negócios, onde a competição é extremamente acirrada, a empresa necessita ter uma competência estabelecida para sobreviver e crescer no seu negócio.

Um exemplo são as instituições financeiras, cujo nível de automação, que na realidade é basicamente software, é um requisito mandatório para operar no mercado.

Nesse tipo de negócio, inclusive, o produto é o próprio software. Um produto de aplicação financeira ou de aplicação comercial bancária ( os empréstimos), são puramente software. Cria diferencial quem tiver produtos de melhor qualidade, com maior gama de opções, que reduza o tempo de acesso e uso do produto pelo cliente e quem tem maior controle sobre as operações ( automação do “back office”) e quem conhecer melhor o seu cliente ( “database marketing”) e quem for extremamente responsivo às necessidades dos clientes e do mercado.

Isto, óbviamente, requer produção de software de alta qualidade e com grande produtividade e a um custo econômico da qualidade, considerando todo o ciclo de vida do produto.

A comparação qualitativa já procura confrontar as práticas relativas à produção do software, levando em conta não somente tecnologia e métodos de desenvolvimento como também a infra-estrutura de gerenciamento.

O processo de Benchmarking, de acordo com Camp 2 consiste em 5 etapas,conforme mostra a Figura 11-1. ⌦

Benchmarking Quantitativo

Consiste em comparar a qualidade do processo de desenvolvimento em termos de densidade de defeitos, a qualidade dos produtos também em termos de densidade de defeitos, a produtividade do desenvolvimento em termos de Pontos de Função por H/M e os custos do ponto de função de desenvolvimento e de manutenção adaptativa e projetos de melhoria.

Esta análise também pode ser demonstrada de forma gráfica.

A seguir é fornecido um exemplo gráfico do benchmarking. Não devemos esquecer que a comparação é mais útil quando estivermos tratando com o mesmo tipo de plataforma, metodologia etc.

1. Identificar o objetivo do benchmarking

PLANEJAMENTO

2. Identificar empresas/modelos para comparar 3. Determinar método de coleta de dados 4. Determinar o “gap”de desempenho

ANÁLISE 5. Projetar futuros níveis de desempenho 6. Comunicar resultados e ganhar aceitação

INTEGRAÇÃO

7. Estabelecer metas funcionais 8. Desenvolver planos de ação

AÇÃO

9. Implementar ações e monitorar o progresso 10. Recalibrar o benchmarking

MATURIDADE

.Comprometimento da administração .Práticas incorporadas nos processos Figura 11-1

Produtividade Média 50 45 40

Empresa A Nossa empresa

35 30

Empresa B

25

Empresa C

20 Figura 11-2

Neste exemplo há duas empresas que têm maior produtividade que a ”nossa”.

O benchamarking competitivo é importante para fornecer os primeiros “insihgts”. O importante é descobrir quais as práticas que levam as empresas B e C a terem maior produtividade do que a nossa. O objetivo seria então atingirmos o mesmo desempenho da empresa C, considerada a de mais alto desempenho.

O mesmo tipo de comparação pode ser realizada para os outros indicadores de qualidade e custos. ⌦

Benchmarking Qualitativo

O Benchmarking qualitativo pode ser desenvolvido através de uma pesquisa cujas questões evidenciem o “estado-da-arte” da tecnologia de desenvolvimento e de gestão empregadas pelas empresas competidoras ou não.

Os instrumentos para a determinação do Índice de Tecnologia de Desenvolvimento, o Índice de Tecnologia de Gestão e as demais medições qualitativas apresentados no capítulo 7 fornecem muitos subsídios para este tipo de pesquisa.

A outra alternativa é compararmos as práticas da empresa com os modelos de certificação da qualidade em software Devido a importância de ambos modelos, decidimos por abrir tópicos específicos para ambos.

11.2 - O Modelo SEI de Certificação da Qualidade em Software O modelo SEI foi desenvolvido pela Carnegie-Mellon University ,a pedido do DoD Departamento de Defesa, em especial a Força Aérea Norte-Americana, visando criar uma forma de certificar empresas de desenvolvimento de software.

O modelo procura determinar, com base nos fatores de organização, gerência de projetos, gerência de processos e tecnologia, níveis de maturidade de uma empresa em relação ao software. O modelo SEI também é conhecido como “Software Process Maturity” ou “Capability Maturity Model - CMM”.• O modelo é composto de cinco níveis de maturidade do processo, ou: ➪

Inicial

Neste estágio , também chamado de “ad hoc” ou caótico, a organização não opera com procedimentos formalizados em termos de desenvolvimento, estimativas de custo e planos dos projetos.O controle de mudança não é homogêneo, não há comprometimento da gerência em relação a planos e procedimentos, sendo que a instalação e manutenção de software frequentemente apresenta problemas sérios.

Os profissionais são dirigidos de crise em crise , por prioridades não planejadas e mudanças não gerenciadas. É comum aos gerentes realizarem solicitações difíceis de serem atingidas pela equipe técnica, enquanto cortam recursos. O prazo é a única prioridade e os talentos não conseguem ser retidos.

As ações necessárias para migrar deste nível ou estágio para o seguinte concentram-se em: planejamento (estimativas), monitoramento do projeto, controle de mudança, comprometimento gerencial e garantia da qualidade. ➪

•

Repetido

Vide Humphrey 4 cuja obra disseca o modelo SEI.

A principal diferença entre este nível e o inicial é que já há controle sobre a forma como a organização estabelece seus planos e comprometimentos.

As ações iniciadas no estágio anterior já começam a surtir efeito em termos de planejamento de projetos documentado, incluindo estimativas, controle de projetos, controle de subcontratados, roteiro de desenvolvimento, documentação do projeto, estrutura de garantia da qualidade, procedimentos documentados e mecanismos de controle de mudanças e gerência de configuração ( controle de versões do software).

As ações chaves para a evolução deste estágio para o seguinte são: estabelecimento do grupo de engenharia de processo, da arquitetura de desenvolvimento de software e a introdução de métodos e tecnologias de engenharia de software. ➪

Definido

Neste nível a organização já estabeleceu um processo padrão o qual pode ser adaptado para necessidades específicas de cada projeto.

O Grupo de Engenharia de Processo é estabelecido para implementar e evoluir o processo de desenvolvimento, inclusive com o treinamento das equipes técnicas, revisões gerenciais períódicas são realizadas para avaliar a efetividade dos novos procedimentos, estabelecem-se métodos de teste, medições são realizadas quanto a erros no processo, as ferramentas de desenvolvimento estão definidas e o processo de inspeção formal é instituído.

As ações necessárias para a evolução deste estágio para o seguinte são: estabelecimento de medições relativas a parâmetros de qualidade e custo do processo, estabelecimento de um banco de dados sobre o processo para análises de qualidade e produtividade e avaliações sobre a qualidade de cada produto. ➪

Gerenciado

Aqui as ações desencadeadas no nível anterior são implementadas em sua totalidade, incluindo benchmarking de produtos; para cada projeto é realizado um planejamento da qualidade; há planos de introdução de novas tecnologias; treinamentos sobre planejamento da qualidade, gerência quantitativa do processo, métodos avançados de desenvolvimento e prototipação são estabelecidos; planos de melhoria do processo são estabelecidos; o desempenho é monitorado conforme os planos da qualidade e melhorias, as mudanças nos projetos estão sob controle da gerência de configuração, o nível das medições é mais detalhado e etc.

As ações requeridas para a evolução deste estágio para o seguinte são: apoio informatizado à coleta de dados sobre o processo e a utilização dos dados para a análise e modificação do processo visando a prevenção de problemas e melhoria contínua. ➪

Otimizado

Este é o estágio da melhoria contínua do processo, da reutilização de componentes , da utilização intensiva de métodos de prevenção de erros, do controle estatístico do processo e da modelagem do ambiente de desenvolvimento.

A Figura 11-3 resume os estágios e suas principais características.

Prevenção de Defeitos Automação do Processo de Software

OTIMIZADO

Medição de Software Gerência da Qualidade do Software

Processo Padronizado Inspeção de Software Metodologia de Teste Grupo de Engenharia de Software

Planejamento de Projetos Controle de Projetos Gerência de Configuração Quality Assurance

GERENCIADO

DEFINIDO

REPETIDO

INICIAL

Figura 11-3

Este modelo além de permitir a organização realizar uma auto-avaliação• , também possibilita o planejamento da melhoria do desenvolvimento de software.

De acordo com Humphrey 4 a passagem de um estágio para outro, sendo feito de forma planejada , leva em torno de 2 anos.

Recentes estatísticas norte-americanas 6 , obtidas através de pesquisa realizada pelo Software Engineering Institute , revelou que 74% das empresas de software se encontram no nível 1, 19% no nível 2 e 7% no nível 3.

Os passos propostos para o planejamento da melhoria do processo de software, de acordo com o modelo consistem em: 1. Entender a situação atual do processo de desenvolvimento 2. Desenvolver uma visão do processo desejado

•

Veja o capítulo 15, o qual traz um instrumento de auto-avaliação quanto ao estágio de maturidade de software.

3. Estabelecer uma lista das ações necessárias para o aperfeiçoamento do processo 4. Produzir um plano para realizar as ações planejadas e requeridas 5. Comprometer recursos para executar o plano 11.3 - O Modelo ISO de Certificação da Qualidade em Software O modelo ISO para software é uma derivação da 9001 e é conhecida como ISO 9000-3 3 apesar que, para fins de certificação, considera-se como 9001.

O objetivo da norma é proporcionar um guia de orientação onde um contrato entre duas partes requer a demonstração da capacidade do fornecedor para desenvolver, suprir e manter produtos de software.

A norma é estruturada em três partes, quais sejam: ➪ ➪ ➪

Sistema da Qualidade - Ferramental Sistema da Qualidade - Atividades do Ciclo de Vida Sistema da Qualidade - Atividades de Suporte

Cada parte é dividida em elementos. A norma possui 22 elementos, ou: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Responsabilidade da Gerência Sistema da Qualidade Auditorias Internas da Qualidade Ação Corretiva Revisão do Contrato Especificação dos Requisitos do Comprador Planejamento do Desenvolvimento Planejamento da Qualidade Projeto e Implementação Teste e Validação Aceitação Replicação, Entrega e Instalação Manutenção Gerência de Configuração Controle de Documentos Registros da Qualidade Medições Regras,Práticas e Convenções Ferramentas e Técnicas Compras Software Produto Incluso Treinamento

A seguir é apresentado um resumo dos principais elementos da norma.

4.1 - Responsabilidade da Gerência

Inclue: ➪ ➪ ➪ ➪ ➪

➪ ➪ ➪

O fornecedor deve definir e documentar uma política da qualidade A política deve ser entendida por todos na organização As responsabilidades e autoridades quanto às atividades relativas à qualidade, na organização, devem estar claramente definidas Os recursos e pessoal para verificação do sistema da qualidade devem estar definidos O fornecedor deve indicar um representante da administração, com responsabilidade e autoridade para assegurar que o sistema da qualidade esteja em operação conforme os requisitos da norma O sistema da qualidade deve ser revisto a intervalos regulares, com os registros pertinentes documentados O comprador ( cliente) deve definir exatamente suas necessidades e especificações O fornecedor e o comprador devem realizar revisões conjuntas para verificar aderência do software às especificações e resultados de teste

4.2 - Sistema da Qualidade Inclue: ➪ ➪

Todos os elementos do sistema da qualidade devem estar documentados O fornecedor deve preparar e documentar um plano da qualidade a fim de implementar atividades da qualidade para cada projeto de software

4.3 - Auditorias Internas do Sistema da Qualidade Inclue: ➪ ➪

O fornecedor deve realizar auditorias internas periódicas para verificar a conformidade do sistema da qualidade As auditorias devem ser planejadas, documentadas e as recomendações acompanhadas

4.4 - Ação Corretiva Inclue: ➪

O fornecedor deve estabelecer, documentar e manter procedimentos para investigar causas de não-conformidade do produto, analisar processos, iniciar ações preventivas, aplicar controles para que as ações corretivas sejam realizadas e implementar e registrar mudanças nos procedimentos em função dos resultados da ação corretiva

5.2 - Revisão do Contrato Inclue: ➪ ➪

O fornecedor deve estabelecer e manter procedimentos para a revisão do contrato e para a coordenação dessas atividades O fornecedor deve revisar cada contrato para assegurar que o escopo e requisitos sejam definidos e documentados, que as contingências sejam identificadas, que informação proprietária seja adequadamente protegida,

➪ ➪

➪

que quaisquer requisitos diferentes daqueles na proposta sejam solucionados, que a responsabilidade do fornecedor com sub-contratados esteja definida O fornecedor deve manter registros dessas revisões O contrato deve prever critérios de aceitação do software, tratamento de mudanças dos requisitos do comprador durante o desenvolvimento, o tratamento de problemas detectados após a aceitação, as atividades a serem desempenhadas pelo comprador no que concerne a especificação dos requisitos, a definição das facilidades, ferramentas e itens de software a serem fornecidos pelo comprador, procedimentos e padrões a serem usados e requisitos de replicação do software Devem ser designadas pessoas, de ambas as partes, para o estabelecimento das especificações dos requisitos do comprador

5.4 - Planejamento do Desenvolvimento Incle: ➪

➪ ➪ ➪ ➪ ➪

O plano de desenvolvimento deve conter a definição do projeto em termos de objetivos e relacionamento com outros projetos do comprador ou do fornecedor, a organização dos recursos para o projeto, incluindo estrutura da equipe, responsabilidades, uso de sub-contratados e recursos materiais, as fases de desenvolvimento, o cronograma do projeto e a identificação de planos correlatos tais como plano da qualidade, plano de gerência de configuração, plano de integração e plano de teste O plano de desenvolvimento deve ser atualizado na medida do progresso do projeto Para cada fase do desenvolvimento devem ser estabelecidas as entradas e saídas O plano deve prever também como o projeto será gerenciado O plano deve identificar as regras, práticas, convenções, ferramentas,técnicas e a gerência de configuração O fornecedor deve verificar as saídas de todas as fases do desenvolvimento

5.5 - Planejamento da Qualidade Inclue: ➪

O plano da qualidade deve prever os objetivos da qualidade, expresso em termos mensuráveis sempre quando possível, os critérios de entrada e saída para cada fase de desenvolvimento, identifidação dos tipos de teste, planejamento detalhado do teste e responsabilidades quanto a revisões e testes, gerência de configuração e controle de mudança e controle de defeitos e ação corretiva

5.6 - Projeto e Implementação Inclue: ➪

Os seguintes aspectos inerentes às atividades de projeto devem ser consideradas: regras de projeto, definições de interfaces internas, metodologia de projeto, utilização de experiências de projeto passadas

➪

➪

➪

No que tange à implementação devem ser levadas em consideração regras para programação, convenções consistentes de nomes, métodos de implementação O fornecedor deve desempenhar revisões e assegurar que os requisitos sejam atendidos e que os métodos de projeto e implementação sejam adequadamente utilizados O fornecedor deve manter registros documentados de tais revisões

5.7 - Teste e Validação Inclue: ➪ ➪

➪

➪

➪

O fornecedor deve estabelecer e revisar os planos de testes O plano de teste deve considerar, planos para itens de software, integração, teste do sistema e teste de aceitação, casos de teste, dados de teste e resultados esperados, ambiente de teste, ferramentas e software de teste, o critério pelo qual o término do teste será julgado, a documentação do usuário e os requisitos de pessoal e o treinamento correspondente Durante o teste os seguintes aspectos devem ser levados em consideração: os resultados do teste devem ser registrados , quaisquer problemas e seus impactos possíveis em outras partes do software devem ser anotados e os responsáveis notificados, de forma que sejam solucionados, áreas do software impactadas por qualquer modificação devem ser identificadas e testadas novamente, a adequabilidade do teste deve ser avaliada e o ambiente de hardware e software do teste deve ser documentado Antes de entregar o produto para a aceitação pelo comprador, o fornecedor deve validá-lo e sempre quando possível, dentro de condições similares ao ambiente especificado no contrato Quando o teste sob condições de campo é requerido, os seguintes aspectos devem ser levados em consideração: as características a serem testadas no campo, as responsabilidades específicas do fornecedor e do comprador no desenvolvimento e avaliação do teste e a restauração do ambiente do usuário

5.8 - Aceitação Inclue: ➪

Antes de desempenhar as atividades de aceitação, o fornecedor deve assistir o comprador na identificação da programação da aceitação, procedimentos para avaliação, o ambiente de hardware/software e recursos necessários e os critérios de aceitação a serem utilizados

5.9 - Replicação,Entrega e Instalação Inclue: ➪ ➪ ➪ ➪

A determinação do número de cópias do software a serem entregues O tipo de meio magnético a ser utilizado, incluindo formatos A estipulação da documentação requerida Questões relativas a direitos autorais

➪ ➪ ➪ ➪ ➪

Custódia da cópia master e cópias de “back-up”, incluindo planos de contingência O período de obrigação do fornecedor suprir cópias As cópias a serem entregues deverão ser verificadas quanto a sua completeza Os papéis do fornecedor e comprador deverão estar plenamente estabelecidos quanto à instalação Deve-se levar em consideração responsabilidades relativas a: cronograma, acesso às instalações do comprador, disponibilidade de pessoal habilitado, disponibilidade e acesso a sistemas e equipamentos do comprador, a necessidade para validar cada instalação e um procedimento formal para a aprovação de cada instalação após o seu término

5.10 - Manutenção Inclue: ➪ ➪ ➪

➪

Os itens de software a serem mantidos devem estar estipulados em contrato Deve ser elaborado um plano de manutenção acordado entre o fornecedor e o comprador O plano de manutenção deve considerar: escopo da manutenção, identificação do status inicial do produto, a organização de suporte, as atividades de manutenção, os registros e relatórios de manutenção O fornecedor e o comprador devem estar de acordo quanto à incorporação de mudanças em um software em função da necessidade de manter o desempenho

6.1 - Gerência de Configuração Inclue: ➪

➪

➪ ➪ ➪

➪

O fornecedor deve desenvolver um plano de gerência de configuração que compreende: organizações e responsabilidades correspondentes relativas à gerência de configuração, atividades a serem desempenhadas, ferramentas,técnicas e metodologias a serem usadas e o estágio no qual os itens de software devem entrar sob o controle da gerência de configuração Procedimentos devem ser aplicados a fim de assegurar para cada versão do software: as especificações funcionais e técnicas, todas as ferramentas de desenvolvimento que afetam estas especificações, todas as interfaces com outros itens de software e hardware e todos os documentos e arquivos de computador relacionados ao item de software A identificação do item de software deve propiciar o relacionamento com os requisitos estabelecidos em contrato Para produtos entregues, deve ser demonstrada a capacidade de rastreabilidade O fornecedor deve estabelecer e manter procedimentos para identificar, documentar, revisar e autorizar quaisquer mudanças no software sob controle da gerência de configuração As mudanças devem ser notificadas aos envolvidos

➪

O fornecedor deve estabelecer e manter procedimentos para registrar, gerenciar e comunicar o status dos itens do software, as solicitações de mudanças e a implantação das mudanças aprovadas

6.2 - Controle da Documentação Inclue: ➪

O fornecedor deve estabelecer e manter procedimentos para controlar todos os documentos relativos a esta parte da ISO 9000, compreendendo: a determinação dos documentos sujeitos a procedimentos de controle de documentos, a aprovação da emissão de procedimentos e procedimentos de mudança de documentos

6.3 - Registros da Qualidade Inclue: ➪

O fornecedor deve estabelecer e manter procedimentos para identificar, coletar, indexar, arquivar , armazenar, manter e disponibilizar os registros da qualidade

➪

Os registros da qualidade devem ser mantidos para demonstrar o atingimento da qualidade requerida e a operação efetiva do sistema da qualidade Registros da qualidade relativos a sub-contratados também devem ser mantidos Os registros da qualidade devem ser protegidos contra deteriorização ou danos Tempos de retenção dos registros da qualidade devem ser estabelecidos

➪ ➪ ➪

6.4 - Medições Inclue: ➪ ➪

➪ ➪

Métricas devem ser usadas para gerenciar o processo de desenvolvimento e de entrega e devem ser relevantes para o produto específico de software O fornecedor deve coletar dados e reportar os valores das métricas em base regular, identificar o nível atual de desempenho a partir das métricas, tomar ações corretivas se o nível da métrica variar em relação aos níveis alvos especificados e estabelecer metas de melhoria em função das métricas O fornecedor deve possuir medições quantitativas da qualidade dos processos de desenvolvimento e de entrega Essas métricas devem refletir quão bem o processo de desenvolvimento está sendo conduzido em termos de pontos de controle (“milestones”) , objetivos de qualidade e qual a efetividade do processo na redução de defeitos

6.5 - Regras,Práticas e Convenções Inclue:

➪

O fornecedor deve prover regras, práticas e convenções para a operação desta parte do sistema da qualidade

6.6 - Técnicas e Ferramentas Inclue: ➪

O fornecedor deve usar ferramentas, facilidades e técnicas para que a operação desta parte do sistema da qualidade seja efetiva

6.7 - Compras Inclue: ➪ ➪ ➪ ➪ ➪ ➪

O fornecedor deve garantir que produtos ou serviços comprados estejam em conformidade com os requisitos especificados Documentos de compra devem conter dados que descrevam claramente os produtos ou serviços comprados O fornecedor deve avaliar sub-contratados com base em suas habilidades para atender os requisitos da sub-contratação Registros de sub-contratados aceitáveis devem ser mantidos O fornecedor é responsável pela validação do trabalho sub-contratado Deve ser facultado ao comprador, avaliar produtos e serviços comprados, bem como sub-contratados

6.8 - Produto de Software Incluso Inclue: ➪ ➪ ➪ ➪

O fornecedor pode ser solicitado pelo comprador a incluir ou usar produto de software fornecido por este ou por terceira parte O fornecedor deve estabelecer e manter procedimentos para a validação,armazenamento, proteção e manutenção de tais produtos Produtos comprados pelo comprador e não adequados para uso, devem ser registrados e notificados ao comprador A validação pelo fornecedor não exime o comprador da responsabilidade de prover produto aceitável

6.9 - Treinamento Inclue: ➪

➪

O fornecedor deve estabelecer e manter procedimentos para identificar as necessidades de treinamento e prover o treinamento para todo o pessoal que desempenha atividades que afetam a qualidade O fornecedor deve manter registros apropriados sobre a realização de treinamento

Da mesma forma como o modelo SEI, o modelo ISO também serve de elemento para a realização de benchmarking.• •

No capítulo 15 também colocamos um checklist pelo qual o leitor pode fazer a autoavaliação de sua organização de desenvolvimento de software.

11.4 - Melhoria Contínua da Qualidade do Software O processo de melhoria contínua baseia-se no ciclo PDCA - Plan - Do - Check Action.

O objetivo é o aperfeiçoamento constante dos processos de planejamento de projetos, desenvolvimento de software e gestão do produto.

A Figura 11-4 mostra o ciclo PDCA para a melhoria contínua.

Indicadores da qualidade

Padronizar

Identificação do problema

A Indicadores da qualidade

P Analisar causas

C

D Contra-medidas

Efeito das contra-medidas

Plano de ação

Adaptado de Arthur 1  Figura 11-4

PLAN O primeiro passo do ciclo de Deming é o planejamento da melhoria , a partir da determinação de objetivos de melhoria em relação aos processos de planejamento de projetos, de desenvolvimento de software, gestão do produto ou em relação a determinadas características do produto.

O planejamento é realizado com as informações coletadas em função do desempenho dos processos atuais. Este desempenho é dado pelas medições respectivas ou, como mostra a figura, pelos indicadores da qualidade.

Os indicadores fornecem informações acerca de áreas problemas ou com potencial de aperfeiçoamento.

Durante o planejamento pode-se utilizar algumas das ferramentas da qualidade como as Listas de Verificação, o Gráfico de Pareto e o Diagrama de Causa-e-Efeito (Ishikawa diagram).

A Figura 11-5 a seguir apresenta um exemplo de aplicação dessas ferramentas.

Folha de Verificação de Defeitos do Software Módulo 1 Módulo 2 Módulo 3 Total

Registros de Defeitos

2

24

1

27

Defeitos do Software Por Tipo - Módulo 2

Defeitos 100 85%

Frequência Acumulada 95% 100%

71% 50

56% 25%

0

25

50%

41%

16

15

15

Diagrama de Causa e Efeito Ambiente

Pessoas

mudanças frequentes

14

10

10%

Processo inexperiente difícil de modificar novas contratações defeitos no software

comunicação inadequada

interrupção de teste

material de consulta não disponível Figura 11-5

Uma vez determinadas as principais causas dos problemas ou das variações do processo, devemos desenvolver contra-medidas eficazes para eliminar a recorrência dos problemas. Isto ocorre na fase do DO do ciclo de Deming.

DO Nesta fase do ciclo de Deming, as contra-medidas (soluções) para os problemas identificados são desenvolvidas e implementadas.

A implementação dessas contra-medidas é planejada em termos de recursos necessários, atribuições e responsabilidades pela implantação, custos previstos, aspectos de gerência,controle e monitoramento do projeto de melhoria.

CHECK A verificação dos resultados da implementação das contra-medidas é feita através das medições operacionais e táticas.

Aqui também podemos utilizar o auxílio de outras ferramentas da qualidade, como a carta de tendência, o gráfico de dispersão e o gráfico de controle, conforme o exemplo dado pela Figura 11-6.

ACTION Uma vez que os resultados são os esperados parte-se para padronizar o processo conforme as melhorias implementadas e, principalmente sustentar a melhoria.

Na medida em que novos objetivos e metas de melhoria são estabelecidas, partese novamente para rodar o ciclo de Deming e assim indefinidamente, aproveitando todas as oportunidades de aperfeiçoamento.

Do ponto de vista do software a melhoria contínua deve concentrar-se principalmente na qualidade, na produtividade, no custo e na satisfação dos clientes/usuários.

Também podemos visualizar a aplicação do ciclo PDCA para aperfeçoar a exatidão das estimativas, o planejamento anual de atendimento, o planejamento de atendimento específico, a qualidade do processo de atendimento e a qualidade do produto ao longo de sua vida útil.

Ou seja, as áreas de aplicação candidatas a melhoria contínua podem compreender desde o nível mais elevado do modelo de gestão de software apresentado neste livro até os seus elementos de maior nível de detalhe.

Carta de Tendência Defeitos do Software Por Semana

Defeitos 50 25 0 1 2

3

4

5

6

7

9 10 Semanas

8

▲

LSC

▲

Gráfico de Controle

média

▲

LIC

Gráfico de Dispersão

Taxa de Defeito

● ●

●

●

● ●

●

●

11.5 - Avaliação do Acervo de Software A avaliação do acervo de software objetiva valorar este ativo da organização, visando fornecer para a administração da companhia uma visão dos investimentos realizados em desenvolvimento e manutenção, dando as condições necessárias para avaliar o retorno do investimento.

O valor do acervo de software de uma empresa é determinado multiplicando-se o somatório do tamanho de todos os software em pontos de função pelo custo do ponto de função de desenvolvimento. Ou seja, quanto custaria para a empresa refazer todo este acervo.

Da mesma forma, podemos determinar o valor do acervo para cada divisão ou departamento da empresa, os quais são os gestores dos respectivos software ou maiores usuários.

Esta demonstração pode ser realizada de forma gráfica para fins de compreensão gerencial.

Talvez o aspecto mais importante da avaliação estratégica seja a medição do retorno dos investimentos em desenvolvimento de software.

Geralmente isto é possível caso tivermos registros quantitativos em relação aos processos empresariais que passam por um processo de automação. Registros estes em termos de custos , ciclos de tempos de processamento etc.

Conforme for o processo empresarial pode-se realizar medições.

Por exemplo, um software que permite alterar profundamente o processo de venda de uma empresa, o resultado pode ser determinado pelo aumento percentual de vendas relativamente ao período antes da introdução da nova sistemática.

Outro exemplo é a melhoria de serviços, pela eliminação de etapas em um processo empresarial. Em bancos, a redução do tempo de análise e concessão de crédito melhora o atendimento, com redução de custo do processo.

A automação industrial melhora a flexibilidade da fabricação, aumentando a qualidade dos produtos e produtividade do processo, com redução de custos e dos custos da qualidade.

Portanto, os elementos básicos para medir o retorno dos investimentos em software existem. A necessidade é que sejam medidos a fim de que as melhorias no negócio sejam percebidas através de fatos e dados.

A partir do próximo capítulo, nossa discussão muda para mostrar aspectos que julgamos fundamentais para a efetiva implantação de medições no ambiente de desenvolvimento de software.

REFERÊNCIAS 1. ARTHUR, Jay Lowel. Improving Software Quality: an insider’s guide to TQM. Wilwy & Sons, New York, 1993.

2. CAMP,Robert. Benchmarking; the search for industry best practices that lead to superior performance. ASQC Quality Press, Milwaukee,Wisconsin,1989.

3. ISO 9000-3 : 1991. Quality Management and Quality Assurance Standards guidelines for the application of ISO 9001 to the development,supply and maintenance o software. International Organization for Standardization.

4.

HUMPHREY,Watts.

Reading,MA,1990.

Managing

the

Software

Process.

Addison-Wesley

5. KEARNS,David. T. Quality Improvement Begins at the Top. Jerry Bowles,Ed. World 20,No. 5 (May,1986) 21

6. LAMPRECHT,James. ISO 9000 e o Setor de Serviรงos. Qualitymark Editora,Rio de Janeiro,1994.

Capítulo

12 VENDENDO E IMPLANTANDO UM PROGRAMA DE QUALIDADE DE SOFTWARE Como qualquer inovação que se pretenda introduzir em uma organização, um Programa de Qualidade de Software requer cuidados especiais, principalmente em uma cultura como a brasileira, cujo planejamento e visão de longo prazo não se constituem em virtudes.

Na verdade este tipo de inovação requer ações no sentido de Planejar a Venda do Programa, Vender o Programa, Planejar a Implantação do Programa, Implementá-lo, Gerenciá-lo e Mantê-lo/Aperfeiçoá-lo.

Por Planejar a Venda estamos considerando as seguintes ações: ➪ ➪ ➪ ➪ ➪ ➪ ➪ ➪

Selecionar o nível de medição em função dos Modelos de Processo em utilização ou que seja praticável medir Determinar os objetivos que se pretende atingir com a medição e portanto selecionar as métricas Aplicar as medições em um projeto-piloto para evidenciar benefícios Pesquisar os casos bem sucedidos de implantação de programas dessa natureza oriundos de outras empresas Determinar o mercado alvo ou segmentos que se pretende “vender” a inovação Arranjar o patrocínio para a inovação Conseguir o apoio dos formadores de opinião, tanto internos como externos à área de informática Elaborar o material de “venda”

Vender o Programa envolve: ➪ ➪ ➪ ➪

Aplicar palestras de sensibilização conforme o segmento do “mercado” Mostrar “ao vivo” se possível ,os casos bem sucedidos Mostrar os resultados do projeto piloto Evidenciar a relação custo/benefício do esforço de medição

Planejar a Implantação compreende: ➪ ➪ ➪ ➪

Definir as estratégias de implantação Definir as atividades e sua sequência lógica para a implantação do Programa Definir os recursos necessários Definir as responsabilidades pelo Programa

➪ ➪ ➪ ➪

Definir a estrutura de coordenação do projeto de implantação do programa Definir o orçamento financeiro necessário Definir os pontos de controle do projeto Definir o cronograma de desembolso

Implementar o Programa compreende o desenvolvimento do projeto.

Gerenciar a implantação do Programa abrange: ➪ ➪ ➪ ➪ ➪ ➪ ➪

Refinar o planejamento inicial Gerenciar as mudanças Replanejar o projeto Aplicar e manter os conceitos éticos Acompanhar o progresso do projeto Avaliar os resultados intermediários e final do projeto Realizar o acompanhamento físico-financeiro do projeto

Por fim, manter e aperfeiçoar o Programa contempla: ➪ ➪ ➪ ➪ ➪ ➪

Utilizar os resultados das medições para tomar ações efetivas visando a melhoria da qualidade e produtividade Disseminar constantemente os resultados, tornando público os benefícios e melhorias obtidas Educar continuamente os integrantes dos vários segmentos do “mercado” Aperfeiçoar o Processo de Software pela introdução do Modelo W, mais detalhado, e aplicar as medições neste nível Introduzir ferramentas de apoio mais avançadas Realizar “benchmarking” contínuo

Como o leitor observou, todo o esforco de implantação de um Programa de Qualidade é encarado aqui como um projeto, cujas fases são justamente o Planejamento da Venda, a Venda, o Planejamento da Implementação, a Implementação e a Manutenção/Aperfeiçoamento.

Estas fases são uma consequência natural da introdução de uma inovação em uma organização. No caso específico de um Programa de Qualidade de Software, o objetivo é evitar os erros que são comuns na implementação, quais sejam: ➲ ➲

➲

➲

A gerência não estabelece claramente os propósitos do Programa e mais tarde vê as medições como irrelevantes Profissionais de sistemas resistem ao Programa, pois o percebem como forma de controlá-los e de gerar comentários negativos sobre seu desempenho Geralmente equipes de projeto que já se encontram sobrecarregadas são prejudicadas com tarefas extensivas e adicionais de coleta de dados referente às medições Os resultados das medições não geram ação gerencial

Um aviso importante neste momento é que um modelo de “Venda e Implantação” de um Programa de Qualidade de Software como o apresentado aqui, e que será detalhado mais adiante, não está considerando peculiaridades de ambiente, clima organizacional e cultura que existem em cada empresa.

Deve-se portanto, analisar criticamente este modelo de forma que seja adaptado à realidade de cada empresa.

12.1- Planejando a Venda do Programa de Qualidade de Software ⌦

Seleção do Nível de Medição

Após a decisão de implementar o Programa de Qualidade , o primeiro passo é selecionar o nível de medição apropriado e, naturalmente, possível.

Como estratégia sugerimos adoção de cautela mesmo que a empresa já possua um Modelo do nível W já em pleno funcionamento.

A medição neste nível é mais complexa e exige recursos de coleta e monitoramento de projeto e processo mais sofisticados. Dificilmente se consegue realizar coleta e análise “na mão” quando se trabalha com modelos mais detalhados.

Caso a empresa já esteja madura e com as ferramentas necessárias disponíveis, pode selecionar o nível mais detalhado. Um fator importante neste caso e que pode contribuir para esta decisão é a existência de cultura corporativa que incentive a medição de processos. Isto geralmente é encontrada em organizações que experimentam ou já experimentaram Programas de Qualidade Total.

Se não for esta a situação da sua empresa, o modelo Universal pode ser o mais apropriado.

Outra consideração a ser feita é que o custo de coleta e análise das medições não deve exceder os benefícios ou economias/melhorias a serem obtidas com o Programa. ⌦

Determinação de Objetivos

Quais são os objetivos que a sua empresa deseja atingir com um Programa de Qualidade de Software?

Alguns objetivos mais comuns são: ➪ ➪ ➪ ➪ ➪

Aperfeiçoar o planejamento de projetos Aumentar a capacidade de detectar defeitos Aumentar a confiabilidade do software Diminuir a densidade de defeitos do software Melhorar os serviços prestados aos usuários/clientes

➪ ➪

Reduzir os custos de não-conformidade Aumentar a produtividade do desenvolvimento, aperfeiçoamento do software

manutenção

e

➪ ➪ ➪ ➪ ➪ ➪ ➪

Minimizar o esforço e prazos de desenvolvimento Reduzir os custos de retrabalho no processo Reduzir os custos de falhas externas Aperfeiçoar os métodos de estimativas de projetos Aperfeiçoar os métodos de gestão dos projetos Determinar tendências relativas a atributos do processo Aperfeiçoar o processo de software

Os objetivos a serem definidos dependem, geralmente: ➪

Das classes de software que são desenvolvidos na empresa, ou seja, sistema operacional, sistemas de missão crítica ( controle de tráfego aéreo é um exemplo), sistemas de tempo-real, sistemas interativos ( sistemas de apoio a combate em caças supersônicos) e sistemas de aplicação comercial.

Por exemplo, em sistemas operacionais, de missão crítica e de tempo-real ,a confiabilidade e desempenho são fatores críticos. Neste caso alguns objetivos da medição podem ser: aperfeiçoar o processo de inspeção formal de software, melhorar o nível de cobertura dos testes e assim sucessivamente.

➪

Empresas que são caracterizadas como de informação intensiva, caso de seguradoras e bancos, cujos produtos são na realidade software, necessitam melhorar a produtividade do desenvolvimento e melhoria de seus sistemas haja visto a intensa competição e possuir sistemas flexíveis em termos de manutenção.

➪

Empresas que se dedicam ao desenvolvimento de software sob medida para terceiros, necessitam reduzir os custos de retrabalho e de falhas externas, bem como realizar estimativas de prazos e custos mais apuradas

➪

Empresas que desenvolvem software-produto, tipo “commodity” necessitam reduzir os custos de falhas externas e controlar as diversas versões dos produtos.

⌦

Selecionar as Métricas

Uma forma interessante de determinar quais métricas utilizar em função dos objetivos nos é dada por Basili 1 com o “Goal/Question/Metric Paradigm” ou paradigma da meta/questão/métrica.

O princípio deste paradigma é: Cada organização ou projeto tem objetivos Para cada objetivo há um conjunto de questões que se pode formular a fim de verificar o atingimento do objetivo Muitas destas questões têm respostas que podem ser mensuradas Os resultados destas mensurações, ao fornecer respostas às questões, podem determinar até que ponto o objetivo está ou foi atingido A Figura 12-1 mostra o relacionamento entre os componentes do paradigma.

Objetivo 1

Questão 1

Métrica 1

Objetivo 2

Questão 2

Métrica 2

Questão 3

Métrica 3

Métrica 4

Figura 12-1

Exemplo de aplicação do paradigma: Objetivo 1: Aperfeiçoar o Planejamento do Projeto Questão 1.1: Qual foi a exatidão da estimativa do prazo do projeto?

Métrica 1.1: Exatidão da Estimaiva de Prazo Fórmula da Métrica: EEP =

Duração Real do Projeto Duração Estimada do Projeto

Questão 1.2: Qual foi a exatidão da estimativa do esforço do projeto?

Métrica 1.2: Exatidão da Estimativa de Esforço Fórmula da Métrica: EEE =

Esforço Real do Projeto Esforço Estimado do Projeto

Vide aplicação deste paradigma pela Motorola  .

Defina portanto seus paradigmas. ⌦

Aplicação de Medições em Projetos-Piloto

A venda de um Programa de Qualidade de Software será mais efetiva caso possamos apresentar exemplos concretos oriundos da própria empresa.

Para tanto é recomendável que o paradigma estabelecido seja aplicado em um projeto-piloto, de preferência de pequeno porte, cujo gerente tenha espírito inovador e aceite a experimentação sem resistências.

Em qualquer empresa encontramos pessoas com estas características.

Em empresas de grande porte, com vários centros de desenvolvimento, este processo pode levar alguns anos 5.

Os resultados da medição servirão de argumento para a venda do Programa. ⌦

Pesquisar os Casos Bem Sucedidos

No Brasil, infelizmente, não temos conhecimento da aplicação de um Programa de Qualidade de Software de forma extensiva.

Entretanto organizações como a CSC 2, Motorola 3, HP 6, GE 4, já implementaram e mantém Programas desta natureza.

Estes casos também devem compor o material de venda. É importante também que os profissionais envolvidos no Programa participem de congressos e seminários no Brasil e exterior sobre o tema.

Um importante forum de discussão sobre Programas de Métricas é o IFPUG. ⌦

Determinar o Mercado Alvo

Em qualquer trabalho de marketing, visando o lançamento de um produto, um passo primordial é a definição dos segmentos de mercado que se pretende atuar.

No caso de um Programa de Qualidade de Software, podemos visualizar os seguintes segmentos alvos: ➩

Alta Administração da Empresa Este segmento está interessado no desempenho das atividades de desenvolvimento/manutenção de software em termos de qualidade ( que significa menores custos), produtividade, custo e apoio aos negócios da corporação, bem como avaliar decisões de investimentos em termos de desenvolvimento de novos produtos, desativação de produtos, substituição e melhoria.

➩

Gerentes Funcionais Este segmento está interessado na qualidade ( desempenho, confiabilidade e funcionalidade ) dos software que apoiam seus processos ou negócios.

➩

Gerência da Tecnologia da Informação Este segmento, composto pelo gerente da área, gerente de desenvolvimento e demais gerentes , está interessado no aperfeiçoamento contínuo do processo de desenvolvimento.

➩

Gerentes de Software/Projetos Este segmento está interessado no controle e aperfeiçoamento dos projetos específicos sob sua responsabilidade.

➩

Engenheiros de Software/Analistas Este segmento está interessado no controle e melhoria de atividades específicas do projeto no qual participa.

⌦

Arranjar o Patrocínio

Não há possibilidade de sucesso da implantação do Programa de Qualidade de Software se o principal executivo da área de tecnologia da informação não se comprometer com o projeto e os esforços de medição ficarem restritos a alguns projetos e não forem sistemáticos.

Comprometimento significa engajamento efetivo, persistência, dedicação, dar o exemplo, exigir que o planejamento seja cumprido , alimentar seu processo de decisão com os resultados das medições preliminares, apoiar publicamente os esforços da equipe do projeto.

Em alguns casos é preciso ser missionário.

Outro aspecto importante é quanto ao “funding” do projeto, ou seja, como a implantação do Programa será financiada.

Dependendo da extensão do Programa e de seu porte, a alçada do gerente de tecnologia da informação pode ser ultrapassada.

Nesta situação somente o comprometimento do gerente não basta. É preciso o patrocínio de um alto executivo da companhia ou seja o executivo campeão.

⌦

Trabalhar os Formadores de Opinião

Os formadores de opinião são pessoas respeitadas por sua “expertise” na área técnica e que exercem influência pronunciada sobre o principal núcleo de gerentes da empresa ou da área de informática.

Muitas vezes apresentam postura extremamente crítica para com idéias ou grupos alheios a sua área de influência, mas, uma vez convencido da relevância de um dado projeto, torna-se um dedicado e leal “campeão” daquela causa. Serve como fonte de informações e referência dentro da organização ( sabe o que foi feito no passado, por quem, e sabe indicar facilmente com quem você deve falar), além de intermediar comunicação informal entre diversas unidades da empresa.

O recado aqui é : conquiste o máximo de aliados. ⌦

Elaborar o Material de Venda

O material de venda deve ser elaborado visando as audiências (segmentos) que se pretende atingir.

Lembrando que os interesses desses segmentos são distintos, o material deve ser elaborado de acordo.

O material de venda pode ser baseado em transparências ou pela utilização de algum software de apresentação (“presentation”) . Neste caso é recomendável o uso de “canhão” ou “datashow” , de preferência colorido.

Para que a “platéia” tenha o registro da apresentação, pode-se fornecer fotocópias do material.

Durante a manutenção do Programa pode-se utilizar outros tipos de materiais de venda .

O material de venda deve ter bons “ argumentos “. Estes argumentos devem ir ao encontro dos respecitvos interesses do “mercado”.

Podemos elaborar dois tipos de materiais, um para ser apresentado à Alta Administração e Gerentes Funcionais e outro para os Gerentes e Engenheiros de Software .

O conteúdo sugerido do material para a Alta Administração ( considere cada tópico como uma transparência ou slide) é apresentado a seguir.(Vide também o material utilizado pela HP  6  para realizar a venda de seu Programa de Métricas)

Agenda da Apresentação Apresentar a estrutura da apresentação e informar o tempo de duração.

Programa de Qualidade de Software:

O que é? Quais os benefícios para a empresa? Qual a estratégia de implantação?

Introduzir as questões que deverão ser respondidas no decorrer da apresentação Os Objetivos Pretendidos Com o Programa de Qualidade Apresentar os objetivos selecionados para serem atingidos com o Programa, enfatizando os aspectos qualidade, produtividade e custos (visão econômica da gestão do software) Quais as Métricas Escolhidas Para Evidenciar o Atingimento dos Objetivos Apresentar as métricas que deverão ser empregadas e em que nível.

Resultados Preliminares em Projeto-Piloto Apresentar os resultados conseguidos com as métricas selecionadas no projeto-piloto ,evidenciando os benefícios atingidos para a melhoria da qualidade, produtividade e redução de custos de desenvolvimento.Mostrar os resultados através de gráficos para melhor compreensão da platéia.

As Melhores Práticas na Indústria Apresentar as melhores práticas na indústria tais como GE ,HP e como, através das métricas, estas empresas conseguiram gerenciar projetos, processo e produto e benefícios conseguidos.

Emprego Estratégico das Métricas Mostrar como as métricas podem auxiliar à alta gerência e os negócios em termos de “benchmarking” , melhoria contínua do processo de software e avaliação econômica do acervo de software da empresa. Deve ser mostrado o impacto na qualidade dos produtos e serviços da empresa e se possível, os ganhos financeiros possíveis de serem obtidos.

Informações Gerenciais Apresentar os relatórios e gráficos gerenciais a serem periodicamente produzidos para a alta administração.

Planejamento Preliminar da Implantação Mostrar o planejamento da implantação, prazos e recursos necessários.

Evidenciar também a estratégia de implantação.

Estimativas de Investimentos Necessários Apresentar os investimentos a serem realizados e detalhá-los a nível de um cronograma de desembolso conforme o prazo de execução do projeto.

O conteúdo para os gerentes e engenheiros de software necessita ter uma abordagem mais técnica e conceitual. Nossa sugestão é a adoção do roteiro a seguir apresentado.

Agenda da Apresentação Apresentar a estrutura da apresentação e informar o tempo de duração.

Programa de Qualidade de Software: O que é? Quais os benefícios para a empresa? Qual a estratégia de implantação?

Introduzir as questões que deverão ser respondidas no decorrer da apresentação Os Objetivos Pretendidos Com o Programa de Qualidade Apresentar os objetivos selecionados para serem atingidos com o Programa, enfatizando os aspectos qualidade, produtividade e custos (visão econômica da gestão do software) Conceitos de Qualidade de Software Apresentar os conceitos básicos de qualidade de software e evidenciar a necessidade por medições.

Resultados Preliminares do Projeto-Piloto Apresentar os resultados conseguidos com as métricas selecionadas no projeto-piloto ,evidenciando os benefícios atingidos para a melhoria da qualidade, produtividade e redução de custos de desenvolvimento.Mostrar os resultados através de gráficos para melhor compreensão da platéia.

As Melhores Práticas na Indústria Apresentar as melhores práticas na indústria tais como GE ,HP e como, através das métricas estas empresas conseguiram gerenciar projetos, processo e produto e benefícios conseguidos.

Quais as Métricas Escolhidas Para Evidenciar o Atingimento dos Objetivos Apresentar as métricas que deverão ser empregadas e em que nível.

Medições Estratégicas ,Táticas e Operacionais Mostrar como as métricas deverão ser utilizadas para fins de gerenciamento do ambiente de software como um todo, os tipos de ações possíveis de serem tomadas e o apoio ao negócio da empresa.

Como as Métricas Escolhidas Auxiliarão os Gerentes a Gerenciar os Projetos e Processo de Desenvolvimento Mostrar como cada métrica definida auxiliará os gerentes em suas atribuições. Mostrar quais os gráficos possíveis de serem empregados para

a apresentação dos resultados das métricas e para fins de tomada de decisão gerencial. Detalhar o nível operacional de medição.

Os Princípios Éticos do Programa Apresentar a “regra do jogo” no que tange à utilização das medições pelos gerentes.

Planejamento Preliminar da Implantação Apresentar como se dará a implantação do Programa e expor algumas das responsabilidades a serem assumidas por membros da equipe.

Próximos Passos Apresentar os próximos passos.

12.2 - Vendendo o Programa A venda do Programa ou o “momento da verdade” , deve obedecer uma sequência lógica caracterizada por , em um primeiro momento , a apresentação da palestra de sensibilização à Alta Administração , caso o Programa for aprovado nesta instância, partir então para o trabalho de venda aos gerentes e engenheiros de software.

O apoio concreto da Alta Administração é condição necessária para o sucesso do projeto. Sem este apoio, qualquer esforço está fadado ao fracasso.

Quando do agendamento da palestra de sensibilização devemos observar alguns procedimentos: ➩ ➩ ➩ ➩

➩

Selecionar as pessoas que deverão ser convidadas à apresentação Agendar com antecedência a apresentação e enviar comunicação para os participantes Procurar realizar a apresentação em local cuja interrupção seja a mínima possível ( infelizmente hoje temos o “celular” ) No dia anterior à apresentação certificar-se de que o material esteja em ordem; se for utilizar projeção com “datashow” ou “canhão”, testar os equipamentos na véspera Designar uma pessoa para realizar anotações durante a apresentação, visando registrar as questões colocadas pela platéia, sugestões, críticas, diretrizes e assim sucessivamente

Outras abordagens possíveis de serem empregadas consistem em: ➩ ➩ ➩

Usar o testemunho do gerente do projeto piloto Mostrar ao “vivo”, se possível , os resultados bem sucedidos de implantação de Programas de Qualidade (Métricas) de Software Fazer com que o pessoal técnico participe de congressos, encontros e seminários relativos ao tema

12.3 - Planejamento da Implantação ⌦

Definição das Estratégias de Implantação

Conforme for o nível de resistência da equipe de gerentes e engenheiros de software é preciso estabelecer algumas estratégias para a implantação bem sucedida do Programa.

Em uma situação deste tipo a abordagem é gerar e aproveitar o efeito demonstração.

Iniciar a implantação pelos projetos cujos gerentes e engenheiros de software são inovadores e apreciam as mudanças e vêem num trabalho deste tipo , oportunidade de crescimento profissional.

Com a disseminação dos primeiros resultados , a apreciação pela Alta Administração e com a consequente análise comparativa entre os projetos controlados (que utilizaram o modelo de qualidade) e os não controlados , começa-se a evidenciar o caminho a ser seguido. É muito provável que as resistências serão removidas com sucesso.

Se a empresa utiliza serviços terceirizados para o desenvolvimento de projetos de software é recomendável que estes fornecedores sejam inseridos no âmbito do Programa de Qualidade.

Sempre quando possível procurar adquirir software-produto disponível no mercado para apoio ao Programa, tais como: gerenciador de projetos, software de estimativas, software para controle de custos da qualidade, banco de dados de métricas e assim sucessivamente.

A estratégia também deve definir os estágios de implantação do Programa, por quais métricas as primeiras medições serão realizadas, em que ponto a qualidade vai começar a ser medida e assim por diante. ⌦

Definição do Roteiro de Implantação

É impossível elaborar o Planejamento da Implantação do Programa sem uma sequência lógica de atividades que configura um roteiro de trabalho a ser seguido durante a implantação do projeto.

Este roteiro é necessário para estabelecer tempos , recursos a serem empregados, responsabilidades, estrutura de coordenação do projeto, cronograma de execução , pontos de controle (revisão gerencial) do projeto e cronograma de desembolso de recursos financeiros. Um exemplo de roteiro de implantação é fornecido a seguir.

Tabela 12-1

ATIVIDADE 1.Estruturar a Equipe do Projeto 2. Capacitação em Métricas e Qualidade de Software

FINALIDADE DA ATIVIDADE Designar pessoas para o projeto e atribuir responsabilidades Capacitar gerentes e engenheiros de software na coleta e análise das métricas, bem como as ações decorrentes

3. Seminário Gerencial Sobre o Programa de Qualidade 4. Capacitação em Function Points

Conscientizar os gerentes funcionais quanto a importância do Programa Capacitar gerentes e engenheiros de software na aplicação da Análise Por Pontos de Função

5. Capacitação em Planejamento de Projetos de Software

Capacitar gerentes e engenheiros de software na aplicação de método e ferramentas de estimativas de prazos,custos e recursos

6. Capacitação na Aplicação das 7 Ferramentas da Qualidade

Capacitar gerentes e engenheiros de software no emprego das 7 ferramentas da qualidade a fim de apoiar na solução de problemas

7. Capacitação na Utilização de Ferramentas e Modelos Estatísticos

Capacitar gerentes e engenheiros de software na aplicação de ferramentas estatísticas para análises dos resultados de métricas Capacitar gerentes e engenheiros de software na técnica de inspeção formal de software Capacitar gerentes e engenheiros de software na análise de complexidade do produto de software em desenvolvimento Determinar pontos fortes e fracos do processo de software atual Padronizar o processo atual e inserir técnicas de inspeção, testes etc.

Estruturação da função de garantia da qualidade

8. Capacitação em Inspeção em Software 9. Capacitação em Análise e Complexidade de Design 10. Avaliação do Processo de Software 11.Implementação de Melhorias no Processo Atual 12.Estruturação do Ambiente Voltado Para a Qualidade 13.Seleção de Produtos Disponíveis no Mercado 14.Implantação de Ferramentas 15.Desenvolvimento de Ferramentas 16.Implementar as Melhorias no Processo 17.Implementar as Medições 18.Disseminar o Programa da Qualidade 19. Acompanhamento do Programa 20. Publicar os Resultados do Programa 21.Disseminar o Modelo de Qualidade Para as Empresas Contratadas

Selecionar produtos disponíveis no mercado para a elaboração de estimativas e controle da qualidade de software Implantação das ferramentas disponíveis no mercado Desenvolver ferramentas complementares para apoio ao Programa Implementar nos novos projetos as melhorias no processo Implementar as medições nos novos projetos Implementar o modelo da qualidade a nível das manutenções e melhorias de software Acompanhar a implantação do Programa e avaliar os resultados Publicar os primeiros resultados positivos do Programa Disseminar ou desenvolver os fornecedores da empresa caso houver

⌦

Definir os Recursos Necessários

Os recursos para a implantação de um Programa de Qualidade de Software podem incluir: ➲

Recursos Humanos Neste item devem ser considerados: ➩ ➩ ➩

➲

Gerente/Coordenador do projeto Equipe de apoio técnico do projeto Alocação do tempo dos demais profissionais nas atividades de treinamento e capacitação e implantação das métricas nos projetos

Recursos de Software Compreendem: ➩ ➩ ➩ ➩ ➩ ➩ ➩

Gerenciador de projetos Ferramenta de estimativa Ferramenta de monitoramento de defeitos (“defect tracking”) Ferramenta estatística Banco de dados de projetos e métricas Ferramenta para controle de custos da qualidade Ferramenta para controle de ações corretivas

➲

Recursos Ambientais e Materiais Compreendem espaço físico para a equipe do projeto, materiais de consumo, serviços de documentação e assim sucessivamente.

➲

Treinamento Cursos de capacitação , seminários (internos ou externos), participação em congressos, encontros etc.

➲

Recursos de Hardware Para utilização das ferramentas de software e para apresentações, treinamentos e documentação do projeto.

➲

➲

Serviços Externos Consistem em serviços de consultores externos software sob medida para apoiar o Programa.

apoio

às

e desenvolvimento de

Outros Serviços Consistem em serviços de transportes ( terrestre e aéreos), alimentação etc.

⌦

Definir as Responsabilidades e Estrutura de Coordenação

Um projeto como a implantação do Programa de Qualidade de Software requer que as responsabilidades sejam claramente definidas em relação à estrutura de coordenação e às pessoas que realizarão as medições operacionais.

A estrutura de coordenação do projeto é o forum de resolução de conflitos e pendências, bem como a instância que define diretrizes, avalia e homologa produtos intermediários , autoriza o replanejamento do projeto e define a alocação e a realocação de recursos ao projeto.

A composição desta estrutura depende do porte e extensão do Programa e, naturalmente, da importância para a empresa.

Quanto maior o porte, a importância e os recursos destinados ao Programa, é aconselhável que a coordenação geral fique no mais alto nível da empresa ou que tenha acesso à Alta Administração.

Este conceito é básico para o gerenciamento de qualquer tipo de projeto, mesmo não sendo orientado à implantação de Programa da Qualidade.

No nível de execução propriamente, as seguintes responsabilidades devem ser definidas: ➩ ➩ ➩ ➩ ➩ ➩

⌦

Quem tem a responsabilidade pela coleta das informações sobre as medições Quem tem a responsabilidade pela manutenção dos registros de coleta Quem tem a responsabilidade pela análise das medições Quem tem a responsabilidade pela manutenção dos registros das medições Quem tem a responsabilidade pelo relato das análises Quem encaminha as ações necessárias em função dos resultados das medições Definição dos Pontos de Controle

Os pontos de controle de um projeto geralmente estão associados a produtos intermediários, 100% inspecionáveis, e que evidenciam o seu progresso .

Dessa forma, ao elaborar o roteiro de implantação do projeto, identificar como ponto de controle, àquelas atividades que compõem o caminho crítico.

As revisões gerenciais, objeto de reuniões de progresso, devem ser agendadas conforme os pontos de controle previstos.

⌦

Elaboração do Orçamento do Projeto

Uma vez que os recursos necessários e o cronograma de execução, com datas de início e término para cada atividade, foram definidos, pode-se elaborar o orçamento financeiro do projeto e o consequente cronograma de desembolso, ou seja, quanto vai ser despendido mensalmente em termos monetários pelo projeto, para fins de gerenciamento.

12.4 - Gerenciando a Implantação do Programa A gerência de projetos baseia-se em alguns princípios universais os quais são relatados neste tópico. ⌦

Monitoramento do Progresso do Projeto Que compreende a realização de reuniões periódicas de avaliação dos trabalhos e de revisão gerencial conforme os pontos de controle, nas quais participem os membros da equipe de coordenação do projeto e no preparo de relatórios de posicionamento para serem distribuídos aos integrantes da administração da companhia.

Este monitoramento deve abranger não só a consecução física do projeto como também financeira.

⌦

Gerenciamento de Mudanças Em qualquer tipo de projeto ocorrem contigências, as quais são ocorrências de eventos que podem impactar negativamente o projeto em termos de prazo e custo.

Alterações de escopo são comuns, assim como o não atendimento da programação de alocação de recursos.

As ocorrências de contingências, voluntárias ou não, devem ser analisadas quanto ao seu impacto no projeto.

Caso houver impacto em prazos e consequentemente em custos, o projeto deve, necessáriamente , sofrer um replanejamento. Não dá para fingir que nada aconteceu e pensar que o tempo será recuperado nas etapas seguintes do projeto. Isto é um dos maiores erros que os gerentes de projetos podem cometer, pois em processos de implantação de inovação, cuja aprendizagem ocorre durante o desenvolvimento do projeto, o tempo jamais é recuperado.

Nesta situação o mais correto é negociar com a administração da companhia ou a gerência de tecnologia da informação este replanejamento.

Para tanto é imprescindível a constituição de um dossiê gerencial do projeto com o registro de todos os fatos e a evidência de análises de impacto. ⌦

Comprometimento Com Princípios Éticos Os princípios éticos de conduta devem ser mantidos a qualquer custo, sob pena do projeto tornar-se um retumbante fracasso. Na medida em que os princípios não são seguidos, o pessoal que tem a responsabilidade por coletar dados e analisar os resultados das medições começará sabotar todo o esforço.

Gerenciar projetos também é uma de instrução contínua das pessoas envolvidas com o mesmo.

⌦

Avaliação dos Resultados Avaliar resultados intermediários possibilita ação imediata para reestabelecer a qualidade dos produtos que estão sendo gerados pelo projeto evitando comprometer a credibilidade do mesmo.

Sempre há possibilidade para aperfeiçoar o próprio processo de desenvolvimento do projeto e corrigir seus rumos.

Em um Programa de Qualidade de Software não existem resultados finais absolutos pois a qualidade também não é algo absoluto. Podemos considerar estágios de qualidade dentro de um espaço de tempo.

Portanto, objetivos quantitativos de qualidade devem ser estabelecidos como metas para um período de tempo pré-determinado.

Os resultados de um Programa de Qualidade de Software devem ser considerados sob esta ótica.

Ao final do projeto Programa da Qualidade de Software , deve-se avaliar o atingimento dos objetivos propostos para o período de duração do mesmo e realimentar o processo para evoluir a fase seguinte do Programa que a partir daí passa a ser um esforço permanente de melhoria contínua da qualidade.

12.5 - Manutenção e Melhoria do Programa de Qualidade de Software Ao terminarmos a fase de implantação do Programa , iniciamos a parte mais difícil que é mantê-lo , nutrí-lo e aperfeiçoá-lo.

Algumas estratégias básicas sugeridas são:

➲

Aperfeiçoar o Processo de Software pela introdução do Modelo W , mais detalhado, e aplicar as medições neste nível, visando obter as condições para o gerenciamento efetivo de projetos, processo e produto.

➲

Educar e retreinar continuamente os integrantes dos vários segmentos do “mercado”. Na medida em que o processo de software se sofistica, com êle se sofistica o nível de medição, as métricas e as metas de qualidade.

➲

Disseminar constantemente os resultados das medições, apresentando os benefícios concretos e melhorias obtidas. Uma alternativa é realizar encontros internos sobre Qualidade de Software , editar “jornalzinho” ou relatórios técnicos.

➲

Introduzir ferramentas de apoio mais avançadas. Por exemplo, ferramentas como o Checkpoint desenvolvida pela Software Productivity Research, empresa pertencente à Capers Jones 8, permite realizar estimativas completas a partir do tamanho de pontos de função do software.

O leitor deve ter percebido que colocamos uma ênfase exagerada neste capítulo.

Foram dezoito páginas. Entretanto, de que adiantaria falarmos o tempo todo sobre métricas se não houvessem as explicações necessárias de como implantá-las numa organização?

REFERÊNCIAS 1. BASILI,V & WEISS,D. A Methodology for Collecting Valid Software Engineering Data.IEEE Transactions on Software Engineering, Vol SE-10,No. 6 ,nov 1984.

2. BELDEN, Andy. Managing With Metrics. IV Encontro Nacional de Usuários de Pontos de Função. IBPI, Rio de Janeiro, 1993.

3. CARD,David . Engenharia da Qualidade de Software. IBPI, Seminário,Rio de Janeiro,1993.

4. DASKALANTONAKIS,Michael. A Practical View of Software Measurement and Implementation Experiences Within Motorola.IEEE Transactions on Software Engineering,Vol 18, No. 11, November 1992.

5. GRADY, R. & CASWELL,D.L. Software Metrics: Establishing a Company-Wide Program. Prentice-Hall, Englewood Cliffs, New Jersey,1987.

6. GRADY,R . Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall, Englewood Cliffs, New Jersey, 1992.

7.JONES,Capers. Applied Software Measurement.McGraw-Hill,New York,1991.

Capítulo

13 ÉTICA NA UTILIZAÇÃO DOS RESULTADOS DAS MEDIÇÕES Apesar dos amplos benefícios que podem ser obtidos com a utilização das métricas para o gerenciamento dos projetos e produtos de software, há um item extremamente sensível que deve ser levado em consideração e que, se negligenciado, pode conduzir ao fracasso tentativas bem intencionadas de medições.

O item sensível ao qual estamos nos referindo é o fator humano. Isto significa que algumas políticas corporativas devem nortear a forma como os dados das medições devem ser coletados e analisados a fim de não ferir suscetibilidades pessoais que possam comprometer todo o esforço de implementar e manter um programa de métricas.

Neste contexto é fundamental que a gerência estabeleça quais as informações que devem ser mantidas a nível de cada projeto e aquelas que podem ser divulgadas de forma mais ampla, tendo em vista as várias audiências contempladas com os resultados das medições.

Entretanto , esta é somente uma das atitudes requeridas da gerência. A outra e talvez a mais importante é o comprometimento na manutenção de algumas regras visando a implantação e evolução de um esforço de medição mais amplo.

O princípio básico que norteia as regras, cujo conjunto deve orientar o comportamento ético da gerência e das equipes de desenvolvimento, fundamenta-se no que podemos considerar um axioma enunciado por Deming  : “85% dos problemas que ocorrem nos processos da empresa é de responsabilidade da gerência”.

Consequentemente a medição jamais deve avaliar desempenhos individuais e sim enfocar processos e produtos os quais são desempenhados por equipes.

O primeiro passo para adotarmos certas regras é determinar quais informações devem ser mantidas no nível restrito do indivíduo , no nível da equipe do projeto, no nível do departamento de informática e no nível da alta gerência da empresa.

O segundo passo é a implantação das regras de conduta em si.

Estes dois aspectos é que definem o que denominamos de ética na utilização das medições.

11.1 - Níveis de Privacidade dos Resultados das Medições Os níveis de privacidade são basicamente quatro, quais sejam: O indivíduo A equipe de desenvolvimento O departamento de informática A alta gerência da empresa ⌦

Nível de Privacidade- o Indivíduo

Como o objetivo não é medir o desempenho individual , toda e qualquer informação que, de alguma maneira, tenha a probabilidade de ser utilizada de forma prejudicial a uma pessoa deve ser privada a ela. Neste caso podemos incluir: ➩ ➩ ➩ ➩

Taxas de defeitos do indivíduo Número de compilações efetuadas pelo indivíduo Produtividade pessoal medida Tempo médio de atendimento do indivíduo para solicitações de manutenção

A privacidade neste nível significa não medir qualquer um deste elementos. ⌦

Nível de Privacidade - Equipe do Projeto

Grande parte das métricas de projeto e produto ( operacionais), conforme relacionadas no Capítulo 3 , devem ser privativas da equipe do projeto, pelo menos durante o desenvolvimento do software ou da implementação de “releases” e serem compartilhadas somente pelo gestor da área de desenvolvimento e/ou pelo responsável pela área de informática.

Dessa forma evita-se o constrangimento da própria equipe em relação ao desempenho das outras ou, ao contrário.

Tais informações poderão ser registradas em um Banco de Dados para futura pesquisa por outras equipes porém, deve-se determinar o tempo em que poderão ser liberadas. A idéia aqui é que tanto as experiências bem sucedidas ou não , realimentem o planejamento da melhoria da gestão dos projetos, dos produtos e do processo de desenvolvimento.

Neste caso podemos dar a liberdade para as equipes efetuarem medições específicas , de seu próprio interesse, que as auxiliem no monitoramento dos objetivos do projeto.

De acordo com a prática da HP, muito bem relatada por Grady   no planejamento do projeto ou da “release”, quando são estabelecidas quais informações deverão ser coletadas, a equipe fica mais confortável em tornar os resultados públicos e aceita mais facilmente ser avaliada conforme as métricas inicialmente estabelecidas.

⌦

Nível de Privacidade - Departamento de Informática

As informações sobre o desempenho dos projetos conforme os padrões estabelecidos ou análises comparativas entre projetos, somente é do interesse do responsável pela área de informática e do desenvolvimento.

Entretanto, informações acerca das medições táticas : análise de tendências, análise de impactos e análise de atributos , podem ser públicas a nível do departamento a fim de que todos os gerentes de projeto e produtos possam beneficiar-se das informações no sentido do aprimoramento contínuo. ⌦

Nível de Privacidade - A Alta Gerência da Empresa

As medições estratégicas , cuja principal audiência é a alta administração da empresa, podem ser públicas a este nível com o conhecimento óbvio da gerência do Departamento de Informática.

Entretanto, como são informações de caráter estratégico, não devem ser disponíveis para outras gerências funcionais e divulgadas de forma detalhada para “fora da empresa”.

Esta atitude é recomendável para aquelas empresas cujo software é o principal insumo do processo de geração de bens e serviços e que lhes propiciam diferenciação mercadológica.

11.2 - Regras de Conduta Para a Utilização das Medições Apresentamos a seguir algumas regras de conduta que devem ser observadas quando da implementação, manutenção e evolução de um esforço de medição.

➊ Defina claramente quais métricas deverão ser coletadas e analisadas ➋ Defina como os resultados das métricas serão utilizados ➌ Defina as métricas que serão empregadas no projeto desde o seu planejamento ,de preferência em conjunto com a equipe ➍ Não permita que utilizem os resultados das métricas para avaliar o desempenho individual ➎ Não utilize as métricas que as equipes de projeto coletaram para qualquer tipo de penalização ; não use as métricas contra a equipe ➏ Não enfatize uma métrica sobre as outras ➐ Dê “feed-back” periódico à equipe do projeto quanto às análises das métricas ➑ ➒ ➓

Utilize as métricas para a melhoria contínua da gestão de projetos e produtos e do processo de desenvolvimento Mantenha comprometimento com o esforço de medição, de forma que as equipes de projeto o alimentem com informações acuradas Não deixe que as equipes com desempenho superior façam propaganda de seus feitos junto às outras equipes

Por fim é importante ter em mente que a obtenção da qualidade desejada é de responsabilidade de todos, mas principalmente dos níveis gerenciais, pois são eles que definem orçamentos, aprovam aquisição de recursos, dão a última palavra no que concerne a utilização de plataformas de desenvolvimento, implementam efetivamente o processo de gestão, o processo de software, definem programas de treinamento e assim sucessivamente.

Capítulo

14 NOVAS RESPONSABILIDADES PARA OS GESTORES DE SOFTWARE Neste Capítulo procuraremos apresentar as novas dimensões de responsabilidades dos gestores de software de acordo com os conceitos que até aqui temos discutido.

Não nos restringeremos somente ao Gerente de Projetos de Software. Por se tratar de um livro também de cunho gerencial ,e que fornece uma abordagem mais ampla sobre a gestão do software em uma organização, discutiremos as responsabilidades e papéis que o Gerente de Desenvolvimento ou de Sistemas e o Gerente do Departamento de Informática devem assumir em um novo cenário.

Geralmente são tópicos esquecidos nos livros sobre Gerência de Projetos.

Estas dimensões de responsabilidades estão fortemente ligadas aos seguintes aspectos: ➲ ➲ ➲ ➲ ➲ ➲

Natureza dos projetos de software e “release” Implantação, manutenção e aprimoramento de um programa de métricas Obtenção da Certificação da Qualidade conforme a norma ISO Melhoria contínua do processo de software conforme o modelo SEI A gestão da complexidade tecnológica (integração de tecnologias) A gestão da mudança ( que em última análise engloba os demais)

14.1 - As Responsabilidades dos Gerentes de Projetos de Software Podemos dividir as responsabilidades dos Gerentes de Projetos de Software em duas categorias, ou seja, Gerenciais-Técnicas e Gerenciais-Organizacionais. Estas duas categorias podem ainda ser sub-divididas em Básicas e Avançadas.

Na verdade podemos visualizar a seguinte matriz: Básicas

Avançadas

Gerenciais Técnicas Gerenciais Organizacionais

As responsabilidades básicas representam os elementos mínimos necessários para a gestão bem sucedida de um projeto de software.

As responsabilidades avançadas representam formas mais evoluídas de ver a gestão do projeto, o que inclue a gestão da mudança de uma forma mais abrangente, a gestão tática e estratégica do software. ⌦

Gerenciais-Técnicas Básicas

Dentro desta categoria há quatro responsabilidades principais, quais sejam: Definição do Projeto Esta responsabilidade diz respeito à elaboração do Planejamento do Projeto, cujo produto é o Plano do Projeto.

Mais especificamente, o Gerente de Projeto deve: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Caracterizar a solução que deverá ser desenvolvida; Definir as premissas e diretrizes que nortearão o projeto; Definir os recursos a serem empregados no projeto; Definir a estrutura de organização e de gestão do projeto; Definir o roteiro de desenvolvimento do projeto; Definir o cronograma básico do projeto; Definir os “pontos de controle” do projeto para fins de revisão gerencial; Identificar os padrões a serem utilizados.

Estimativas e Cronogramação Este conjunto de responsabilidades geralmente está associado à elaboração do Plano do Projeto, entretanto, devido a sua importância a colocamos como um ítem a parte.

Dizem respeito a: ➩ ➩ ➩

Estimar prazos ,custos, recursos e tamanho do software, com uso de ferramentas de estimativas ou não; Estimar o esforço de desenvolvimento para o projeto como um todo e para cada uma das fases estabelecidas; Estimar os prazos para cada fase de desenvolvimento.

Esta categoria talvez seja uma das mais difíceis do gerente realizar visto que, na maioria das instalações ,não há “história” registrada a fim de subsidiar as estimativas.

Sua importância reside no fato de que as estimativas geram um comprometimento do gerente com sua gerência e com os usuários além de, naturalmente, criar expectativas junto a estes últimos.

Outro complicador é que, atualmente, muitos projetos de software estão inseridos em um contexto de integração de tecnologia, por exemplo,

utilizando o “mainframe” como servidor de dados e as funções sendo executadas em um ambiente “client-server” com aplicações escritas em GUI (Graphical User Interface). Ou seja, a “história” passada não ajuda muito.

Controle do Projeto O controle do projeto abrange: ➩ ➩ ➩ ➩ ➩

Refinamento do projeto ao longo do seu desenvolvimento; Replanejamento do projeto em função de mudanças, inclusive com novas estimativas; Controle de mudanças de escopo do projeto; Controle de alocação de recursos; Verificação e validação de produtos intermediários em termos de padrões de desenvolvimento, aderência às especificações e aos requisitos dos usuários, funcionalidade e assim sucessivamente;

Monitoramento do Projeto O monitoramento do projeto é a tarefa de tornar disponível para os usuários e gerência de informática, informações sobre o progresso do projeto.

O progresso do projeto é baseado na verificação do término efetivo (100%) dos produtos intermediários do projeto ,devidamente validados e de acordo com os padrões e aderente às especificações e requisitos dos usuários.

Neste caso o gerente do projeto deve atentar para as diferentes necessidades de informações requeridas pela gerência de desenvolvimento e de informática e os usuários.

Geralmente as gerências de desenvolvimento e informática requerem informações acerca do esforço, prazos, custos realizados, situação dos produtos em termos de sua completeza, bem como relato de ocorrências, as quais podem impactar negativamente em prazos e custos.

Os usuários por sua vez, requerem informações acerca de prazos, pendências e completeza dos produtos.

⌦

Gerenciais- Organizacionais Básicas As responsabilidades organizacionais básicas abrangem os aspectos comportamentais, de negociação, motivacionais, bem como as tarefas administrativas a seu cargo. ➩ ➩

➩

➩

➩

⌦

O gerente de projeto deve manter a motivação da equipe ao longo do desenvolvimento; O gerente de projeto deve dar grande ênfase à integração das tarefas e atividades do projeto, uma vez que cada área funcional apresenta seus propósitos e objetivos particulares, ocasionando desentendimentos e conflitos; O gerente de projeto deve negociar entre as partes interessadas, usuários e gerência de informática quanto a prazos, recursos, revisão de escopo etc.; O gerente de projeto deve executar as funções administrativas requeridas, tais como elaboração de relatórios de progresso, comunicações com áreas de apoio etc.; O gerente de projeto deve conseguir a colaboração de várias pessoas na organização para atingir os objetivos específicos do projeto, o que exige constante trabalho de convencimento e negociação.

Gerenciais-Técnicas Avançadas

As responsabilidades técnicas avançadas estão associadas com as medições ao longo do projeto, visando a obtenção do “nível aceitável de qualidade” dos produtos intermediários e final do mesmo.

Portanto diz respeito à qualidade da gestão do projeto e dos produtos gerados e a satisfação dos usuários (cliente).

Neste contexto o gerente de projeto deve: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Realizar as medições relativas a prazo, custo,tamanho , recursos do projeto e esforço; Determinar, a partir de Inspeções Formais de Software, os níveis e tipos de defeitos introduzidos nos produtos intermediários; Gerir os custos da má qualidade do projeto, em termos de falhas internas e custos de prevenção e avaliação; Implementar técnicas de testes de sistemas e de verificação, visando reduzir os defeitos introduzidos no produto; Gerir e controlar as versões dos produtos do projeto; Implementar o Plano de Qualidade do projeto; Medir a satisfação dos usuários quanto aos resultados do projeto e seus produtos; Realizar as medições de produtividade do projeto; Realizar os registros da qualidade pertinentes;

⌦

Gerenciais-Organizacionais Avançadas

As responsabilidades organizacionais avançadas dizem respeito engajamento do gerente em um esforço de inovação e seu papel requerido.

ao

Todos nós sabemos que um processo de inovação em uma empresa , requer alguns papéis-chaves. Um desses papéis é o que Kugler   definiu como Campeão do Produto.

O campeão do produto é o gerente do projeto. É o indivíduo que cria, define, ou adota uma idéia para lançar uma dada inovação e que está disposto a arriscar seu cargo e prestígio ( geralmente baseado no seu poder de perícia ) para apoiar a bemsucedida implantação do projeto.

Seus papéis principais são os de gerar novas idéias e testar sua viabilidade eficaz na resolução de problemas que exigem criatividade e determinação; agressivo e teimoso em promover suas idéias.

Muitas vezes consegue recursos informalmente, com consentimento tácito das gerências; sabe muito bem como usar a estrutura para conseguir fazer andar o projeto; sabe agir politicamente e sabe equilibrar necessidades de mercado e restrições técnicas.

14.2 - As Responsabilidades dos Gerentes de Desenvolvimento A responsabilidade principal do gerente de desenvolvimento é a de gerir o ambiente de software visando a melhoria contínua do processo. Isto inclue, mas não está limitado a : ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Introduzir e administrar a utilização de novas técnicas e métodos para a melhoria da qualidade do planejamento dos projetos; Administrar a introdução de Inspeções Formais de Software; Fornecer as ferramentas necessárias para a gerência da configuração do software; Administrar a introdução de métodos de planejamento e execução de testes de software; Administrar a introdução de planos da qualidade para cada projeto de software; Fazer com que os gerentes de projeto realizem as medições relativas aos projetos e produtos; Promover a atualização técnica períódica do pessoal de projetos; Realizar as medições de caráter tático, relativas ao ambiente de desenvolvimento como um todo; Determinar as condições que contribuem para projetos produtivos e de qualidade e implementá-las; Monitorar a melhoria das práticas de desenvolvimento de software em termos de qualidade, produtividade etc.;

➩ ➩ ➩

Verificar o impacto da introdução de novas tecnologias; Avaliar comparativamente os projetos em termos de qualidade e produtividade e identificar causas de problemas; Implementar ações corretivas eficazes , visando eliminar recorrência de problemas

14.3 - As Responsabilidades dos Gerentes de Informática Em uma filosofia de qualidade, aplicada ao desenvolvimento de software , a responsabilidade principal do gerente de informática é a de ser o grande patrocinador da implementação das mudanças.

Isto significa influenciar diretamente no processo de alocação de recursos, usar seu poder para canalizar recursos para uma dada inovação, assumindo em grande parte, quando não no todo, o risco da implantação da inovação.

Geralmente não tem tempo para desenvolver e promover suas próprias idéias, entretanto deve ser capaz de defender a “inovação” com o apoio decisivo dos “campeões de produto”.

Deve promover o acesso de sua equipe à base do poder da oraganização, legitimando a inovação.

Deve fornecer direcionamentos e conselhos à equipe , auxiliando os “gerentes campeões”, muitas vezes de forma velada, incentivando e encorajando o desenvolvimento pessoal.

Sabe isolar a sua equipe de restrições organizacionais, dando o tom de equilíbrio entre exigências administrativas e autonomia técnica.

Sabe selecionar pessoas e projetos; sabe “quem se dá bem com quem”.

Sabe cobrar resultados de maneira gradual; pouca pressão no início, de maneira a estimular divergências e pensamento criativo, e aumentando gradativamente o grau de exigência , de forma a estimular convergência e refinamento de soluções na fase final do implementação da mudança.

Adicionalmente o gerente de informática deve ser capaz de: ➩ ➩ ➩ ➩ ➩ ➩ ➩ ➩

Fornecer os meios para a estruturação do ambiente de desenvolvimento de software orientado à qualidade; Estruturar as funções de “Quality Assurance” do ambiente; Estruturar as funções de Gerência da Configuração; Planejar a evolução do estágio de maturidade do desenvolvimento do software e orientar a implementação de ações sistemáticas para este fim; Implantar o Sistema da Qualidade; Realizar “benchmarking” do ambiente com outras empresas; Avaliar economicamente o acervo de software da organização; Gerir os custos da má qualidade do ambiente, redirecionando os investimentos para a prevenção;

➩ ➩

Revisar criticamente o Sistema da Qualidade, conforme periodicidade pré-determinada; Monitorar as ações corretivas para eliminar recorrência de causas de problemas;

Capítulo

15 AUTO-AVALIAÇÃO DO ESTÁGIO DE MATURIDADE DE SOFTWARE Este capítulo tem por objetivo auxiliá-lo na realização de uma auto-avaliação referente ao estágio de evolução que sua empresa se encontra em termos da gestão do software,considerando o termo mais amplo que até aqui temos empregado.

Para tanto, trazemos três instrumentos de auto-avaliação que também podem ser utilizados como elementos para análise de benchmarking, bem como ponto de partida para um esforço planejado de evolução e/ou melhoria contínua da maturidade de software.

Os três instrumentos referem-se, respectivamente a: ➊ ➋ ❸

Auto-avaliação conforme o Modelo SEI Auto-avaliação conforme o Modelo ISO 9000-3 Auto-avaliação conforme as Condições da Empresa Para a Mudança

15.1 - Auto-Avaliação Conforme o Modelo SEI Caracterize sua organização de software, selecionando o nível que mais se aproxima de sua realidade.

Nível A 1.

2.

3.

4.

5.

6.

7.

8.

A empresa opera sem procedimentos formalizados Não são empregados métodos de estimativas de custo,prazo e recursos As ferramentas de desenvolvimento não são integradas com o processo e nem aplicadas uniformemente Não há controles de mudança A metodologia de desenvolvimento não está claramente estabelecida Não são empregadas técnicas de inspeção e teste de sistemas Não há controle quantitativo (estatístico) da qualidade do software É comum os projetos ultrapassarem os custos e prazos planejados Nível B

9.

Todos os projetos produzem e documentam seus planos,incluindo projeçõesdo tamanho do produto, estimativa de recursos,pessoal, prazos e pontos de controle

10.

O processo de planejamento é monitorado com base em padrões e procedimentos aprovados plea área de Garantia da Qualidade

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

Revisões gerenciais periódicas (mensais ou trimestrais) são conduzidas para acompanhar o desempenho do projeto em termos de tamanho, pessoal, cronogramas e pontos de controle Mecanismos são estabelecidos para monitorar e controlar as mudanças nos requerimentos Um sistema de gerência de configuração e de controle de mudança é estabelecido para requerimentos, codificação e resultados de testes Padrões documentados são produzidos para estimativas de tamanho de software, projeção de recursos, prazos e planos de produto Guias de estilo de produto são desenvolvidos para orientar as atividades de projeto e codificação Procedimentos documentados são produzidos para o desenvolvimento e aprovação dos planos do produto, aprovação para mudanças nos requerimentos, projetos ou código, condução de auditorias e revisões gerenciais Os métodos básicos de projeto, codificação e teste de software estão definidos e documentados Métodos padrões são desenvolvidos para estimativa e planejamento de projetos Medições e análises são feitas entre o planejado e o executado Dados históricos são retidos sobre o código, erros de teste etc.

Mecanismos e responsabilidades são estabelecidas para assegurar que os planos sejam produzidos e acompanhados para todos os projetos; os planos são aprovados pelas equipes de implementação; todos os planos são revistos antes de haver comprometimento efetivo; auditorias são conduzidas quando especificadas, controle de mudança é rigorosamente implementado e a Garantia da Qualidade e gerência de configuração de software são efetivamente desempenhadas Procedimentos, métodos e responsabilidades são estabelecidas para assegurar que os desenvolvedores entendam tanto os requerimentos como o ambiente dos usuários da aplicação Meios são estabelecidos para prover o ambiente de desenvolvimento com o conhecimento sobre ferramentas e métodos disponíveis Nível C

24.

25.

26.

27.

28.

29.

Existe política escrita, divulgada e documentada, requerendo que o padrão do processo de desenvolvimento de software seja usado É estabelecido um grupo de engenharia do processo de software Revisões gerenciais periódicas são realizadas para verificar o status dos projetos internos de aperfeiçoamento do processo de software O grupo de engenharia do processo de software lidera as atividades de aperfeiçoamento do processo, bem como assegura a conscientização sobre os métodos empregados Revisões gerenciais periódicas são realizadas para tratar sobre treinamento, inserção de tecnologia, status do processo de software e planos de aperfeiçoamento do processo Mecanismos são estabelecidos para identificar problemas sobre projeto de sistema e software e resolvê-los imediatamente

30.

31.

32.

33.

34.

35.

36.

37.

38.

39.

40.

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

Cursos padrões são oferecidos sobre gerência da qualidade, gerência de profissionais de software, métodos de software e inspeções Um plano de treinamento é produzido, definindo os cursos requeridos para cada função no ambiente de desenvolvimento Os recursos são estimados para cada atividade chave no processo de software Contingências são estabelecidas para todas estimativas conforme a experiência histórica Planos de gerência de risco dos projetos identificam termos técnicos e de negócio, os quais possam afetar o sucesso do projeto O desempenho do projeto é acompanhado e revisado por atividade chave no processo de software Inspeções de projeto e código são monitorados até a resolução dos problemas que surjam O desenvolvimento e documentação dos padrões e métodos do processo são monitorados e revistos As ferramentas e métodos de desenvolvimento de cada projeto são mantidos sob o controle da gerência de configuração de software As definições e padrões do processo para cada projeto são mantidas sob o controle da gerência de configuração de software Procedimentos formais são estabelecidos para a sub-contratação de recursos Mecanismos e recursos são estabelecidos para o acompanhamento do desempenho dos sub-contratados A área de Garantia da Qualidade da empresa monitora a Garantia da Qualidade do sub-contratado Padrões documentados são produzidos para o processo de software como um todo, abrangendo também registros de custos, métodos de teste e relatórios sobre qualidade dos produtos Guias de estilo para desenvolvimento são utilizadas por toda a empresa e para qualquer projeto Procedimentos documentados são estabelecidos para produzir e aprovar padrões de processo e produto As definições do processo são adaptadas, para dinamicamente, atender as contingências de cada projeto Métodos documentados são desenvolvidos para o projeto, codificação, inspeção e teste Métodos são estabelecidos para identificar e relacionar todos os itens referentes ao projeto e codificação, desde os requisitos até o teste Medições são feitas sobre os erros encontrados e os custos incorridos pela atividade do processo Mecanismos e responsabilidades são estabelecidos para assegurar que cada requisito do produto seja testável Mecanismos e responsabilidades são estabelecidos para assegurar a produção de padrões do processo, bem como relatórios de custos Mecanismos são estabelecidos para assegurar que os padrões do processo de software sejam inteiramente revistos e que sua adoção seja aceita pela comunidade técnica da empresa Mecanismos e responsabilidades são estabelecidos para a revisão da eficácia do grupo de engenharia do processo de software

54.

55.

56.

57.

Mecanismos do processo são estabelecidos para assegurar a validação da abordagem do projeto contra as necessidades dos usuários Um plano de inserção de tecnologia é estabelecido O ambiente de desenvolvimento de software é estabelecido e instalado Um conjunto de padrões de ferramentas compatíveis é definida e está disponível Nível D

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

Uma política da empresa é estabelecida, requerendo que cada novo produto ou release seja medida Uma política da empresa é estabelecida, requerendo que todos os projetos estabeleçam planos para aperfeiçoar os métodos padrões A ênfase organizacional é sobre o planejamento e acompanhamento da qualidade Recursos são disponíveis para apoiar a introdução de tecnologia Cada grupo de desenvolvimento principal conduz, periodicamente, um trabalho de avaliação Revisões gerenciais periódicas são realizadas para avaliar o desempenho em termos dos planos de qualidade e ações de melhoria da qualidade Cursos padrões são oferecidos sobre planejamento da qualidade, gerência quantitativa de processo, métodos avançados de desenvolvimento, prototipação Planos de qualidade são produzidos para cada projeto Planos de ação visando a melhoria da qualidade são produzidos sempre quando o projeto não atinge as metas da qualidade O desempenho é medido em função dos planos de qualidade e melhorias As customizações de cada projeto em relação aos padrões do processo são retidas sob o controle da gerência de configuração de software As métricas utilizadas no processo são mantidas sob o controle da gerência de configuração de software Métricas de qualidade dos sub-contratados são estabelecidas e acompanhadas O desempenho da área de Garantia da Qualidade é acompanhado e revisado Padrões documentados são produzidos para inspeções, ferramentas e métodos, planos de qualidade e monitoramento de qualidade por atividade do processo Procedimentos documentados são produzidos para a customização do processo e do ambiente Procedimentos documentados são desenvolvidos para os planos de qualidade, acompanhamento, inspeções e customização do processo e do ambiente Métodos documentados são estabelecidos para prototipação e avaliação quantitativa do projeto Protótipos são desenvolvidos para demonstrar a viabilidade de requisitos críticos antes que entrem no escopo do projeto Medições e análises são feitas sobre os níveis de defeitos nos produtos, eficiência e cobertura das inspeções e testes, distribuição dos erros, produtividade de tarefas e eficácia das ferramentas

78.

79.

80.

81.

82.

Um banco de dados sobre o processo é estabelecido Um banco de dados sobre o processo e o sistema de qualidade são centralmente mantidos e protegidos Mecanismos e responsabilidades são estabelecidas para assegurar a definição e o uso de métricas padrões, a produção e acompanhamento dos planos de qualidade, e a inserção apropriada de novas tecnologias Mecanismos e responsabilidades são definidos para assegurar que os profissionais técnicos dos projetos aprovem e aceitem os planos de qualidade dos produtos e tornem-se pessoalmente comprometidos em mantê-los Apoio à inserção de tecnologias é estabelecida, incluindo apoio para a instalação e uso de ferramentas, assistência à utilização de novos métodos, bem como à customização do ambiente Nível E

83.

84.

85.

86.

87.

88.

89.

90.

91.

92.

93.

94.

95.

96.

97.

98.

99.

Uma política é emitida, requerendo que cada grupo de desenvolvimento demonstre um padrão crescente de produtividade Uma política da empresa requer que cada grupo de desenvolvimento utilize os métodos e ferramentas oficiais estabelecidas O ponto focal da organização é o desenvolvimento, a introdução e o apoio à reutilização de componentes Revisões gerenciais periódicas são realizadas para avaliar o desempenho da produtividade Meios são estabelecidos para assegurar que o processo de software e as ações de melhorias sejam objetivamente avaliadas, reconhecidas e recompensadas Cursos padrões são oferecidos para justificação econômica, projetos avançados, métodos de reutilização e métodos de prevenção de erros Planos de melhoria do processo são produzidos para cada projeto Planos de melhoria de produtividade são produzidos para cada projeto O desempenho é avaliado em função das melhorias no processo e produtividade A reutilização de componentes e suas definições são mantidas sob o controle da gerência da configuração de software Melhorias de processo e produtividade dos sub-contratados são revistas, aprovadas e monitoradas A área de Garantia da Qualidade da empresa monitora as ações de melhoria de processo e de produtividade dos sub-contratados Padrões documentados são produzidos para a mediçào da produtividade de cada tarefa em termos de limites estatísticos Guias documentados e padrões são produzidos para a reutilizaçào de componentes, incluindo padrões de interfaces Procedimentos documentados são desenvolvidos para o planejamento da produtividade, geração de códigos reutilizáveis, customização de componentes reutilizáveis Métodos documentados são desenvolvidos para o projeto de componentes reutilizáveis, análise de prevenção de defeitos e extinção de defeitos Estudos econômicos e técnicos são conduzidos durante o projeto para decidir quando componentes reutilizáveis devem ser empregados

100.

101.

102.

103.

104.

105.

Medições e análises são realizadas sobre eficácia de ferramentas, métodos de prototipação, de reutilização Análise de causas de defeitos são conduzidas Mecanismos e responsabilidades são definidas para acompanhamento de produtividade, integração de tecnologia e acompanhamento da eficácia da reutilização Mecanismos e responsabilidades são estabelecidas para assegurar que os profissionais sejam treinados e capazes de desempenhar prevenção de defeitos e que sejam pessoalmente comprometidos com as melhorias do processo O apoio da tecnologia inclue a análise de cada tarefa para determinar o apoio requerido, os aspectos econômicos deste apoio e a prototipação de ferramentas e métodos potenciais O conjunto de ferramentas é progressivamente aperfeiçoado para incluir o uso de novas tecnologias e métodos

NÍVEL SELECIONADO - ESTÁGIO MAIS ADEQUADO DE SUA REALIDADE A B C D E

15.2 - Auto-Avaliação Conforme o Modelo ISO 9000-3 ELEMENTOS DA NORMA

CHECKLIST

4 Sistema da Qualidade 4.1 Responsabilidade da Administração Existe uma política documentada, definindo os objetivos e o compromisso para com a qualidade?

Esta política é compreendida, implementada e mantida em todos os níveis da organização?

Estão definidas as responsabilidades e autoridades de todo o pessoal que administra, desempenha e verifica atividades que influem na qualidade?

Os requisitos, recursos e pessoal treinado para atividades de verificação estão identificados?

Sim

Nã o

ELEMENTO DA NORMA

CHECKLIST

4 Sistema da Qualidade Ferramentas 4.1 Responsabilidade da Administração O Sistema da Qualidade é analisado criticamente pela Administração em intervalos apropriados?

São mantidos registros destas análises?

O comprador quando da contratação dos serviços designa um representante com autoridade para lidar com os aspectos contratuais?

Revisões conjuntas com o cliente são realizadas a intervalos programados para verificar conformidade do software com os requisitos, verificar resultados e resultados de teste de aceitação?

Os resultados de tais revisões são documentados?

4.2 Sistema da Qualidade Há um Sistema da Qualidade documentado , considerando todo o ciclo de vida, assegurando que a qualidade seja verificada durante o processo ?

O Sistema da Qualidade documentado está efetivamente implementado?

Os elementos e requisitos do Sistema da Qualidade estão claramente documentados numa estrutura lógica coerente?

Para cada projeto de software existe um Plano da Qualidade baseado no Sistema da Qualidade?

Este Plano da Qualidade é entendido e observado pelas pessoas e áreas da organização envolvidas com o projeto?

4.3 Auditorias Internas do Sistema da Qualidade Há auditorias internas da qualidade para verificar a eficácia do Sistema da Qualidade?

As Auditorias são programadas com base na importância das atividades relativas à qualidade?

As Auditorias e ações de acompanhamento são desempenhadas de acordo com procedimentos documentados?

Os resultados das Auditorias são documentados e levados à atenção do pessoal que tem responsabilidade pela área auditada?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

4.4 Ação Corretiva É mantida documentação e procedimentos para: a) investigar as causas de não-conformidade do produto e a ação corretiva necessária para prevenir a repetição? analisar todos os processos, operações de b) trabalho,concessões, registros da qualidade, relatórios de assistência técnica e reclamações do Cliente para detectar e eliminar causas potenciais de serviços não conforme? c) iniciar ações preventivas para tratar dos problemas em um nível correspondente aos riscos encontrados? d) aplicar controles para assegurar que as ações corretivas são realizadas e que as mesmas são efetivas? e) implementar e registrar alterações nos procedimentos resultantes de ações corretivas?

5. Sistema da Qualidade Atividades do Ciclo de Vida 5.1 Geral

-

Os projetos de desenvolvimento de software são organizados de acordo com um roteiro metodológico que represente um modelo de ciclo de vida?

As atividades relacionadas com a qualidade são planejadas e implementadas com relação ao modelo de ciclo de vida usado?

5.2 Revisão de Contrato São estabelecidos e mantidos procedimentos para revisão de contrato e para a coordenação destas atividades?

Quanto aos contratos: a) o escopo do contrato e os requerimentos são definidos e documentados? b) as contingências e riscos possíveis são identificados? c) as informações propietárias são adequadamente protegidas? d) os requerimentos que diferem daqueles na proposta são resolvidos? e) as responsabilidades com sub-contratados estão definidas? f) a terminologia a ser empregada é entendida por ambas as partes?

Sim

Não

ELEMENTO DA NORMA

Sim

CHECKLIST

5.2 Revisão de Contrato Em relação aos itens da qualidade no Contrato: a) estão definidos os critérios de aceitação? b) está definido o tratamento de mudanças nos requisitos do cliente durante o desenvolvimento? c) está definido o tratamento de problemas detectados após a aceitação do produto/serviço, incluindo reclamações e queixas do cliente acerca de itens relacionados com a qualidade? d) as atividades a serem desempenhadas pelo cliente, especialmente às relativas a especificação de requisitos, instalação

e

aceitação estão definidas? e) as facilidades, ferramentas e itens de software a serem entregues ao cliente estão definidas? f) os padrões e procedimentos a serem utilizados estão definidos? g) os requisitos para replicação do software esão definidos?

5.3 Especificação dos Requisitos do Cliente Os requisitos do cliente abrangem itens como desempenho, segurança, confiabilidade e privacidade?

Estes requisitos são claramente definidos de forma a serem validados durante a aceitação do produto?

Há aprovação destes requisitos por parte do cliente antes do desenvolvimento do produto?

Há controle da documentação relativa aos requisitos do cliente?

Todas as interfaces entre o produto de software e outros software ou produtos de hardware são claramente especificados na especificação de requisitos?

Durante o desenvolvimento da especificação dos requisitos: a) há designação de pessoas de ambas as partes para estabelecer a especificação de requisitos do cliente? b) há formas e métodos para aprovação das especificações e para mudanças nas especificações?

Não

ELEMENTO DA NORMA

Sim

CHECKLIST

5.3 Especificação dos Requisitos do Cliente c) o esforço de definição de requisitos é documentado por ambas as partes?

5.4 Planejamento do Desenvolvimento O plano de desenvolvimento contempla: a) a definição do projeto, incluindo a declaração de seus objetivos , bem como referencia o relacionamento com outros projetos da empresa e do Cliente? b) a organização dos recursos do projeto, incluindo a estrutura da equipe, responsabilidades, utilização de sub-contratados, recursos materiais e outros? c) as fases de desenvolvimento? d) o cronograma e calendarização do projeto, as tarefas, recursos e esforço requerido relacionamento entre elas?

para

cada

tarefa

e

qualquer

inter-

e) a identificação dos planos relacionados tais como: plano da qualidade, plano de gerência de configuração, plano de integração, plano de teste?

O plano de desenvolvimento é atualizado na medida em que o projeto avança?

Antes do início de cada fase há uma revisão e aprovação dos produtos da fase anterior?

Há uma metodologia claramente definida para o desenvolvimento do produto?

Nesta metotologia há desenvolvimento a serem executadas?

a

identificação

das

fases

de

Há identificação das entradas para cada fase?

Há identificação das saídas requeridas de cada fase?

Há procedimentos de verificação a serem realizados em cada fase?

Há análise de problemas potenciais associada com as fases de desenvolvimento e com a construção dos requisitos?

Não

ELEMENTO DA NORMA

CHECKLIST

5.4 Planejamento de Desenvolvimento O plano de desenvolvimento estabelece como como os projetos devem ser gerenciados, incluindo a identificação de cronograma de desenvolvimento e implementação, os produtos a serem entregues, o controle do progresso, as responsabilidades organizacionais, os recursos e atribuição de tarefas à equipe do projeto, bem como os interfaces técnicos e organizacionais entre diferentes grupos?

O plano de desenvolvimento identifica as regras, práticas e convenções para o desenvolvimento, as ferramentas e técnicas e a gerência de configuração?

Há revisões de progresso planejadas?

As revisões de progresso são documentadas?

As entradas para cada fase de desenvolvimento são definidas e documentadas?

Cada requisito pode ser verificado quanto a sua consecução?

As saídas requeridas de cada fase de desenvolvimento são definidas e documentadas?

Há um plano para a execução de verificações dos produtos de cada fase de desenvolvimento?

Os resultados das verificações são registrados?

5.5 Planejamento da Qualidade Para o desenvolvimento do projeto é preparado um plano da qualidade específico?

O plano da qualidade contempla: a) objetivos da qualidade expressos em termos mensuráveis? b) critérios de entrada e saída para cada fade de desenvolvimento? c) identificação dos tipos de teste, bem como atividades de verificação e validação a serem desempenhadas? d) planejamento detalhado de teste, atividades de verificação e validação a serem realizadas, definindo cronograma, recursos e autoridade de aprovação e) responsabilidades para revisões e testes, gerência de configuração, controle de mudança,controle de defeitos e ação corretiva?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

5.6 Projeto e Implementação No projeto de desenvolvimento é levado em consideração: a) regras de projeto, definições de interfaces internas? b) metodologia específica tendo em vista o tipo de software que está sendo construído? c) utilização de experiência passada para evitar a ocorrência de problemas similares? d) a construção das especificações de forma que possam ser facilmente testadas e mantidas?

Na implementação é levado em consideração: a) regras de programação, linguagens de programação, convenções de identificação de atributos, tabelas, índices, arquivos ? b) metodologias de implementação?

Há revisões para assegurar que os requisitos estão sendo atingidos e que os métodos de projeto e implementaçào estão sendo empregados?

Estas revisões impedem o prosseguimento do projeto antes que as deficiências sejam efetivamente sanadas?

Há registros documentados de tais revisões?

5.7 Teste e Validação Há plano de testes para o software?

O plano de teste contempla: a) teste de item de software, teste de integração, teste de sistema e teste de aceitação? b) casos de testes, dados de testes e resultados esperados? c) tipos de testes a serem desempenhados, ou seja, funcional, testes de interfaces, testes de desempenho, teste de usabilidade? d) ambiente de teste e ferramentas de teste? e) os critérios pelos quais o término do teste será julgado? f) documentação do usuário? g) o pessoal requerido e requisitos de treinamento?

Durante o teste é levado em consideração: a) o registro dos resultados dos testes?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST b) os responsáveis são notificados para a resolução de problemas? c) partes do software impactadas por qualquer modificação são identificadas e re-testadas? d) a adequabilidade e relevância do teste? e) a documentação e registro das condições do ambiente de hardware e software e da configuração do software que está sendo testado? É feita uma efetiva validação do software antes da entrega para o cliente em termos de sua operação e, quando possível, em condições reais?

Quando o teste sob condições de campo é exigido: a) são especificados as funções a serem testadas? b) são definidas as responsabilidades de ambas as partes na avaliação do teste? c) há a restauração do ambiente do usuário após o teste?

5.8 Aceitação Antes das atividades de aceitação: a) o cliente é auxiliado na determinação de prazo? b) o cliente é auxiliado na determinação dos procedimentos de avaliação? c) o cliente é auxiliado na determinação do ambiente de hardware e software necessários para a avaliação de aceitaçào? d) o cliente é auxiliado na definição dos critérios de aceitação?

5.9 Replicação, Entrega e Instalação No caso de replicação do software: a) é especificado o número de cópias do software? b) é especificado o tipo de meio para cada item de software, incluindo formato e versão? c) é especificado a documentação requerida tais como manuais e guias do usuário? d) é especificado “copyright” e termos de licenciamento? e) é especificado os aspectos relativos a custódia e “back-up” de cópias, incluindo planos de “recovery”?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

5.9 Replicação, Entrega e Instalação f) é especificado a obrigação de reposição de cópias ao cliente?

Há procedimentos para verificar a exatidão das cópias após a sua replicação?

Durante a instalação do software, as responsabilidades de ambas as partes são definidas em termos de: a) cronograma, incluindo fins de semana? b) acesso às instalações do cliente ( físicas, password etc.) ? c) disponibilidade de pessoal especializado? d) acesso aos equipamentos e sistemas do cliente? e) a necessidade de validação de cada instalação do produto?

5.10 Manutenção Há procedimentos para as atividades de manutenção requeridas?

Há um plano de manutenção do software?

O plano de manutenção contempla: a) escopo da manutenção? b) identificação do status inicial do produto? c) organização de suporte? d) registros de manutenção e relatórios? e) atividades de manutenção?

A identificação do status inicial do produto, para fins de manutenção , é definido junto com o cliente e documentado?

As mudanças efetuadas no software em função da manutenção são documentadas e controladas?

Para cada item de software que sofre manutenção: a) Há uma lista de solicitação ou relato de problemas recebido do cliente e o status atual de cada solicitação? b) Há responsáveis para responder às solicitações ou para implementar a ação corretiva apropriada? c) Há prioridades atribuídas às ações corretivas? d) Há o registro das ações corretivas? e) São mantidos dados estatísticos sobre a ocorrência de falhas e atividades de manutenção?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

5.10 Manutenção Os registros das atividades de manutenção são utilizados para a melhoria do produto de software e do próprio sistema da qualidade?

Há procedimentos documentados para incorporar mudanças no produto de software numa abordagem de “release”?

Estes procedimentos incluem: a) regras para determinar onde novas implementações serão realizadas ou incorporadas no produto? b) descrições dos tipos de “releases” dependendo de sua frequência e/ou impacto nas operações do cliente e habilidade para implementar mudanças a qualquer ponto no tempo? c) métodos pelos quais o cliente será comunicado sobre mudanças planejadas no produto? d) métodos para confirmar que as mudanças a serem implementadas não introduzirão outros problemas? e) registros indicando quais mudanças foram implementadas por instalação, para múltiplos produtos?

6 Sistema da Qualidade - Atividades de Suporte 6.1 Gerência da Configuração Há um sistema de gerência de configuração?

Este sistema: a) identifica unicamente as versões de cada item de software? b) identifica as versões de cada item de software que, juntos, constituem uma versão específica de um produto completo? c) identifica o status de construção do produto de software em desenvolvimento ou entregue e instalado? d) controla a atualização simultânea de um item de software específico por mais de uma pessoa? e) provê a coordenação para a atualização de múltiplos produtos em uma ou mais instalações quando requerido? f) identifica e monitora todas ações e mudanças resultantes de uma solicitação de mudança, desde o início até a “release”?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

6.1 Gerência da Configuração Há um plano de gerência da configuração?

Este plano contempla: a) organizações ou áreas envolvidas na gerência da configuração e responsabilidades atribuídas para cada um? b) atividades de gerência da configuração a serem desempenhadas? c) ferramentas de gerência da configuração, técnicas e metodologias a serem utilizadas? d) o estágio que os itens devem ser colocados sob o controle da gerência da configuração?

Há procedimentos para identificar os itens de software durante todas as fases de desenvolvimento, desde a especificação até a replicação e entrega?

Quando requerido por contrato , há procedimentos para o tratamento após a entrega do produto?

Cada item de software tem uma identificação única?

A identificação de cada item de software para cada versão contempla: a) as especificações funcionais e técnicas? b) todas as ferramentas de desenvolvimento que afetam as especificações funcionais e técnicas? c) todos os interfaces com outros itens de software e hardware? d) todos os documentos e arquivos de computador relacionados ao item de software?

Há procedimentos para identificar, documentar, revisar e autorizar qualquer mudança aos itens de software sob a gerência da configuração?

Todas as mudanças nos itens de software seguem estes procedimentos?

Há métodos para notificar as mudanças às partes interessadas e para mostrar a “rastreabilidade” entre mudanças e partes modificadas dos itens de software?

Há procedimentos para registrar gerenciar e relatar sobre o status dos itens de software, sobre solicitaçào de mudanças?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

6.2 Controle da Documentação É mantido procedimentos para controlar todos os documentos relativos ao sistema da qualidade?

Os procedimentos para controle da documentação contemplam: a) a determinação dos documentos sujeito ao controle? b) a aprovação e emissão de procedimentos? c) o controle de mudanças nos documentos?

O controle de documentação é aplicado a: a) documentos que descrevem o sistema da qualidade aplicado ao ciclo de vida do software? b) documentos de planejamento descrevendo a evolução do relacionamento com o cliente? c) documentos de produto incluindo entradas para cada fase de desenvolvimento, saídas de cada fase de desenvolvimento, planos de verificação e validação e respectivos resultados, manuais e documentação de manutenção?

Há procedimentos para assegurar que os documentos e respectivas cópias estejam disponíveis em locais apropriados onde operações essenciais para o efetivo funcionamento do sistema da qualidade são desempenhadas?

Há procedimentos para que documentos obsoletos sejam removidos dos locais de uso?

Há procedimentos para a revisão e aprovação de mudanças nos documentos?

Há controle das versões dos documentos?

Os documentos são re-emitidos após um determinado número de alterações ?

6.3 Registros da Qualidade Há procedimentos para identificação, coleta, indexação, arquivamento, armazenamento, manutenção e disposição de registros da qualidade?

Há procedimento para determinar período de tempo em que os registros devem ser retidos?

Sim

Não

ELEMENTO DA NORMA

CHECKLIST

Sim

Não

6.4 Medição Há utilização de métricas para a medição da qualidade do produto?

As métricas relativas ao produto são coletadas em intervalos regulares?

São identificados os níveis de desempenho com as métricas ?

Com os resultados das medições, e quando há indicação, há tomada de ação corretiva?

São estabelecidas metas de melhoria em função das mediçòes?

Há métricas para a medição da qualidade do processo de desenvolvimento de software?

6.7 Compra Há procedimentos para assegurar que produtos e/ou serviços adquiridos para agregar ao produto estejam em conformidade com os requisitos?

Há registros sobre a qualificação e desempenho de sub-contratados?

Há validação do trabalho de sub-contratados?

6.8 Software Produto Incluso Há procedimentos para a validação , armazenamento, proteção e manutenção de produto de software do cliente ou de terceiros?

6.9 Treinamento Há procedimentos para identificar as necessidades de treinamento do pessoal envolvido com atividades que afetam a qualidade?

São mantidos registros sobre as atividades de treinamento?

15.3 - Verificação das Condições Para a Mudança Apesar destes instrumentos de auto-avaliação, fornecerem subsídios para o “caminho” a percorrer, árduo por sinal, é necessário verificar as condições ambientais da empresa para a mudança. Isto significa verificar se o esforço a ser despendido para evoluir a novas patamares de excelência em software terá chances de ser bem sucedido.

Para tanto, apresentamos um breve “checklist” para você avaliar se sua empresa ou organização de informática reune as condições organizacionais para a mudança.• O “checklist” é composto por 17 itens. Para cada item, dê uma nota, de acordo com a seguinte escala: ⌦ ⌦ ⌦

Alto =3 Médio = 2 Baixo = 1

A nota 3 significa que a organização possue a condição na totalidade; a nota 2 significa que a organização possue parcialmente a condição; a nota 1 significa que a organização não possue a condição.

Se o seu escore ficar entre 41 e 51 a implementação da mudança poderá ser bem sucedida. Se o escore ficar entre 28 e 40, a mudança é possível mas será difícil. Neste caso maior atenção deverá ser destinada as sete primeiras condições. Por fim, se o seu escore ficar entre 17 e 27, a implementação da mudança será praticamente impossível.

CONDIÇÃO PARA A MUDANÇA

ESCORE

PATROCINADOR Há um patrocinador para a mudança, ou seja, a pessoa com poder para auxiliar a equipe de mudança quando encontra resistência; 3 pontos caso o patrocinador se encontra no nível senior da empresa ( o Diretor de Informática/Tecnologia); caso o patrocinador seja de áreas de assessoria dê somente 1 ponto LIDERANÇA Isto significa a liderança do dia-a-dia; a pessoa que estabelece metas, trabalha arduamente para o sucesso do empreendimento e tem os resultados para o negócio bem claro na mente;dê 3 pontos caso a liderança seja desempenhada por alguém de alto nível da organização e que tenha trânsito junto às outras áreas da empresa MOTIVAÇÃO Dê três pontos para um forte senso de urgência transmitido pela alta gerência, o qual é compartilhado pelo resto da empresa e para uma cultura corporativa que enfatiza a melhoria contínua DIREÇÃO A alta gerência acredita que o futuro pode ser diferente do presente? Quão clara é a visão da alta gerência acerca do futuro? A alta gerência pode mobilizar empregados, clientes e fornecedores para a ação? Dê três pontos para respostas positivas a estas questões MEDIÇÕES Três pontos se a empresa já utiliza medidas de desempenho advindas da qualidade total ( tais como taxas de defeitos, marketing timing etc.); dois pontos se algumas medidas existem; se a empresa ou unidade de negócio não tiver medições ou você não sabe do que se trata, atribua somente um ponto CONTEXTO ORGANIZACIONAL Como a mudança pretendida se relaciona com outras que estão ocorrendo na organização? Três pontos se existe uma forte relação, se há uma ligação estratégica ; caso o esforço de mudança é isolado ou se há múltiplos esforços de mudança não ligados estrategicamente pode estar havendo problemas

•

Este “checklist” foi adaptado do artigo “ Rate Your Readiness To Change” de Thomas A. Stewart publicado na revista Fortune de fevereiro de 1994.

CONDIÇÃO PARA A MUDANÇA PROCESSOS/FUNÇÕES As principais mudanças geralmente exigem o “re-projeto” dos processos do negócio, os quais atravessam funções organizacionais; se os executivos não estão conscientes a mudança será dificultada. Dê mais pontos quanto maior for a consciência dos executivos e da organização como um todo no sentido de mudar os processos críticos mesmo sacrificando poder para o bem do grupo BENCHMARKING DOS COMPETIDORES Dê maiores pontos se sua empresa observa continuamente os competidores e compara métodos e processos com os seus; dê um ponto se o conhecimento que sua empresa tem do competidor é primário FOCO NO CLIENTE Quanto mais as pessoas na empresa estão imbuídas de vontade para conhecer cada vez mais o cliente, maior a probabilidade de que a organização concorde com mudanças para servir melhor o cliente. Três pontos se cada um na empresa sabe quem é o seu cliente, conhece suas necessidades; dê menos pontos se este conhecimento fica restrito a pessoal de vendas, executivos da alta administração RECOMPENSAS Mudanças tornam-se mais fáceis se os gerentes e empregados são recompensados para aceitarem riscos, serem inovadores e perseguirem novas soluções; recompensas para equipes são mais aconselháveis do que recompensa pelo desempenho individual; reduza os pontos se sua empresa recompensa a continuidade ao invés da mudança; reduza mais ainda se os empregados acreditam que erros são sempre punidos ESTRUTURA ORGANIZACIONAL A melhor situação é uma organização flexível; dê nota baixa se a sua empresa tem uma estrutura rígida cuja maior mudança ocorreu mais do que cinco anos ou tem feito frequentes reorganizações com pouco sucesso COMUNICAÇÃO Uma empresa adaptar-se-á mais rapidamente a uma mudança caso tiver comunicação que chegue a todos os seus níveis e que seja usada e entendida pelos empregados; caso contrário a mudança será muito difícil HIERARQUIA ORGANIZACIONAL Quanto menores os níveis da hierarquia e quanto menores os “títulos” dos empregados, maior a probabilidade de um esforço de mudança ser bem sucedido; grande número de gerentes de nível médio e de pessoal de assessoria faz com que o processo de tomada de decisão seja mais demorado e tem poder para bloquear a mudança mesmo que de forma passiva EXPERIÊNCIA PASSADA COM MUDANÇAS Dê três pontos se a sua empresa implementou, em um passado recente, mudanças bem sucedidas; dê um ponto se nunca vivenciou uma mudança; dois pontos para mudanças que agregaram um pouco de valor MORAL A mudança é fácil se os empregados gostam do seu trabalho e o nível de responsabilidade individual é alto; sinais de pouca disposição para mudança se o espírito de equipe é baixo, pouco trabalho voluntário extra e desconfiança; observe dois tipos de desconfiança: entre gerência e empregados e entre departamentos INOVAÇÃO Melhor situação: a empresa está sempre experimentando; novas idéias são implementadas com pouco esforço; empregados trabalham através das fronteiras departamentais sem muito problema; maus sinais: muitas aprovações antes que novas idéias sejam tentadas, empregados são desencorajados de trabalhar com colegas de outros departamentos ou divisões

ESCORE

CONDIÇÃO PARA MUDANÇA TOMADA DE DECISÃO Dê três pontos se as decisões são tomadas rapidamente, levando em consideração uma grande variedade de sugestões; é claro onde as decisões são tomadas; dê uma nota baixa se as decisões são demoradas e são tomadas pelos misteriosos “êles” ; há muitos conflitos durante o processo e confusão antes que as decisões sejam anunciadas

ESCORE

Capítulo

16 COLETÂNEA DE ESTATÍSTICAS REFERENTES À SOFTWARE Informações estatísticas que representam a experiência de outras organizações no desenvolvimento de software, fornecem “avisos” importantes para o gerente e desenvolvedores.

As informações que a seguir são expostas podem subsidiar qualquer processo de planejamento do desenvolvimento de software, independente de plataforma e técnicas a serem empregadas.

Probabilidades de Introdução de Defeitos Em Função do Número de Condicionais Em Um Programa 60% 40% 30% 20% 10% 5%

1-10

11-20

21-30

31-50

51-90

>90

Fonte: Furlan  3

Fontes de Erros do Software Fonte dos Erros Requisitos e Especificações Projeto Linguagem e Ambiente Outros

Fonte: Weiss  6

% 11 81 6 2

Inspeção Formal de Software versus Teste ➲ Utilizando a técnica de inspeção formal de software, o prazo de desenvolvimento tem um acréscimo de 10% ➲ Testes de sistemas conseguem detectar somente 50% dos defeitos do software ➲ A técnia de inspeção formal de software detecta até 70% dos defeitos do software ➲ A utilização conjunta da técnica de inspeção formal de software e de testes podem detectar até 90% dos defeitos do software Fonte: AT&T  2

Emprego da Reutilização de Software ➲ Projetos criados primariamente de software reutilizado despendem cerca de 1/4 do tempo e recursos do que novos projetos ➲ Projetos criados de software reutilizado experimentam somente 1/3 da densidade de defeitos daqueles que são novos Fonte: Grady  4

Cobertura de Teste ➲ Testes típicos, sem medição de cobertura, somente conseguem testar cerca de 55% do código; com o controle de cobertura pode testar cerca de 80% Fonte: Grady  4

Distribuição do Esforço do Desenvolvimento

➲ Projetos de software investem, em média, cerca de 18% do esforço total durante a especificação, 19% no “design” , 34% na codificação e 29% durante o teste Fonte: Grady  4

Produtividade Média Na Produção de Código

➲ Um projeto entrega em média, cerca de 350 linhas de código (excluindo comentários) por engenheiro/mês Fonte: Grady  4 

Esforço de Desenvolvimento versus Esforço de Manutenção ➲ Gasta-se cerca de 2 a 3 vezes de esforço em manutenção melhoramento de software do que criando novos

e

Fonte: Grady  4 

Densidade de Defeitos ➲ Para cada 10 defeitos encontrados no teste do software, será encontrado cerca de 1 defeito pós-release Fonte: Grady  4 

Variações no Processo de Software ➲ 85% das causas de variações no processo de software são comuns, enquanto 15% são causas especiais Fonte: Arthur  1

Crescimento do Software Após a Especificação ➲ Entre o término da especificação de um sistema e a sua implementação, cerca de 44% de codigo e 35% de funcionalidade serão adicionados Fonte: Capers Jones  5

Aspectos Relativos à Qualidade ➲ Uma organização reativa despende cerca de 90% do seu tempo na correção dos sintomas de problemas ao invés de atacar as suas causas ➲ Não é incomum encontrar um departamento de informática que não possui programa de qualidade formal, cujos custos de má qualidade representam cerca de 30 a 50% do orçamento anual ➲ Custos de avaliação em empresas que têm programa de qualidade chegam a 25% do custo total do software, enquanto em outras companhias este custo chega a 50% do custo total Fonte: Arthur  1

Módulos Com Erros Crônicos

➲ Cerca de 5% dos módulos de um sistema de porte, recebe em torno de 50% das comunicações de defeitos.

Fonte:Capers Jones  5

Médias Norte-Americanas Emprego de Pessoal Conforme o Tamanho do Sistema em Pontos de Função

Tamanho do Sistema em Pontos de Função 20 40 80 160 320 640 1280 2560 5120 10240

Intervalos de Quantitativo de Pessoal Até 1 Até 1 2 Entre 2 e 4 Entre 4 e 8 Entre 8 e 16 Entre 16 e 32 Entre 32 e 64 Entre 64 e 128 Entre 128 e 254

Variação Percentual Entre Prazos Planejados e Realizados Conforme o Tamanho do Sistema em Pontos de Função Tamanho do Sistema em Pontos de Função 20 40 80 160 320 640 1280 2560 5120 10240

Variação Entre Prazo Realizado versus Planejado Nenhum + 10% + 35% + 40% + 60% + 65% + 90% + 65% + 100% + 114%

Crescimento em Conteúdo Funcional Conforme o Tamanho do Sistema em Pontos de Função

Intervalo de Tamanho de Sistema em Pontos de Função 10 a 80 80 a 640 640 a 5120 5120 a 10240

Intervalos Percentuais de Crescimento Até 10% Entre 10 a 20% Entre 20 a 30% Entre 20 a 40%

Homem-Mês de Esforço Para Novos Projetos de Software Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120 10240

Intervalos de Esforço em Homem/Mês 1 2 Entre 2 e 4 Entre 4 e 8 Entre 8 e 16 Entre 32 e 64 Entre 128 e 256 Entre 512 e 1024 Entre 1024 e 2048 Entre 4096 e 8192 Entre 8192 e 16384

Taxas de Produtividade Para Projetos de Software

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120 10240

Taxa de Produtividade em Pontos de Função Entre 15 e 16 Entre 14 e 15 Entre 13 e 14 Entre 10 e 11 Entre 7 e 8 Entre 6 e 7 Entre 4 e 5 Entre 3 e 4 Entre 2 e 3 Entre 1 e 2 1

Volume Médio de Documentação Gerada em Páginas

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120

Volume Médio da Documentação Gerada Entre 10 e 20 Entre 20 e 40 Entre 40 e 80 Entre 160 e 320 Entre 320 e 640 Entre 1280 e 2560 Entre 2560 e 5120 Entre 5120 e 10240 Entre 20480 e 40960 Entre 40960 e 81920

Risco de Cancelamento de Projetos de Software

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120 10240

Intervalos das Probabilidades de Cancelamento Até 5% Até 5% Entre 5 e 10% 10% Entre 10 e 15% Entre 15 e 20% Entre 20 e 25% Entre 25 e 30% Entre 30 e 35% Entre 35 e 40% Entre 45 e 50%

Expectativa de Vida de Software Após a Entrega

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120

Intervalo de Anos em Produção Antes da Substituição Até 1 Entre 1 e 2 Entre 2 e 3 Entre 3 e 4 Entre 4 e 5 Entre 6 e 7 Entre 8 e9 Entre 10 e 11 Entre 13 e 14 Entre 14 e 15

Volume de Novas Funções Adicionadas Como Melhorias Anualmente

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120

Intervalos de Pontos de Função Adicionados Até 10 Até 10 Entre 10 e 20 Entre 10 e 20 Entre 20 e 40 Entre 40 e 80 Entre 80 e 160 Entre 160 e 320 Entre 320 e 640 Entre 640 e 1280

Taxas de Produtividade Para Projetos de Melhoria

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120

Intervalos de Taxas de Produtividade em Pontos de Função Entre 3 e 4 Entre 5 e 6 Entre 7 e 8 Entre 9 e 10 Entre 8 e 9 Entre 6 e 7 Entre 5 e 6 Entre 3 e 4 Entre 2 e 3 Entre 1 e 2

Taxas de Produtividade Para Projetos de Manutenção

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320

Intervalos de Taxas de Produtividade em Pontos de Função Entre 18 e 20 Entre 14 e 16 Entre 6 e 8 Entre 4 e 6 Entre 2 e 4 Entre 0 e 2

Média de Defeitos Potenciais

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120 10240

Intervalos de Defeitos em Potencial Entre 4 e 8 Entre 16 e 32 Entre 64 e 128 Entre 128 e 256 Entre 256 e 512 Entre 512 e 1024 Entre 1024 e 2048 Entre 2048 e 4096 Entre 4096 e 8192 Entre 8192 e 16384 Entre 16384 e 32768

Eficiência Média na Remoção de Defeitos

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120 10240

Intervalos de Remoção Cumulativa de Defeitos Entre 90 e 95% Entre 90 e 95% Entre 85 e 90% Entre 85 e 90% Entre 80 e 85% Entre 75 e 80% Entre 70 e 75% Entre 65 e 70% Entre 65 e 70% Entre 60 e 65% Entre 60 e 65%

Volumes de Defeitos Entregues aos Usuários

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120

Intervalos de Defeitos Válidos Entregues aos Usuários Até 1 Até 2 Entre 2 e 4 Entre 4 e 8 Entre 8 e 16 Entre 64 e 128 Entre 256 e 512 Entre 1024 e 2048 Entre 4096 e 8192 Acima de 16384

Defeitos Comunicados Pelos Usuários No Primeiro Ano de Uso do Sistema

Tamanho do Sistema em Pontos de Função 10 20 40 80 160 320 640 1280 2560 5120 10240

Intervalos de Defeitos Comunicados Pelos Usuários Até 1 Até 2 Até 2 Entre 2 e 4 Entre 8 e 16 Entre 64 e 128 Entre 256 e 512 Entre 1024 e 2048 Entre 2048 e 4096 Entre 4096 e 8192 Entre 8192 e 16384

Eficiência da Remoção de Erros Conforme Fatores de Projeto Fatores de Projeto 1.Sem inspeção do projeto 2.Sem inspeção de código 3.Sem garantia da qualidade 4.Sem teste formal 1.Com inspeção do projeto 2.Com inspeção de código 3.Com garantia da qualidade 4.Com teste formal

Eficiência da o mais baixo

30

95

Remoção de médio

Erros, % o mais alto

40

50

99

99

Intervalos de Produtividade Em Pontos de Função Conforme Fatores de Projeto

Fatores de Projeto 1.Staff inexperiente 2.Métodos não estruturados 3.Ferramentas comuns 4.Linguagens de baixo nível 1.Staff experiente 2.Métodos estruturados 3.Ferramentas CASE 4.Linguagens de alto nível

Intervalos de o mais baixo

Produtividade médio

PF’s o mais alto

0.25

2.5

5.0

20.0

40.0

100.0

Fonte: Capers Jones  5

Você pode usar estas informações para avaliar o seu processo e avaliar os riscos inerentes ao desenvolvimento. Porém não procure fazer muitas generalizações, pois referem-se a uma realidade diferente da nossa, cujas organizações de software encontram-se em estágios mais evoluídos.

REFERÊNCIAS 1. ARTHUR,Jay Lowel . Improving Software Quality: an insider’s guide to TQM. Wiley & Sons, New York, 1993.

2. EBENAU, R.G. & STRAUSS, S. H. Software Inspection Process. McGraw-Hill, 1994.

3. FURLAN, José Davi. Reengenharia da Informação: do moto à realidade. MAKRON Books, São Paulo, 1994.

4. GRADY, R.B. Practical Software Metrics for Project Management and Process Improvement., Prentice Hall, Englewood Cliffs, New Jersey, 1992.

5. JONES, Capers.Applied Software Measurement. McGraw-Hill,New York,1991.

6. WEISS,D.M. & BASILI,V.R. Evaluating Software Development By Analisys of Changes. IEEE Transactions on Software Engineering, Vol 2, No 2 , feb 1985.

LISTA DE MÉTRICAS QUE APARECEM NESTE LIVRO Capítulo 6 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

Estimativa do Tamanho do Software Estimativa do Prazo do Projeto Com Pontos de Função Estimativa do Esforço do Projeto Com Pontos de Função Custo Estimado do Projeto Com Ponto de Função Estimativa do Número de Instruções Fontes Estimativa de Esforço COCOMO - Básico Estimativa de Prazo COCOMO- Básico Estimativa de Quantitativo de Pessoal COCOMO - Básico Estimativa de Esforço COCOMO Intermediário Estimativa de Quantitativo de Pessoal - COCOMO Intermediário Estimativa de Distribuição de Esforço e Prazo COCOMO Estimativa do Número de Defeitos Pré-Release Estimativa do Número de Defeitos Pós-Release Estimativa do Esforço de Retrabalho Estimativa do Custo de Retrabalho

Capítulo 7 16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

37.

38.

39.

40.

41.

42.

43.

Progresso na Remoção de Defeitos Defeitos Restantes Desvio da Estimativa de Defeitos Composição dos Tipos de Defeitos na Fase Composição de Defeitos Até a Fase Composição das Classes de Defeitos Distribuição de Defeitos Por Módulo do Software Densidade de Defeitos da Inspeção Densidade de Defeitos na Fase Densidade de Defeitos Por Módulo do Software Eficiência da Remoção de Defeitos do Processo de Inspeção Taxa de Exame Por Inspeções Taxa de Preparaçãoa Por Inspeção Tamanho do Material Inspecionado Por Inspeções Análise de Complexidade Falhas Adicionais Esperadas Para Atingir Objetivo de Intensidade Tempo de Execução Adicional Esperado Para Atingimento do Objetivo de Intensidade Progresso na Elaboração de Produtos Acompanhamento Físico do Projeto Estimativa Atualizada do Tamanho do Software Estimativa Atualizada de Prazo Exatidão da Estimativa de Prazo da Fase Estimativa Atualizada de Esforço Estimativa Atualizada de Alocação de Recursos Exatidão da Estimativa de Esforço da Fase Acompanhamento Financeiro do Projeto Estimativa Atualizada do Custo do Projeto Comportamento do Custo de Retrabalho

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

70.

Monitoramento de Mudanças nos Requisitos Origens de Incremento/Mudanças nos Requisitos Falhas Esperadas Para o Software Intensidade Atual de Falhas Estimativa Atualizada do Número de Defeitos Pós-Release Exatidão da Estimativa de Prazo Exatidão da Estimativa de Tamanho do Software Exatidão da Estimativa de Custo Exatidão da Estimativa de Esforço Exatidão da Estimativa de Defeitos Pré-Release Exatidão da Estimativa de Custo de Retrabalho Exatidão da Estimativa de Instruções Fontes Tamanho do Software Entregue Cálculo do Ponto de Função Cálculo do Feature Points Produtividade do Desenvolvimento Custo do Ponto de Função de Desenvolvimento Crescimento Funcional do Software Durante o Desenvolvimento Reutilização do Código Complexidade do Software Custo da Qualidade Distribuição do Esforço Por Fase Distribuição do Custo Por Fase Distribuição de Defeitos Por Fase Densidade de Defeitos do Software Índice de Tecnologia de Desenvolvimento Empregado Índice de Tecnologia de Gestão Aplicado ao Projeto

Capítulo 8 71.

72.

73.

74.

75.

76.

77.

78.

79.

80.

81.

82.

83.

84.

85.

86.

87.

88.

89.

Estimativa do Esforco Anual de Atendimento Estimativa do Número de Profissionais Para o Atendimento Anual Estimativa do Custo do Atendimento Anual Estimativa Esperada de Defeitos do Atendimento Anual Esforço de Retrabalho do Atendimento Anual Custo Esperado do Retrabalho do Atendimento Anual Probabilidade da Ocorrência do Primeiro Evento de Solicitação de Manutenção Corretiva Probabilidade de Que Sejam Recebidos Mais do Que “X” Solicitações de Manutenções Corretivas Probabilidade do Recebimento de Um Número “X” de Solicitações Probabilidade de Tempo de Atendimento - Exemplo 1 Probabilidade de Tempo de Atendimento - Exemplo 2 Probabilidade de Tempo de Atendimento - Exemplo 3 Falhas Esperadas do Software Estimativa do Esforço da Manutenção Adaptativa Estimativa do Prazo da Manutenção Adaptativa Estimativa do Número de Profissionais Necessário Para a Manutenção Adaptativa Estimativa do Custo de Manutenção Adaptativa Estimativa do Número de Defeitos da Manutenção Adaptativa Estimativa de Esforço de Retrabalho da Manutenção Adaptativa

90.

91.

92.

93.

94.

95.

96.

97.

98.

99.

100.

101.

102.

103.

104.

105.

106.

107.

108.

109.

110.

111.

112.

113.

Estimativa do Custo do Retrabalho da Manutenção Adaptativa Estimativa do Tamanho do Projeto de Melhoria Estimativa de Esforço do Projeto de Melhoria Monitoramento do Backlog Tempo Médio de Atendimento das Solicitações Tempo Médio do Backlog Em Aberto Origem das Solicitações Frequência do Tipo de Solicitação Frequência de Solicitações Por Módulo do Software Produtividade da Manutenção Corretiva/Adaptativa Monitoramento da Densidade de Defeitos do Produto Monitoramento da Intensidade de Falhas do Produto Índice de Manutenção do Produto Produtividade de Manutenções Adapatativas e Projetos de Melhoria Custos do Ponto de Função de Manutenção Adaptativa e Projetos de Melhoria Eficiência da Remoção de Defeitos do Processo Verificação da Exatidão das Estimativas de Manutenção Tamanho Atual do Software Crescimento Funcional Relativo do Software Crescimento Funcional Médio do Software Complexidade Atual do Software Custo da Qualidade do Atendimento ao Produto Índice de Tecnologia de Manutenção/Melhoria Empregado Índice de Tecnologia de Gestão Empregado

Capítulo 9 114.

115.

116.

117.

118.

119.

120.

121.

122.

Verificação de Projetos/Produtos Com Desvio do Padrão da Qualidade Verificação dos Projetos Com Desvio da Estimativa de Prazos Verificação dos Tempos de Atendimento às Manutenções Corretivas Verificação dos Desvios de Custos Estimados Análise da Capacidade de Atendimento Análise da Tendência da Produtividade do Desenvolvimento Análise de Impacto Análise de Atributos Modelagem do Ambiente de Desenvolvimento