PROGRAMA DE MELHORIA SUSTENTADA DA QUALIDADE DE
SOFTWARE: O CASO DO TRIBUNAL SUPERIOR DO
TRABALHO
CLÁUDIO FONTES FEIJÓ
PROGRAMA DE MELHORIA SUSTENTADA DA QUALIDADE DE
SOFTWARE: O CASO DO TRIBUNAL SUPERIOR DO
TRABALHO
Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da
Tecnologia da Informação da
Universidade Católica de Brasília, como requisito parcial para a obtenção do título de Mestre.
Orientador: Prof. Dr. Walcélio Louzada Melo
Ficha elaborada pela Seção de Processos Técnicos do SIBI F297p Feijó, Cláudio Fontes
Programa de melhoria sustentada da qualidade de software: o caso do Tribunal Superior do Trabalho / Cláudio Fontes Feijó. -- Brasília, 2002.
100 f.
Orientador: Walcélio Louzada Melo
Dissertação (mestrado) – Universidade Católica de Brasília, 2002.
1. Tribunal Superior do Trabalho - Software – Controle de qualidade 2. Software – Desenvolvimento. 3. Gerenciamento de configurações software. 4. Software – Manutenção. I. Melo, Walcélio Louzada, orient.
II. Título.
SUPERIOR DO TRABALHO
Cláudio Fontes Feijó
Dissertação defendida em 16 de dezembro de 2002 e aprovada pela banca examinadora constituída pelos professores:
______________________________________________ Prof. Walcélio Louzada Martins Melo – orientador
______________________________________ Profa. Maria Elenita Menezes Nascimento
____________________________ Profa. Káthia Marçal Oliveira
Agradeço ao Professor orientador Walcélio Melo pela valiosa contribuição que deu a esse trabalho.
Agradeço à professora Káthia Marçal e ao professor Nicolas Anquetil, pelas sugestões que deram o acabamento final à dissertação.
Agradeço a Deus, por me dar a vida, a saúde e a oportunidade de evoluir e aprender. Agradeço a minha mãe, que com muita fé, transmite a todos força, determinação e otimismo. Ao meu pai, que mesmo não estando entre nós, se faz presente por todo o tempo. As minhas irmãs, Fabiana e Fernanda por sempre terem acreditado na realização desse trabalho.
Agradeço ainda a todos os meus colegas do Tribunal Superior do Trabalho, em especial ao Heron, que me incentivou e apoiou durante toda essa caminhada. Aos colegas Antônio Borges (o Toninho), Lúcio, Lívio, Luiz Fernando e Olavo, pelas preciosas contribuições em reuniões de qualidade.
Ao Luiz Carlos Lírio (meu caro...), pelas palavras de apoio e incentivo, sempre impregnadas de sentimento fraterno.
Resumo vi
Abstract vii
Lista de Figuras xii
Lista de Tabelas xiv
CAPÍTULO 1 – Introdução
1.1Contextualização 1
1.2Motivação 2
1.3Objetivos 3
1.4Organização da dissertação 3
CAPÍTULO 2 – Qualidade de Software
2.1Modelos e sistemas de garantia da qualidade 4
2.2Conceitos de qualidade de software 5
2.3Normas de certificação da qualidade do produto de software 6 2.4Modelos de avaliação da qualidade do processo de software 7
2.5Melhoria do processo de software 12
2.5.1IDEAL 13
2.5.2QIP 13
2.5.3O Roadmap AINSI 15
2.6Mensuração de software 17
2.7Abordagens de mensuração 18
2.8Implantação de melhoria do processo de software 19
2.8.1Avaliações e determinação da capacidade 19
2.8.2Institucionalização e melhoria contínua 20
2.8.3Programa de mensuração 21
2.8.4Experiências práticas em programas de melhoria 22
2.8.5Experiências de melhoria no setor público 23
2.9Considerações finais 24
CAPÍTULO 3 – Gestão de Configuração de Software
3.1Introdução 25
3.2Histórico 25
3.3Motivação para a GCS 26
3.4Qualidade de software e gerência de configuração 27
3.5Plano de Gerência de Configuração 28
3.6Implementação de um processo de GCS 30
3.7Esquema de solução para gerência de configuração 30
3.8Sistema de Gerência de Configuração 31
3.9Atividades de Gerência de Configuração de Software 32
3.10 Modelos de Gerência de Configuração de Software 35
4.2.2Sistema de Informações Judiciárias (SIJ) 40
4.3Estratégia global de implementação 42
4.4Levantamento de informações para o programa de melhoria 43 4.4.1Conhecimento sobre a Unidade Produtora de Software 44 4.4.2Análise de programas anteriores de qualidade de software 46
4.4.3Programa de Qualidade Total do TST 47
4.4.4Análise de defeitos relatados por usuários 47
4.4.5Avaliação da maturidade no desenvolvimento de software 50 4.4.6Avaliação de processos consoante o Nível 2 do CMM 51 4.4.7Pesquisa estruturada dos principais problemas e dificuldades 52 4.4.8Opiniões das equipes de engenharia de software sobre os problemas da
unidade produtora de software
54
4.5Escolha do processo ideal para melhoria 55
4.6Implantação do AINSI 55
4.6.1Definição da equipe de melhoria de processos 56
4.6.2Modelagem descritiva dos processos de software atuais do TST 56
4.6.3Análise qualitativa 58
4.6.4Definição do plano de ação 58
4.7Considerações finais 60
CAPÍTULO 5 – Resultados e discussão
5.1Novos processos 61
5.2Plano de Gerência de Configuração de Software (PGCS) 69
5.3Programa de mensuração Goal/Question/Metric 76
5.3.1Etapa de planejamento 76
5.3.2Etapa de Definição 77
5.3.3Coleta de dados 80
5.3.4Ferramentas de apoio ao programa de mensuração 81
5.3.5Interpretação 81
5.4Lições aprendidas 86
5.5Considerações finais 88
CAPÍTULO 6 – Conclusão
6.1Visão geral do trabalho realizado 89
6.2Trabalhos futuros 90
6.3Contribuições 91
6.4Considerações finais 92
Referências Bibliográficas 93
2.1. Relacionamento entre padrões e normas de qualidade 4 2.2. Processos de ciclo de vida do software, segundo a ISO/IEC 12207 10 2.3. Arquitetura ISO para avaliação de processos de software 11 2.4. Ciclo de aprendizagem do Paradigma da Melhoria da Qualidade (QIP) 14
2.5. Propósitos de aplicação da mensuração 17
2.6. Avaliações de processos de software 20
3.1. Distribuição de consumo de ferramentas de GCS 26
3.2. Esquema genérico da solução de GCS 31
3.3. Visões do sistema de gerência de configuração 31
3.4. Exemplo do esquema de uma baseline 33
3.5. Processo de pedido de mudança 33
3.6. Modelo operacional Checkout/Checkin 36
3.7. Estrutura do modelo composição 37
3.8. Seleção de um componente da versão 37
4.1. Estrutura organizacional da UPS do TST 40
4.2. Elementos da estratégia global de implementação 42
4.3. Experiência em software dos servidores da UPS 44
4.4. Distribuição das responsabilidades dos servidores na UPS 45 4.5. Distribuição percentual de atividades de engenharia de software 45
4.6. Satisfação com o SIJ 46
4.7. Satisfação com o atendimento 46
4.8. Detalhe da obtenção de causas de defeitos no SIJ. 48
4.9. Defeitos relativos a Requisitos 48
4.10. Defeitos relativos à GCS 48
4.11. Defeitos relativos a hardware 49
4.12. Defeitos relativos a dados inconsistentes 49
4.13. Causas de falhas relatadas por usuários do SIJ 49
4.14. Análise de dados por Pareto (Histograma classificado) 50
4.15. Avaliação da ACP – GR 50
4.16. Avaliação da ACP – GCS 50
4.17. Avaliação da ACP – CI 51
4.18. Avaliação da ACP – GS 51
4.19. Avaliação de processos pela metodologia SPICE 51
4.20. Estágio de aparecimento de erros 52
4.21. Distribuição de erros e falhas 52
4.22. Prováveis causas dos erros 52
4.23. Distribuição da severidade de erros 52
4.24. Distribuição da manutenção atual e desejada 53
4.25. Distribuição atual e desejada do esforço em atividades de ES 53 4.26. Diagrama de atividades do processo existente antes das ações de melhoria 57
5.7. Arquitetura de integração dos controles 68
5.8. Objetivo do Plano de GCS 70
5.9. Políticas e procedimentos – Responsabilidades do PGCS 71 5.10. Relacionamento entre os ambientes de atuação do novo processo de GCS 72 5.11. Relatório de Histórico de Eventos de um item de configuração 75
5.12. Meta GQM formalizada (G1) 77
5.13. Meta GQM formalizada (G2) 77
5.14. Questões e hipóteses iniciais do Plano GQM 78
5.15. Algumas métricas iniciais do Plano GQM 79
5.16. Capacidade de atendimento a pedidos de manutenção 82
5.17. Tempo médio de permanência nas filas 82
5.18. Classificação dos pedidos de manutenção 83
5.19. Erro médio percentual nas estimativas 84
2.1. Perfil de maturidade das organizações 22
2.2. Programa de Qualidade Total ou similar 23
2.3. Distribuição do tempo em relação às atividades desempenhadas 24 3.1. Necessidades pessoais relativas à Gerência de Configuração 32
4.1. Processos recebidos e solucionados no TST 41
4.2. Resultado do alcance de ACPs do nível 2 de maturidade 52 4.3. Percentual de incremento de produtividade das equipes de ES 54
5.1. Matriz de relacionamento entre metas e questões 79
Este capítulo insere esse trabalho no contexto da qualidade de software, fazendo referência ao movimento atual de busca da melhoria dos processos de software face aos problemas enfrentados pela área de engenharia de software. Apresenta a situação de programas de melhoria da qualidade de software no contexto brasileiro, fazendo ainda a exposição dos motivos que levaram ao desenvolvimento desse projeto. Finalmente, descreve os objetivos propostos e apresenta a estrutura de capítulos da dissertação.
1.1
Contextualização
O grande desafio das organizações que produzem e implementam soluções de software é gerenciar a complexidade dos sistemas atualmente demandados, simultaneamente com as rápidas mudanças nas regras de negócio. Essa complexidade e alterações freqüentes provocam elevado risco ao desenvolvimento e implantação de soluções de software [BROWN, 2000].
Por outro lado, vários problemas afligem a área de software desde a sua criação, entre eles, os relacionados ao processo de desenvolvimento como: alto custo, dificuldade de manutenção, e uma disparidade entre as necessidades dos usuários e os produtos desenvolvidos [PRESSMAN, 2000; DEMARCO, 1993; BOEHM, 1976]. Pressman os
caracteriza como uma “aflição crônica”, e não uma crise pontual. Para administrá-los, a comunidade de engenharia de software, ao longo dos últimos trinta anos, vem estudando e implementando práticas sistemáticas de desenvolvimento de software.
Nesse cenário, parte do trabalho dos pesquisadores envolvidos com a engenharia de software tem sido definir modelos que possibilitem melhor descrever, analisar, compreender e julgar o processo de desenvolvimento software. A existência de tais modelos é apontada como um dos primeiros passos em direção ao gerenciamento e à melhoria do processo de software [KELLNER, 1989].
É importante sinalizar que qualidade do processo de software é tão importante quanto a qualidade do produto. Nota-se, por exemplo, que a partir da década de 90 houve grande preocupação com a melhoria do processo de software. Surgiram padrões importantes como as normas ISO 9000-3 [ISO 9003-3, 1997] e a ISO 12207 [ISO/IEC 12207, 1995], o modelo CMM (Capability Maturity Model)[PAULK et al.,1993] e o SPICE (Software Process Improvement and Capability dEtermination)[ISO/IEC 15504-1, 1998]. Entre outras definições, esses modelos e padrões sugerem que melhorando o processo de software, pode-se melhorar a qualidade dos produtos [PFLEEGER, 1998].
Não obstante todos esses esforços de modelagem, padronização e melhoria, há muito a ser feito em termos da melhoria da qualidade em software. No Brasil, por exemplo, das empresas que conhecem as normas de qualidade de produtos de software, apenas 6% utilizam a norma ISO 12119 [NBR/ISO 12119, 1998] e 9,5% a norma ISO 9126 [PBQS, 1999]. Para as normas de processo de software, o cenário não é diferente, o modelo CMM, das que o conhecem, apenas 9% o utilizam e o SPICE apenas 3,4% [PBQS, 1999].
de mercado. O aumento crescente da complexidade dos produtos de software também favorece esse movimento. Entretanto, no setor público, os investimentos em programas dessa natureza são raros, e quando são criados, geralmente são conduzidos por empresas de consultoria externa, face à expressiva terceirização desse segmento no contexto brasileiro.
Nessa perspectiva, independente se o segmento é público ou privado, os programas de melhoria da qualidade de software devem se mostrar sustentáveis, pois não podem ser concebidos com data certa para terminar. Cabe aos patrocinadores e técnicos envolvidos nessas atividades disseminarem uma cultura da qualidade que seja fundada no entendimento, análise e mensuração do processo. Dessa forma, acredita-se que isso possa favorecer a construção de soluções contínuas e progressivas de melhoria de processos de software.
1.2
Motivação
Face ao desafio de aumentar a produtividade e a qualidade reduzindo custos, urge a necessidade de se melhorar os processos de desenvolvimento de software, principalmente nas organizações públicas, que contam com orçamentos cada vez mais reduzidos.
Por outro lado, é necessário que se insira as instituições públicas no contexto dos novos métodos e tecnologias disponíveis, traçando um paralelo com a iniciativa privada, concebendo-se as semelhanças existentes entre: cliente e cidadão, lucro e melhor utilização de recursos públicos.
Ademais, a necessidade de uma certificação por uma norma internacional de qualidade, não é requisito apenas de competitividade para o setor privado. Esse tipo de diferencial pode estimular a competição entre órgãos públicos, fazendo com que a população, ao final, tenha as suas expectativas superadas em relação aos serviços públicos prestados.
A informática, no contexto do Tribunal Superior do Trabalho (TST), faz parte de uma estratégia traçada pela presidência como meio para atingir, de forma mais eficiente, a excelência da prestação jurisdicional.
O ambiente de produção de software desse órgão compõe-se exclusivamente de servidores de carreira, não havendo serviços terceirizados. Nessa perspectiva, pode-se obter um elevado grau de compromisso para iniciativas de melhoria da qualidade de software.
Mais ainda, há vontade, por parte dos funcionários da unidade produtora de software, de entregar software de melhor qualidade e reduzir o tempo destinado à manutenção em prol de uma atuação direcionada ao desenvolvimento de novos produtos.
O aumento da precisão de cronogramas para entrega desses produtos melhora a imagem da área em relação aos usuários, aumentando a sua credibilidade e reforçando a sua importância no sentido da superação das expectativas dos clientes internos e externos.
1.3
Objetivos
Geral
Criar um ambiente de melhoria contínua e progressiva de processos de engenharia de software no Tribunal Superior do Trabalho.
Específicos
Diagnosticar o nível de maturidade da organização, no que tange aos aspectos relacionados aos processos de software.
Caracterizar de maneira específica os pontos fortes e as deficiências da unidade produtora de software do TST.
Definir um processo para promover ações de melhoria utilizando-se para tal um método para melhoria de processo.
Estabelecer um programa de mensuração.
Implantar um projeto piloto visando validar o processo de melhoria de software. Coletar dados que permitam definir continuamente ações de melhoria.
1.4
Organização da dissertação
Este capítulo trata dos aspectos relevantes da qualidade de software que serviram de embasamento teórico para esse trabalho. Apresenta o conceito de qualidade de software e descreve um panorama dos principais modelos de referência, normas e certificações. Faz uma revisão de modelos de avaliação e melhoria de processo, bem como das metodologias de mensuração de software. É feita uma descrição dos pontos relevantes para a implantação de um programa de melhoria da qualidade de software. Por fim, são apresentados alguns dados relativos à maturidade e às políticas de qualidade existentes no contexto brasileiro.
2.1
Modelos e sistemas de garantia da qualidade
Nos anos 90 a comunidade de processos de software cresceu com a importância do software industrial [HUMPHREY, 1989]. Muitos padrões, incluindo referências a software foram criados para ajudar o controle da qualidade e produção. Hoje existe grande quantidade de padrões, abordagens e aplicações (Figura 2.1).
Figura 2.1. Relacionamento entre padrões e normas de qualidade [SHEARD, 1997].
Para tanto, organizações de todos os tipos e tamanhos buscam a implementação e operação de sistemas de gestão da qualidade eficazes.
Schmauch [SCHMAUCH, 1994] afirma que a série de padrões ISO 9000 [ISO 9000, 2000] para sistemas de qualidade é construída na premissa de que se a produção e a administração são feitas corretamente, então o produto ou serviço final será concluído a contento.
Atualmente, muitas instituições preocupam-se em criar normas para permitir a correta avaliação da qualidade tanto de produtos quanto de processos de engenharia de software. Entretanto, os certificados mais valiosos são aqueles que certificam o processo de produção de um produto e não aqueles que simplesmente certificam o produto. É comum encontrar empresas que perseguem os dois tipos de padrão de qualidade.
Nesse contexto, todo esse aparato utilizado por indústrias e organizações que pretendem melhorar a visibilidade de seus produtos e aumentar a fatia de mercado conquistada também é aplicável ao software. A idéia de que fazer software é diferente e que não se aplicam os conceitos de engenharia e qualidade total é equivocada. Por exemplo, o QIP [BASILI, et al., 1994a], que é a base do NASA SEL Quality Improvement, é fundamentado pelas premissas da Qualidade Total, entretanto, é específico para software.
Em suma, idéias originárias de diversos domínios, com alguma adaptação, permitem também que a qualidade do software produzido possa ser continuamente avaliada, medida, controlada e finalmente melhorada. Assim é importante que se tenha um correto entendimento do que seja a qualidade de software.
2.2
Conceitos de qualidade de software
Não se deve pensar em qualidade como sinônimo de perfeição. Trata-se de algo factível, relativo, substancialmente dinâmico e evolutivo, adaptando-se às subpartes dos objetivos a serem atingidos. Considerá-la como algo absoluto e definitivo seria um contra-senso que acabaria por dificultar os esforços para produzi-la.
Nessa direção qualidade é um conceito complexo, porque possui diversos significados para várias pessoas, em contextos particulares. Portanto, não é comum haver medidas simples de qualidade aceitáveis por todos. Para predizer ou melhorar a qualidade de software numa organização, deve-se definir as características de qualidade, para então se decidir como serão as medidas [KITCHENHAM et al., 1996].
Contudo, de maneira geral, pode-se relacionar alguns aspectos diretamente relacionados com a qualidade de software:
A diminuição dos erros nos projetos de software;
A importância em satisfazer a qualidade, mediante os custos e prazos dos projetos;
A demonstração da maturidade e competência no desenvolvimento de software;
A demonstração ou certificação da qualidade de produtos que estejam em conformidade com as normas ou modelos de qualidade;
A satisfação dos usuários, e o atendimento as suas necessidades na execução de tarefas.
ambas as fases, devem ser utilizados parâmetros objetivos que fundamentem julgamentos e forneçam argumentos para avaliações posteriores [HERBERT & PRICE, 1995].
Como se percebe, o desenvolvimento de software envolve metas, processos e ambientes diferentes. Contudo, ainda faltam modelos e experiências tecnológicas no domínio de software. A efetividade das tecnologias e os ambientes de software são ao mesmo tempo evolucionários e experimentais. Produtos e projetos são sempre diferentes em alguns aspectos, pois são desenvolvidos por seres humanos e para eles.
Nesse contexto, torna-se difícil normalizar o processo de qualidade no desenvolvimento de software, pois a qualidade desses produtos varia consoante as necessidades e requisitos dos projetos, considerando ainda as características do usuário final. Com efeito, pode-se dizer que a qualidade de software deve ser discutida também durante as fases de desenvolvimento, manutenção, teste e uso do produto.
Os sistemas modernos de qualidade dão ênfase ao processo de software, que nada mais é do que o conjunto de tarefas que conduzem à “materialização” do produto de software. Esses sistemas avaliam os procedimentos, os métodos, as ferramentas e os equipamentos utilizados para transformar matéria prima em produto [BASILI & CALDIERA, 1993]. Contudo, o foco no processo não é suficiente para garantir a qualidade dos produtos, pois o processo se dá antes da interação com o usuário. Assim, aspectos ergonômicos do software devem ser igualmente avaliados, pois elevarão o conceito de qualidade para a dimensão do usuário.
É possível relacionar alguns problemas pertinentes ao desenvolvimento de software que podem influenciar no processo de avaliação da qualidade, por exemplo:
As estimativas de prazos e custos são imprecisas em função da imaturidade das organizações em usar modelos e técnicas de produtividade e acompanhar a execução de projetos;
O custo de manutenção é quarenta por cento maior do que o de desenvolvimento [BROOKS, 1995];
Os projetos de software são difíceis de planejar e controlar; O software é continuamente modificado;
O contexto tecnológico dos projetos se modifica rapidamente.
Enfim, existe uma quantidade considerável de problemas que podem afetar a qualidade do software. Por outro lado, é fundamental que se avalie a qualidade do produto com vistas a alcançar um padrão de excelência aceitável, não obstante a existência de vários problemas intrínsecos. Para tanto, é recomendável que se alinhe esses produtos a uma norma internacional de qualidade.
Nesse contexto, para que a qualidade de um produto de software possa ser corretamente avaliada, faz se necessário identificar um modelo que permita organizar os atributos de software de forma a facilitar a análise da conformidade dele com os seus requisitos.
2.3
Normas de certificação da qualidade do produto de software
A norma ISO/IEC 9126 (NBR 13596) - Avaliação da qualidade de produtos de software ao longo do desenvolvimento, permite a avaliação da qualidade de um produto de software durante a fase de projeto e implementação e tem como objetivo identificar possíveis alterações que possam levar a uma melhoria da qualidade e diminuição de custos.
Bazzana e colaboradores [BAZZANA et al., 1993] consideram essa norma um padrão para a modelagem da qualidade de software, pois, em uma pesquisa realizada em países da Comunidade Européia, 70% dos entrevistados já tinham ao menos ouvido falar dela.
Contudo, apesar da relevância da ISO/IEC 9126 há dificuldades em adequar sua aplicabilidade na avaliação prática de produtos de software [TSUKUMO et al., 1996], pois as características de qualidade que ela determina não são diretamente mensuráveis [KITCHENHAM et al., 1996].
A norma ISO/IEC 14598 – Avaliação de produtos de software, engloba a visão geral do produto, o planejamento e o gerenciamento, o processo para equipe de desenvolvimento, o processo para adquirentes, o processo para avaliadores e os módulos de avaliação. Deve ser utilizada em conjunto com a série ISO/IEC 9126 descrita anteriormente.
Por fim, a norma ISO/IEC 12119 (NBR 12119) – Pacotes de software – Teste e requisitos de qualidade, estabelece os requisitos de qualidade para pacotes apresentando instruções de como avaliá-los.
Observa-se então que para a obtenção da qualidade desejada em produtos de software é fundamental a existência de modelos e normas que viabilizem a avaliação da sua qualidade face aos seus requisitos. Contudo, a qualidade de produtos de software está fortemente relacionada à qualidade do seu processo de desenvolvimento [FUGGETTA, 2000]. Nessa perspectiva, as organizações que conseguirem harmonizar e evoluir os seus processos de software poderão obter produtos de melhor qualidade.
2.4
Modelos de avaliação da qualidade do processo de software
Quando se deseja um produto de software de alta qualidade, deve-se assegurar que cada uma de suas partes constituintes também tenha qualidade [HUMPHREY, 1995]. Portanto, os resultados intermediários do processo de produção devem ser imediatamente examinados após sua conclusão, procurando garantir que erros e inadequações no produto sejam detectados o mais cedo possível, pois a qualidade final do produto é uma função de todas as fases anteriores do seu ciclo de desenvolvimento.
Nessa direção, a modelagem do processo de software, bem como a sua avaliação e melhoria contínua podem contribuir para a qualidade do produto final. Contudo, para se obter sucesso na definição e melhoria de processos de software é exigido que os aspectos relativos às características da organização, da equipe técnica e do domínio da aplicação sejam considerados. Acredita-se que tudo isso tenha impacto direto na qualidade e produtividade do processo e afete a qualidade do produto final.
Para avaliar a qualidade, com referência aos processos de software, alguns modelos e normas foram desenvolvidos, como por exemplo, o CMM – Capability Maturity Model, o Trillium, ISO 12207, BOOTSTRAP e a norma ISO 15504 (Projeto SPICE) [ISO/IEC 15504-1, 1998].
processos como entidades estáticas, não os relacionando entre si, nem considerando seus fluxos de atividades.
Esses modelos podem ser divididos em dois grupos, baseado na sua arquitetura: o primeiro grupo, consiste do CMM v1.1 e do Trillium 3.0. pois abordam os processos pela perspectiva da maturidade, agrupando-os e definindo níveis de maturidade. O segundo grupo, consiste da ISO 12207, Bootstrap e modelo de referência SPICE que manipulam a arquitetura de processo e o nível de maturidade em duas dimensões distintas – a de processo e a de capacitação. A seguir é feita uma síntese de cada um desses modelos citados.
O modelo CMM
Desde o início da década passada, o CMM vem sendo implantado em muitas organizações com o objetivo de padronizar e melhorar os processos de desenvolvimento de software. O princípio fundamental desse modelo é que a qualidade do produto de software é alcançada por meio da melhoria da qualidade de seus processos [SANDERS et al., 1994].
Baseado nas idéias originais de Humphrey [HUMPHREY, 1989] e Radice [RADICE et al., 1985], o SW-CMM v1.1 define 5 níveis de capacidade de processo e um conjunto de áreas chaves de processos associadas a cada nível, descrevendo um caminho de evolução que começa por um processo não documentado e imaturo (nível 1) até chegar a um maduro, disciplinado e otimizado (nível 5) [PAULK et al., 1993]. Tal modelo engloba aspectos do planejamento, engenharia, e gerência de desenvolvimento e manutenção de software.
Uma avaliação CMM é fortemente estruturada e baseia-se em equipe, documentos e entrevistas que são realizadas com o propósito de melhoria do processo ou determinação da sua capacidade [MASTERS & BOTHWELL, 1995; BYERNES & PHILLIPS, 1996; DUNAWAY & MASTER, 1996]. Entre as avaliações CMM pode ser feito um monitoramento informal da capacidade do processo [WHITNEY et al. 1994]. A mensuração é considerada fundamental para atingir cada área chave de processo. Nos níveis quatro e cinco a mensuração serve de instrumento para alcançar uma maior capacidade através do entendimento quantitativo, controlado e otimizado do processo de software.
Os cinco níveis são estruturados em ordem crescente de maturidade. Quando a organização se encontra em um certo nível, deve seguir atividades determinadas pelo modelo, para atingir o nível seguinte [HUMPHREY, 1991]:
Nível 1 ou inicial: As organizações não possuem um ambiente estável para o desenvolvimento e a manutenção de software, ficando na dependência exclusiva da habilidade e eficácia de seu pessoal técnico;
Nível 2 ou repetitivo: A instituição já possui projetos cujos processos são gerenciados, medidos, documentados, tendo sua equipe devidamente treinada;
Nível 3 ou definido: Há uma retroalimentação contínua do aprendizado dos processos utilizados na empresa, havendo, para isto, uma biblioteca de processos padrões que podem ser escolhidos durante a fase de planejamento;
Nível 4 ou gerenciado: São estabelecidas métricas mais estritas para a identificação de pontos críticos e oportunidades de melhoria;
Nível 5 ou otimizado: A organização se encontra em uma melhoria contínua de seus processos.
atividades de execução, (v) medidas e análise, e (vi) verificação da implementação [SAIEDIAN et al., 1995].
Conforme estudos do SEI/CMU, uma empresa de software que alcance certificação ISO 9001 atende a todos os requisitos para ser classificada no nível 2 do CMM, mesmo que tenha alcançado alguns dos requisitos de níveis superiores [WEBER et al., 1997].
O CMM possui quatro critérios para determinar se há compromissos e habilidade para a garantia da qualidade [JONES, 1995]:
Existe pessoal designado para uma unidade organizacional, responsável pela garantia da qualidade?
Há recursos financeiros (e outros) suficientes e disponíveis para a realização do trabalho desse pessoal?
As pessoas responsáveis pela qualidade têm sido treinadas, de tal forma que estejam conscientes do que é esperado delas e de como realizarão as suas tarefas?
O grupo de garantia da qualidade é tido como pessoal de alto nível, que está satisfeito com o que faz?
O CMM tem sido criticado por alguns pesquisadores por não ter uma base teórica formal e ser fundamentado na experiência de um grupo de pessoas. Bach [BACH, 1994], por exemplo, argumenta que o CMM é uma mistificação do processo evolutivo e não uma representação legítima do processo de software, podendo colapsar o potencial competitivo da organização.
Contudo, é inegável o sucesso do SW-CMM, pois essa iniciativa levou à criação de uma série de outros CMMs: O SE-CMM (System Enginnering CMM), o SQ-CMM (Software Acquisition CMM) e o P-CMM (People CMM), que mede a capacidade da maturidade dos processos de gestão de recursos humanos.
A evolução desse modelo continua, atualmente tem se canalizado esforços para harmonizar todos esses CMMs sob uma única arquitetura, o CMMI [CMMI, 2000]. Esse novo modelo, além de incorporar as melhorias propostas e aprendidas há mais de uma década de uso do modelo SW-CMM, é equiparado à norma ISO 15504 em termos estruturais.
Por outro lado, as críticas continuam. Pierce [PIERCE, 2000] afirma que esse novo modelo integrador é muito grande e complexo, em razão de possuir 437 práticas, 8 áreas chaves de processos no nível 2 e onze no nível 3.
Trillium
O Trillium [BELL, 1994], é derivado do modelo CMM e de outros modelos para a avaliação de organizações.
O objetivo do Trillium é prover um método para o início e a condução de um programa de melhoramento contínuo da qualidade de processos. O projeto Trillium é orientado às telecomunicações, e foi desenvolvido sob a perspectiva do cliente visando à concepção de produtos em conformidade com normas ISO.
Esse modelo especifica uma área de processo –“3: Process” – que especifica práticas e atividades para o processo de engenharia de software tal como o CMM.
ISO/IEC 12207 – Processos de ciclo de vida de software
desenvolvimento, operação e manutenção de produtos de software. Essa especificação estabelece uma arquitetura de alto nível para o ciclo de vida do software que abrange desde a concepção até a sua descontinuação.
Tal arquitetura baseia-se em processos-chaves e nos seus inter-relacionamentos, seguindo dois princípios básicos:
Modularidade: Os processos têm alta coesão e baixo acoplamento, ou seja, todas as partes de um processo são fortemente relacionadas e o número de interfaces entre os processos é mantido ao mínimo;
Responsabilidade: Cada processo é de responsabilidade de uma “parte envolvida”, que pode ser uma organização ou parte dela. As partes envolvidas podem ser da mesma organização ou de organizações distintas.
Essa norma busca auxiliar as organizações na definição de seus processos de software oferecendo um guia para definição das atividades e tarefas a serem desempenhadas durante as principais etapas que envolvem a construção de um produto de software. A norma agrupa os processos de software em três grandes classes de acordo com a sua natureza – processos fundamentais, processos de apoio e processos organizacionais. Cada processo é definido em termos de suas próprias atividades, e cada atividade é adicionalmente definida em termos de suas tarefas (Figura 2.2).
Figura 2.2. Processos de ciclo de vida do software, segundo a ISO/IEC 12207.
Como se percebe, cada processo inserido nestas classes compreende um conjunto de atividades que, por sua vez, se dividem em um conjunto de tarefas para sua realização. Contudo, a norma não especifica detalhes de como implementar ou executar estas tarefas e atividades. Também não determina um modelo de ciclo de vida ou método de desenvolvimento de software. Assim, esta norma deve ser ajustada à luz do processo de adaptação, de acordo com a organização, seus projetos e metodologias de desenvolvimento.
Bootstrap
recomendações sugeridas pela norma ISO 9000 e a ESA (European Space Agency). Foi feita uma extensão destes modelos de avaliação de qualidade de forma a melhor responder ao contexto europeu.
A metodologia dispõe de um guia para inspecionar os processos de desenvolvimento de software, instrumentos para determinar a capacidade e maturidade organizacional, especificações para a melhoria de processos de desenvolvimento e até para um programa de formação profissional. Esta metodologia tem o suporte de ferramentas tecnológicas para computador e uma base de dados européia que é constantemente atualizada. Assim, provê um meio efetivo de comparar, em termos de maturidade e capacidade, as empresas avaliadas por essa metodologia.
O SPICE(Software Process Improvement and Capability dEtermination)
Em junho de 1991, a International Standards Group for Software Engeneering aprovou um estudo na área de gestão de processos para investigar necessidades de requisitos para normalização na gerência de processo de software. Essa iniciativa, levou a ISO/IEC a aprovar em 1993 um novo grupo de trabalho, denominado WG10, a partir do qual se organizou o projeto SPICE (Software Process Improvement and Capability dEtermination).
Esse estudo foi realizado pelo Comitê técnico ISO JTC1, Subcomitê SC7 que tinha a finalidade de fazer com que a norma se adequasse à ISO 12207 e provesse a unificação de propostas anteriores como a do CMM, Trillium e Bootstrap. Com efeito, a ISO 15504 especificou uma arquitetura para avaliação de processos com duplo objetivo: melhorar os processos e, determinar a capacidade deles em uma organização (semântica bidimensional).
No que tange à melhoria, utilizou-se a definição de processos e práticas que podem ser implementados para estabelecer e aprimorar a capacidade de aquisição, desenvolvimento, manutenção, operação e suporte de software. Quanto ao aspecto da avaliação da capacidade, definiu-se que a organização deve fixar objetivos e o contexto da avaliação, bem como os modelos, métodos de avaliação e os requisitos desejados.
Estas práticas são organizadas por meio de uma arquitetura que combina duas perspectivas: uma funcional (análoga à perspectiva da norma ISO/IEC 12207), compreendendo quais os processos que devem existir numa organização, e outra de capacitação (análoga a do CMM), que avalia o nível de capacidade de cada um destes processos (Figura 2.3).
O uso da norma permite ainda que as organizações possam identificar a existência ou não de um processo, bem como quantificar a capacitação de processos existentes, traçando caminhos para a melhoria.
Dentre os benefícios esperados pelo SPICE, destacam-se:
Os projetistas de software poderão selecionar melhor a organização que desenvolverá seu produto, por meio da avaliação da capacidade dos processos dos fornecedores, minimizando os atrasos e reduzindo os riscos do produto não atender seus propósitos;
Os fornecedores de software economizarão recursos, pois poderão submeter seus processos a um único esquema de avaliação;
Os projetistas de software terão uma ferramenta que, reunida às melhores práticas, possibilitará iniciar e manter um programa contínuo de melhoria de processos compreendido e reconhecido pelos clientes;
Os gestores terão a garantia que o processo de desenvolvimento de software estará alinhado e apoiado pelas necessidades da organização.
O SPICE ainda inclui um modelo de referência dividido em 5 grandes categorias de processos que serve de base para o processo de avaliação:
1. Processo Cliente-fornecedor (CUS): Essa categoria avalia os processos que influenciam diretamente os produtos e serviços de software na relação cliente fornecedor;
2. Processo Engenharia (ENG): Processos que especificam, implementam ou mantém um sistema ou um produto de software e a sua documentação;
3. Processo Suporte (SUP): Esta categoria avalia processos que podem ser utilizados por qualquer outro processo da norma;
4. Processo Gestão (MAN): Esta categoria avalia processos que contém práticas de natureza genérica e que podem ser usados por quem produza projetos ou processos dentro do ciclo de vida de software;
5. Processo Organização (ORG): Essa categoria avalia processos que estabelecem os objetivos de negócios da organização.
No que tange à capacitação, define seis níveis que permitem quantificar a adequação da organização à norma: Nível 0 (Incompleto), Nível 1 (Executado), Nível 2 (Gerenciado), Nível 3 (Estabelecido), Nível 4 (Previsível) e Nível 5 (Otimizado).
O impacto da elaboração do SPICE tem contribuído para a melhoria das práticas de software no mundo [ROUT, 2000]. O Brasil tem aumentado significativamente sua participação nesse esforço internacional, sendo hoje um representante significativo [ROCHA et al., 2001].
Nessa perspectiva, as organizações produtoras de software vêm implantando programas de melhoria da qualidade, buscando primeiramente entender os seus processos. A partir daí, estabelecem um programa de mensuração e por meio de avaliações procuram melhorá-los continuamente.
2.5
Melhoria do processo de software
utilizado pelas equipes, como avaliar sua qualidade corrente e como manter continuamente e progressivamente esta melhoria.
Os modelos e normas de referência são os instrumentos principais para dar sustentação a estas iniciativas. Com base nas práticas sugeridas pelos modelos, as organizações podem definir seus próprios processos e efetivamente implantá-los. Servem ainda como referência para avaliação da qualidade dos processos existentes e também como diretriz para melhoria contínua.
Existem muitas metodologias para melhoria, mas em geral elas se dividem em duas correntes:
Abordagens top-down: CMM, SPICE e Bootstrap [KUVAJA & BICEGO, 1994]. Esses modelos se baseiam em avaliações e benchmarks.
Abordagens bottom-up: GQM [BASILI et al., 1994], QIP [BASILI et al., 1994a], AMI [PULFORD et al., 1995] e mais recentemente o IDEAL [MCFEELEY, 1996], que aplicam principalmente a mensuração como fundamento de melhoria.
2.5.1
IDEAL
O modelo IDEAL [MCFEELEY, 1996] foi originalmente concebido como um modelo de ciclo de vida para melhoria de processo de software baseado no SW-CMM. Por essa razão o modelo utiliza os conceitos de melhoria de processos. Reconhecendo que o modelo tinha grande potencial para a área de processos, a SEI revisou o IDEAL para que fosse aplicável de maneira mais ampla e genérica em abordagens de melhoria de processos. Com efeito, [GREMBA & MYERS, 1997] publicaram essa revisão que se transformou na versão v1.1 do referido modelo. Esse foi o primeiro passo na direção da sua ampliação e generalização.
O modelo IDEAL (Initiating – Diagnosing – Establishing – Acting – Leveraging) propõe cinco fases para a realização de um ciclo de melhoria. Ao fim de cada ciclo, atinge-se um estágio de capacitação. Cada ciclo repete os passos do modelo. Possivelmente, a motivação e o patrocínio estarão bem estabelecidos a partir do segundo ciclo.
O IDEAL provê uma abordagem útil e de fácil compreensão para a melhoria contínua porque define passos concretos para estabelecer e implantar um programa de melhoria. Por meio da definição de fases, atividades e princípios, esse modelo vem trazendo benefícios em muitos esforços de melhoria de processos. Ele tem uma disciplina rígida de melhoria, enfatizando a gerência do programa e estabelecendo fundamentos para uma estratégia de melhoria de longo prazo.
A iniciativa de fazer o IDEAL como um modelo genérico vem permitindo que ele possa ser utilizado também para a implementação de programas de melhoria de tecnologia e até de capacitação de pessoas.
Embora esse modelo seja recente, ele guarda muita semelhança com o QIP.
2.5.2
QIP
Space Flight, o Centro HP e CRIM no Canadá, têm adotado essa metodologia para melhorar seus processos de software.
O enfoque deste paradigma é entender primeiro os processos existentes nas organizações para depois determinar a causa dos problemas mais significativos. Assim, uma caracterização do ambiente apropriada e sem ambigüidades é um pré-requisito para a aplicação correta do QIP.
O QIP está diretamente relacionado ao ciclo Plan/Do/Check/Act (PDCA) de Shewart-Deming [DEMING, 1986] largamente utilizado na indústria para implementação de planos de gerenciamento da qualidade.
A abordagem PDCA é articulada em quatro fases:
1. Planejar (Plan): Definir os objetivos e metas do aperfeiçoamento da qualidade, determinar métodos para alcançar esses objetivos e preparar um plano de implementação;
2. Executar (Do): Executar a implementação do plano e a coleta de dados;
3. Verificar (Check): Verificar a melhoria do desempenho utilizando os dados coletados dos processos, e tomar ações corretivas necessárias;
4. Agir (Act): Atuar no sentido de padronizar as melhorias e incorporá-las ao processo.
O QIP possui seis fases fortemente relacionadas ao ciclo PDCA. Essas etapas começam caracterizando o ambiente e terminam armazenando a experiência adquirida. Abaixo está representada a estrutura global do ciclo QIP (Figura 2.4). A seguir, estão detalhadas as fases desse modelo.
Figura 2.4. Ciclo de aprendizagem do Paradigma da Melhoria da Qualidade (QIP).
1. Caracterizar e entender: Conhecer o ambiente com base nos dados e modelos disponíveis na instituição. Estabelecer os fundamentos dos processos existentes na organização e analisá-los criticamente;
2. Definir metas: Com base na caracterização inicial e nas capacidades estratégicas da organização, definir por meio de objetivos quantificáveis o que seriam projetos bem sucedidos, avaliando o desempenho e melhoria da organização. As exceções aceitáveis são definidas com base nos fundamentos estabelecidos no passo de caracterização;
4. Executar: Executar os processos provendo o retorno dos dados que estão sendo coletados, com vistas a mensurar o alcance dos objetivos;
5. Analisar: Ao final de cada projeto específico, analisar os dados e informações acumuladas para avaliar as práticas correntes, identificar problemas, registrar achados, e fazer recomendações para melhoria de projetos futuros;
6. Empacotar: Consolidar a experiência adquirida em forma de refinamento do modelo praticado ou mesmo pela adoção de novos modelos e, ainda, por meio de outras formas de estrutura de conhecimento alcançadas em processos anteriores, armazená-las em uma base de experiências tornando-as disponíveis para uso futuro.
A abordagem GQM - Goal/Question/Metric é o mecanismo usado pelo Quality Improvement Paradigm para definir e avaliar um conjunto de objetivos operacionais usando métricas. Essa abordagem representa uma sistemática de ajuste e integração de objetivos a modelos de processos e a necessidades específicas de um projeto ou organização.
2.5.3
O
Roadmap
AINSI
O AINSI também é um método indutivo de melhoria de processo de software. Tal como o QIP é uma abordagem do tipo bottom-up para a melhoria prática de processos e produtos de software, podendo ser visto como o exemplo mais geral do Paradigma de Melhoria de Qualidade (QIP).
O AINSI difere das abordagens Top-down, (as quais pretendem fornecer um quadro de trabalho ideal para melhoria de processos, por exemplo, SEI e CMM), porque confia em uma interpretação mais detalhada das fontes disponíveis e interdependentes de informações sobre a organização de software.
Esse método também é organizado em fases, cada uma das quais especificando passos concretos na direção da melhoria do processo de software.
Fases do AINSI
1. Montar uma equipe de melhoria de processo
A primeira e mais crítica atividade consiste em adquirir o compromisso da administração para com a melhoria de processo de software. Uma das razões principais pelas quais os programas de melhoria de processo fracassam é que a administração não proveu os recursos adequados para fazer acontecer. É o caso de muitas organizações cujo negócio principal não é o desenvolvimento de software, por não considerar que o software seja importante são relutantes em investir em melhoria de processo de software.
2. Modelar o processo existente
úteis para entender o modo como as coisas funcionam na organização e para comunicar esta compreensão.
Nessa etapa é fundamental considerar a forma de coleta das informações. É preciso formalizar o processo indicando o que coletar e qual o nível de detalhe apropriado para a modelagem.
3. Conduzir a análise qualitativa
A meta nesta fase é identificar as causas e os mecanismos internos que acarretam problemas graves e de risco elevado para a qualidade dos produtos entregues ou para a eficiência do processo de desenvolvimento. A análise descrita no item anterior está fornecendo o contexto no qual o analista pode inquirir sobre os problemas. Um modelo de processo bem definido ajudará a diferenciar hipóteses do funcionamento real que apresenta algum tipo de problema.
4. Definir e montar um plano de ação
Uma vez que o processo esteja implantado e suas principais deficiências e potencialidades estejam compreendidas, um plano de ação deve ser definido. O plano de ação é definido como: “Uma resposta escrita formal, para a (processo) avaliação, é o mapa para melhoria". O plano de ação é extremamente importante por várias razões. Primeiro, é exigido para adquirir um orçamento satisfatório para as próximas fases (avaliação de soluções, mudanças do processo). Segundo, é crucial para transmitir a informação correta à administração e desenvolvedores sobre a importância e dificuldade do que vai ser alcançado. Isto é particularmente importante, já que duas fontes comuns de fracassos para programas de melhoria são, entre outras, a falta de fundos/recursos adequados e de compromisso da administração sênior.
Um outro ponto importante é que interdependências entre as tarefas do plano de ação devem ser cuidadosamente estudadas. O impacto em menosprezar os esforços de algumas tarefas pode criar danos significativos à pertinência do plano de ação. É muito freqüente, por exemplo, existirem planos de ação baseados em uma compreensão muito superficial dos processos, ou de inspeções introduzidas sem a adequada coleta de dados.
5. Estabelecer um programa de mensuração
É necessário considerar para um programa de mensuração alguns aspectos importantes relacionados à metodologia de mensuração, de coleta, treinamento e mudança de cultura.
à meta, o programa pode fracassar em virtude das medições se distanciarem, ou ainda não servirem para atingir objetivos globais.
Outro ponto fundamental é que sejam apropriados, em termos de cultura organizacional, o formato e os procedimentos de coleta das métricas. Não se deve perder o foco do modo de trabalho das equipes de engenharia de software e a necessidade de se racionalizar as tarefas. Por exemplo, a utilização de muitos formulários de preenchimento manual pode desestimular as equipes em função do tempo gasto para tal atividade. Obviamente que isso ao final prejudicará não só a mensuração como também o programa de melhoria como um todo.
6. Executar um projeto piloto
Idealmente, um projeto piloto deve ser iniciado para avaliar as novas práticas e/ou ferramentas que foram selecionadas. Essa avaliação no contexto da organização é importante, pois existe pouca evidência empírica sobre os benefícios trazidos por novas e antigas tecnologias de engenharia de software;
7. Mudar o processo e a organização
Este é o momento em que a tecnologia é transferida para o resto da organização. Lições aprendidas no piloto devem ser usadas para modelar a tecnologia e seus materiais de treinamento. Os procedimentos de coleta de dados também podem ser ajustados considerando a bagagem de experiência obtida em outras ações de melhoria e com o próprio projeto piloto.
Independente da abordagem de melhoria, a mensuração exerce papel fundamental para o incremento da qualidade do processo e do produto de software. Por outro lado, a mensuração também provê significado para identificação de metas de melhoria. Aplicando-se mensuração a uma parte específica do processo, pode-se mais facilmente identificar problemas e definir novas ações evolutivas.
2.6
Mensuração de software
Mensuração é o processo pelo qual números ou símbolos são designados como atributos de entidades do mundo real com o intuito de descrevê-las de acordo com regras claramente definidas. É considerada uma atividade fundamental para qualquer disciplina de engenharia, e para a engenharia de software não é diferente.
Fenton e Pfleeger [FENTON & PFLEEGER, 1997] definiram mensuração de software como um processo contínuo de definir, coletar e analisar dados de um produto ou processo de desenvolvimento de software com o objetivo de entendê-los, visando a otimização e um maior controle. A interpretação desses dados provê a informação que pode ser utilizada para três diferentes propósitos (Figura 2.5).
Figura 2.5. Propósitos de aplicação da mensuração.
Em primeiro lugar, os dados provêem visibilidade do processo de desenvolvimento atual e das características dos produtos de software. Essa visibilidade é necessária para reduzir a complexidade e incrementar o entendimento do processo e do produto. Entender significa determinar as diferentes variáveis que existem durante a execução do processo.
Uma vez que um entendimento básico tenha sido estabelecido (as variáveis são conhecidas), os dados coletados e analisados podem ser utilizados para controlar o processo e os produtos por meio da definição de ações preventivas e corretivas. Isso significa que os relacionamentos entre as variáveis do processo têm de estar determinados. Uma vez que esses relacionamentos são conhecidos eles podem ser usados para controlar o processo. Ademais, baseando-se em análises, os dados de mensuração coletados podem ser usados para avaliar processos, atuando como indicador de problemas do processo de desenvolvimento de onde ações de melhoria podem ser identificadas.
Um relevante modelo de mensuração foi feito por Basili, Rombach e outros, conhecido por GQM (Goal/Question/Metric) tal representação serve como base para a maioria dos métodos de implantação de programa de mensuração desenvolvidos por especialistas da área. Tal modelo propõe que a medição dos processos e produtos de software seja orientada a metas. A definição do processo segue três passos: Definir metas específicas para as necessidades de acordo com o propósito, perspectiva e ambiente; Refinar as metas em questões quantificáveis que se relacionam com as metas definidas, e; Obter as métricas e os dados a serem coletados para responder tais questões. A análise e interpretação desses dados são feitas de maneira inversa, ou seja, bottom-up.
Esse método tanto suporta a identificação das métricas úteis e relevantes, como permite a análise e interpretação dos dados coletados.
2.7
Abordagens de mensuração
Paradigma GQM (Goal/Question/Metric)
desenvolvido para uso genérico, mas atende especialmente áreas relacionadas a melhoramento. Esse método consiste de três etapas [HYATT, 1997]:
Gerar um conjunto de metas (alvos): baseando-se nas necessidades da organização, determina-se o que se quer melhorar e, então, definem-se alvos em termos de propósitos, perspectivas e ambientes, usando-se modelos genéricos:
i) Propósito: manuseia (caracteriza, avalia, prediz, etc.) o objeto (processo, produto, modelo, métrica, etc.), com o propósito de entender (estimar, gerenciar, melhorar, etc.) esse objeto;
ii)Perspectiva: examina custo; correção; defeitos; mudanças; métricas de produto; confiabilidade, sob o ponto de vista do desenvolvedor, gerente, cliente, etc;
iii)Ambiente: consiste em fatores (de processo, pessoas, problemas, etc.) e métodos, ferramentas, restrições entre outros.
Derivar um conjunto de questões: as questões quantificam os alvos como sendo possíveis, requerendo a interpretação de termos nebulosos no contexto do ambiente de desenvolvimento. As questões são classificadas como sendo relacionadas a produtos ou processos e fornecem feedback pela perspectiva da qualidade;
Desenvolver um conjunto de métricas: essas métricas fornecem as informações necessárias para responder a cada questão. As métricas podem ser objetivas e subjetivas e possuem guias de interpretação, isto é, um valor que indique se o produto é de alta qualidade. Geralmente, uma questão não é respondida simplesmente por uma métrica, mas por uma combinação de métricas. Uma vez definidos os alvos, derivadas as questões, e desenvolvidas as métricas, são criadas matrizes para relacionar metas, questões e métricas.
Uma vez que os objetivos foram definidos, as questões derivadas e as métricas desenvolvidas, deve-se criar matrizes para relacioná-los. A primeira relaciona objetivos e questões e a segunda, questões e métricas. Isto permitirá aos desenvolvedores identificar métricas que se relacionam com várias questões e garantir que para cada objetivo existem mais de uma questão e mais de uma métrica. Estas matrizes permitem também, identificar relacionamentos fracos (que são relacionados apenas uma vez) que não possuem boa relação custo/benefício para produzi-los.
Modelo PMS
O PSM - Practical Software Measurement, é um modelo para a mensuração de projetos de software criado em 1994, sob o apoio do Department of Defense (DoD).
Essa abordagem foi usada como base para a elaboração da Process Area Measurement and Analysis do CMMI – o modelo integrado considerado a evolução do CMM. Essa técnica foi formalizada pela norma ISO 15939 – Software Engineering – Software Measurement Process Framework [ISO/IEC 15939, 2002].
Toda essa teoria e esforço prático em se medir um produto ou processo de software vem ao encontro da busca por um produto de software de melhor qualidade. Nesse contexto, a mensuração é instrumento indispensável para a implantação de programas de melhoria da qualidade de software.
2.8
Implantação de melhoria do processo de software
Para a instalação de um programa de melhoria da qualidade de software, faz se necessário conscientizar a equipe de que o processo não busca identificar culpados ou avaliar a produtividade visando aplicar punições. A principal meta é enfrentar os problemas existentes, em benefício de todos. Para tal, devem ser avaliados aspectos como, a estratégia geral da empresa; planos de expansão; recursos disponíveis, de forma a poder efetivamente estabelecer condições favoráveis para o alcance dos objetivos.
Um programa de melhoria da qualidade leva ao estabelecimento de um sistema de qualidade que deve envolver também questões técnicas e culturais, igualmente importantes. O aspecto técnico envolve o desenvolvimento de padrões e procedimentos para implementar a qualidade em todas as atividades. O aspecto cultural está diretamente relacionado com a aceitação da qualidade por todos os indivíduos da organização.
Para o sucesso na implementação desses programas é importante que se crie uma estrutura em que a melhoria contínua seja possível. Melhorar processos de software requer tempo e monitoramento constante da evolução do processo. Para tanto, um programa de melhoria contínua de processos de software deve ser construído sob um programa de mensuração.
Tão importante quanto a infra-estrutura de mensuração está a necessidade de se conhecer fielmente as deficiências e potencialidades da organização. As fases de entendimento dos processos de software, e de avaliação da maturidade do ambiente de software da organização não devem ser negligenciadas.
2.8.1
Avaliações e determinação da capacidade
As estratégias para se melhorar a qualidade de processos de software envolvem compreender o estado atual de uma organização em relação as suas práticas e gerência de desenvolvimento. Esta compreensão permite que sejam identificados os pontos do processo que precisam ser melhorados, as práticas que necessitam ser incluídas, bem como quais já funcionam trazendo benefícios para a qualidade do processo. A partir daí, um plano de ação pode ser definido, priorizando as necessidades de melhoria, guiando as mudanças e introduzindo novas práticas no processo.
Para auxiliar a avaliação e análise do estado atual dos processos de uma organização e identificar pontos potenciais de melhoria, novamente os modelos de qualidade são tomados como referência. Os modelos podem ser utilizados para se comparar o estado atual do processo e das práticas de uma empresa com o ideal de qualidade almejado. Esta comparação ou avaliação do processo serve como base para se traçar planos de melhoria.
As avaliações de processos de software oferecem um guia para onde seguir e uma forma de obter o posicionamento da organização em relação as suas necessidades de melhoria de processos. Essas avaliações também podem ser utilizadas para priorizar ações de melhoria de processos. Os resultados destas avaliações, juntamente com as diretrizes fornecidas pelas práticas do modelo, são utilizados pelo grupo de qualidade para planejar a estratégia de melhoria de processos da organização.
Avaliações também oferecem recursos para caracterizar a prática dos processos correntes da organização em termos da capacitação dos processos selecionados (determinação de capacitação). As análises de seus resultados, à luz das necessidades de negócio da organização, identificam pontos positivos, negativos e os riscos do processo.
Além disso, permite determinar se os processos estão efetivamente atingindo seus objetivos e identificar as causas de baixa qualidade ou de custos elevados, oferecendo mecanismos para priorizar as necessidades de melhoria. O relacionamento entre avaliações, determinação de capacitação e melhoria de processos pode ser visualizado na Figura 2.6.
Figura 2.6. Avaliações de processos de software [ISO/IEC 15504-1, 1998].
2.8.2
Institucionalização e melhoria contínua
Os modelos são usados como referência para avaliação da qualidade de processos e para a determinação de pontos para sua melhoria. Contudo, a melhoria contínua de processos de software exige a aplicação de abordagens para sua condução de forma disciplinada.
A maioria das abordagens para melhoria de processos se baseia nos modelos de referência (CMM, SPICE, BOOTSTRAP, TRILLIUM) e utilizam estratégias top-down para sua realização. Isto significa dizer que partem do que consideram como melhores práticas (definidas pelos modelos de referência) e tentam moldar a melhoria a partir destes modelos [BRIAND, EL EMAN & MELO, 1999].
Estas abordagens consideram que processos são como software: devem ser entendidos, especificados e projetados para uso efetivo. A especificação e o projeto se baseiam nos padrões de qualidade de processos (modelos de capacitação) que determinam o que se deve esperar do processo do ponto de vista de qualidade [THOMAS & McGARRY, 1994].
O ideal exeqüível é uma fusão dessas duas abordagens, fazendo com que o processo de melhoria seja construído tomando-se como base as práticas sugeridas pelos principais modelos, introduzindo adaptações decorrentes das características e necessidades intrínsecas à organização e seus projetos de desenvolvimento.
2.8.3
Programa de mensuração
A implementação de um programa de melhoria contínua será possível se houver a implantação simultânea de um programa de mensuração. Ora, a melhoria somente poderá ser corretamente avaliada e o progresso constatado se métricas propiciarem a coleta de dados úteis a análise e interpretação de resultados.
Contudo, a maneira como um programa de métricas é desenvolvido pode determinar seu sucesso ou fracasso. Inicialmente, deve-se investigar as ferramentas disponíveis e adquirir/construir outras, para que a coleta de dados de métricas seja feita de forma automatizada, preferencialmente. A coleta de dados deve ser monitorada, para que não se incorra na tentativa de colher dados em demasia, dificultando o seu uso, e tornando a própria coleta inviável [ROSENBERG et al., 1996].
Além de subsidiar a melhoria contínua, um programa de métricas deverá viabilizar estimativas, a identificação de novas ações de melhoria e o completo monitoramento do ambiente, no que tange à qualidade e produtividade da organização. No entanto, muitas organizações não aceitam de imediato esses conceitos para a implementação de um programa de métricas, porque [MÖLLER, 1993]:
i) Consideram que as métricas podem restringir o processo criativo; ii) Geram trabalho adicional;
iii) Os benefícios a serem alcançados não são bem elucidados;
iv) Existem receios de que seja um meio para medir a própria organização; v) Há dificuldades em admitir que a melhoria é necessária.
Há dois grandes componentes de um programa de métricas de qualidade: medida da satisfação do usuário e medida de defeitos. Por razões sociológicas, os programas de métricas são geralmente estabelecidos em seqüência, como uma tentativa de medir todos os fatores simultaneamente. A seqüência de medição abaixo tem sido utilizada com sucesso [JONES, 1997]:
i) Medidas operacionais: envolvem principalmente as medidas de uso do computador, tempo ocioso de máquina e tempo de resposta;
ii) Medidas do projeto atual: acompanham o projeto em desenvolvimento; iii) Medidas de biblioteca: referem-se à produção de relatórios de ocorrência; iv) Medidas da satisfação do usuário: reportam-se a entrevistas com os usuários;
v) Medidas do projeto completo: medem o projeto final;
vi) Medidas de fatores imprecisos: referem-se a dados sem muita precisão; vii) Medidas de defeitos: mensuram os defeitos do software;
viii)Medidas demográficas: arrolam os recursos humanos, enquadrando-os em classes de habilidades relevantes para a organização.
![Figura 2.6. Avaliações de processos de software [ISO/IEC 15504-1, 1998].](https://thumb-eu.123doks.com/thumbv2/123dok_br/18219786.340003/35.892.204.686.475.686/figura-avaliações-de-processos-de-software-iso-iec.webp)
![Tabela 2.1. Perfil de maturidade das organizações [fonte: SEI, 2002].](https://thumb-eu.123doks.com/thumbv2/123dok_br/18219786.340003/37.892.149.747.952.1129/tabela-perfil-de-maturidade-das-organizações-fonte-sei.webp)
