Baixe qualidade em software e outras Notas de estudo em PDF para Sistemas de Informação, somente na Docsity!
Qualidade de Software
José Barreto Júnior
O que é qualidade? Existem diversas definições. Algumas pessoas que tentaram uma definição simples chegaram a frases como:
- Qualidade é estar em conformidade com os requisitos dos clientes
- Qualidade é antecipar e satisfazer os desejos dos clientes
- Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito
Segundo a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade é:
A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas
Nota-se que esta definição formal exige alguns complementos, principalmente para definir o que são as entidades, as necessidades explícitas e as necessidades implícitas. A entidade é o produto do qual estamos falando, que pode ser um bem ou um serviço. As necessidades explícitas são as próprias condições e objetivos propostos pelo produtor. As necessidades implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações éticas, as questões de segurança e outras visões subjetivas.
Por exemplo, a qualidade de um prato de comida (a entidade, o produto) está relacionada com a satisfação de necessidades (requisitos) tais como: sabor, aparência, temperatura, rapidez no serviço, preço, higiene, valor nutricional, etc... Para avaliar a qualidade de um produto, você deve fazer uma lista destas necessidades e analisar cada uma destas necessidades.
Certificação de Qualidade
Um aspecto interessante da qualidade é que não basta que ela exista. Ela deve ser reconhecida pelo cliente. Por causa disso, é necessário que exista algum tipo de certificação oficial, emitida com base em um padrão. Você provavelmente já conhece alguns certificados mais comuns:
- O selo do SIF de inspeção da carne
- O selo da ABIC nos pacotes de café
- O certificado da Secretaria de Saúde para restaurantes (classe "A" são os melhores)
- A classificação em estrelas dos hotéis (hotéis com cinco estrelas são ótimos)
- Os certificados de qualidade da série ISO-
Você já deve ter ouvido muitas propagandas de empresas falando de sua certificação ISO- 9000. Isto nada mais é do que um padrão de qualidade (reconhecido mundialmente) pelo qual esta empresa foi avaliada e julgada. Para que seja possível realizar uma avaliação e um julgamento , é necessário haver um padrão ou norma. Existem alguns organismos normalizadores reconhecidos mundialmente:
- ISO - International Organization for Standardization
- IEEE - Instituto de Engenharia Elétrica e Eletrônica
- ABNT - Associação Brasileira de Normas Técnicas
A norma ISO-9000, por exemplo, foi criada pela ISO para permitir que todas as empresas do mundo possam avaliar e julgar sua qualidade. Existindo um padrão único mundial , uma empresa do Brasil, mesmo não tendo nenhum contato com uma outra empresa na Europa, pode garantir a ela a qualidade de seu trabalho.
A Certificação em uma norma ou padrão é a emissão de um documento oficial indicando a conformidade com esta determinada norma ou padrão. É claro que, antes da emissão do certificado, é preciso realizar todo um processo de avaliação e julgamento de acordo com uma determinada norma. Embora uma empresa possa auto-avaliar-se ou ser avaliada por seus próprios clientes, o termo Certificação costuma ser aplicado apenas quando efetuado por uma empresa independente e idônea, normalmente especializada neste tipo de trabalho. No Brasil, o INMETRO é o órgão do governo responsável pelo credenciamento destas instituições que realizam a certificação de sistemas de qualidade.
Qualidade do Produto x Qualidade do Processo
Uma das evoluções mais importantes no estudo da qualidade está em notar que a qualidade do produto é algo bom, mas que qualidade do processo de produção é ainda mais importante. No caso do prato de comida, por exemplo, você pode dizer mais sobre a qualidade observando como o prato foi preparado do que analisando o produto final. Afinal, você não consegue ter certeza da higiene ou o valor nutricional apenas comendo o prato.
Esta descoberta aconteceu durante a própria evolução dos conceitos de qualidade, ao longo dos anos. Observe na tabela abaixo como aconteceu esta evolução:
Inspeção pós-produção Avalia o produto final, depois de pronto 1900
Controle estatístico da produção Avalia os subprodutos das etapas de produção 1940
Procedimento de produção Avalia todo o procedimento de produção 1950
Educação das pessoas Avalia as pessoas envolvidas no processo 1960
Otimização dos processos Avalia e otimiza cada processo 1970
Projeto robusto Avalia o projeto de produção 1980
Engenharia simultânea Avalia a própria concepção do produto 1990
desenvolvimento de software.
NBR ISO 9001 Sistemas de qualidade - Modelo para garantia de qualidade em Projeto, Desenvolvimento, Instalação e Assistência Técnica (processo)
NBR ISO 9000- Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para o processo de desenvolvimento de software.
NBR ISO 10011 Auditoria de Sistemas de Qualidade (processo)
CMM
Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de Software do Departamento de Defesa dos EEUU) para avaliação da qualidade do processo de desenvolvimento de software. Não é uma norma ISO, mas é muito bem aceita no mercado.
SPICE ISO 15504
Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software. Ainda não é uma norma oficial ISO, mas o processo está em andamento.
No final desta página, você encontra alguns links relacionados a Qualidade e Qualidade de Software.
Engenharia de Software
Como você já viu, a disciplina que vai nos ajudar a entender o processo de desenvolvimento de software é a Engenharia de Software. É através dela que poderemos chegar à qualidade. Existe, entretanto, um grande problema a ser resolvido: tecnicamente, ela não existe.
O problema é que, para que uma disciplina seja considerada realmente uma Engenharia , é necessário atender a alguns requisitos básicos que a Engenharia de Software, pelos menos até agora, não atende. Veja a definição de Engenharia:
"A Engenharia deve criar soluções com uma relação custo-benefício adequada para problemas práticos, pela aplicação de conhecimentos científicos, para construir coisas a serviço da humanidade."
Dentro destes conceitos, a Engenharia de Software falha principalmente no que diz respeito à adequação do custo-benefício e à aplicação, em toda a sua extensão, de conhecimentos científicos. Atualmente, estes requisitos são atendidos apenas em parte.
É necessário definir, portanto, o que é exatamente a Engenharia de Software. Veja algumas tentativas de definição:
"...é a disciplina que integra métodos, ferramentas e procedimentos para o desenvolvimento de software para computadores."
"...é uma coleção de processos de gerenciamento, ferramental de software e atividades de projeto para o desenvolvimento de software. "
"...é um termo usado para referir-se a modelos de ciclo de vida, metodologias de rotina, técnicas de estimativa de custo, estruturas de documentação, ferramentas de gerenciamento de configuração, técnicas de garantia de qualidade e outras técnicas de padronização da atividade de produção de software."
No final desta página você encontrará alguns links relacionados a Engenharia de Software.
Qualidade de Produtos de Software - ISO 9126
Quando se pensa em qualidade de um "produto físico", é fácil imaginar padrões de comparação, provavelmente ligado às dimensões do produto ou alguma outra característica física. Quando se trata de software, como podemos definir exatamente o que é a qualidade? Parece difícil...
Felizmente, para nós, a ISO (Organização Internacional de Padrões) já pensou bastante sobre o assunto. O suficiente para publicar uma norma que representa a atual padronização mundial para a qualidade de produtos de software. Esta norma chama-se ISO/IEC 9126 e foi publicada em 1991. Ela é uma das mais antigas da área de qualidade de software e já possui sua tradução para o Brasil, publicada em agosto de 1996 como NBR 13596.
Mas, afinal de contas, o que está escrito nesta norma ISO/IEC 9126 ou na NBR 13596? Bem, estas normas listam o conjunto de características que devem ser verificadas em um software para que ele seja considerado um "software de qualidade". São seis grandes grupos de características, cada um dividido em algumas subcaracterísticas.
Os nomes dados pelo ISO/IEC para as características e subcaracterísticas são um pouco complexos (para dizer a verdade, acho até que os próprios termos "características" e "subcaracterísticas" são mais complexos que o necessário). Entretanto, uma pessoa que trabalha com software não terá dificuldade em entendê-las. Observe na tabela abaixo a lista completa:
Característica Subcaracterística Pergunta chave para a subcaracterística Adequação Propõe-se a fazer o que é apropriado? Acurácia Faz o que foi proposto de forma correta? Interoperbilidade Interage com os sistemas especificados? Conformidade Está de acordo com as normas, leis, etc.?
Funcionalidade (satisfaz as necessidades?)
Segurança de acesso Evita acesso não autorizado aos dados? Maturidade Com que freqüência apresenta falhas? Tolerância a falhas Ocorrendo falhas, como ele reage?
Confiabilidade (é imune a falhas?) Recuperabilidade É capaz de recuperar dados em caso de falha? Usabilidade Intelegibilidade É fácil entender o conceito e a aplicação?
Ficam, portanto, as questões: como dar uma nota, em valor numérico, a uma característica inteiramente subjetiva? O que representa, por exemplo, uma "nota 10" em termos de "Segurança de Acesso"? Quando se pode dizer que a "Intelegibilidade" de um software pode ser considerada "satisfatória"? Criou-se, então, uma área de estudo à parte dentro da Qualidade de Software conhecida como Métricas de Software. O que se pretende fazer é definir, de forma precisa, como medir numericamente uma determinada característica.
Para avaliar uma determinada subcaracterística subjetiva de forma simplificada, por exemplo, você pode criar uma série de perguntas do tipo "sim ou não". Crie as perguntas de forma tal que as respostas "sim" sejam aquelas que indicam uma melhor nota para a característica. Depois de prontas as perguntas, basta avaliar o software, respondendo a cada pergunta. Se você conseguir listar 10 perguntas e o software obtiver uma resposta "sim" em 8 delas, terá obtido um valor de 80% nesta característica.
Obviamente, a técnica acima não é muito eficiente. Para melhorá-la, entretanto, você pode garantir um número mínimo perguntas para cada característica. Além disso, algumas perguntas mais importantes podem ter pesos maiores. É possível, ainda, criar perguntas do tipo ABCDE, onde cada resposta indicaria um escore diferenciado. Alguns estudiosos sugerem formas diferentes de medir uma característica, baseada em conceitos do tipo "não satisfaz", "satisfaz parcialmente", "satisfaz totalmente" e "excede os padrões". Estes conceitos, emboram parecem muito subjetivos, não deixam de ser uma forma eficiente de medir uma característica.
Em todos os casos, um fato fica claro: nada ajuda mais a avaliar características de um software do que um avaliador experiente, que já realizou esta tarefa diversas vezes e em diversas empresas diferentes. Afinal, medir é comparar com padrões e um avaliador experiente terá maior sensibilidade do que um profissional que acaba de ler uma norma pela primeira vez.
Atualmente, a norma ISO/IEC 9126 está sendo revisada. A revisão, que deverá estar pronta nos próximos anos, não deverá modificar nenhuma das características básicas da 9126. A maior modificação será a inclusão de dois documentos adicionais para descrever métricas externas (relativas ao uso do produto) e métricas internas (relativas à arquitetura do produto). Veja algumas das modificações previstas para esta revisão:
- Algumas novas subcaracterísticas. Conformidade fará parte de todas as características. Atratividade será uma subcaracterística de usabilidade. Capacidade de coexistir será uma subcaracterística de portabilidade.
- A norma será dividida em três partes. A primeira (9126-1) incluirá definições e características. As duas seguintes descreverão métricas externas (9126-2) e internas (9126-3).
- A versão brasileira da revisão desta norma deverá ser chamada de NBR 9126-1, 9126-2 e 9126-3, segundo a numeração original da ISO/IEC.
Guias para a Avaliação da Qualidade - ISO 14598
Todos notaram a necessidade de mais detalhes sobre como avaliar a qualidade de um software. As características e subcaracterísticas da norma ISO/IEC 9126 apenas começaram o trabalho. Faltava definir, em detalhes, como atribuir um conceito para cada item. Afinal, sem uma padronização, que valor teria uma avaliação?
A ISO, consciente deste problema, está finalizando o trabalho em um conjunto de Guias para a Avaliação da Qualidade segundo a norma ISO/IEC 9126. Estes guias descrevem, detalhadamente, todos os passos para que se avalie um software. Embora o trabalho nesta norma ainda não esteja totalmente pronta, já existem informações detalhadas sobre o que será esta norma, quando for oficialmente publicada.
Esta nova norma trará muitos recursos interessantes aos avaliadores, já que trata o processo de avaliação em grande detalhe. Ela leva em conta a existência de três grupos interessados em avaliar um software, o que define os três tipos básicos de certificação:
Certificação Quem realiza Finalidade
de 1a. parte Empresas que desenvolvem software
Melhorar a qualidade de seu próprio produto
de 2a. parte Empresas que adquirem software Determinar a qualidade do produto que irão adquirir
de 3a. parte Empresas que fazem certificação Emitir documento oficial sobre a qualidade de um software
Esta norma se constituirá, na verdade, de seis documentos distintos, relacionados entre si. Veja:
Norma Nome Finalidade
14598-1 Visão Geral Ensina a utilizar as outras normas do grupo
14598-2 Planejamento e Gerenciamento Sobre como fazer uma avaliação, de forma geral
14598-3 Guia para Desenvolvedores Como avaliar sob o ponto do vista de quem desenvolve
14598-4 Guia para Aquisição Como avaliar sob o ponto de vista de quem vai adquirir
14598-5 Guia para Avaliação Como avaliar sob o ponto de vista de quem certifica
14598-6 Módulos de Avaliação Detalhes sobre como avaliar cada característica
- Requisitos de qualidade
3.1. Descrição do Produto Descreve o produto, de forma a ajudar o comprador em potencial, servindo como base para testes. Cada declaração deve ser correta e testável. Deve incluir declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
3.2. Documentação do usuário
Deve ser completa, correta, consistente, fácil de entender e capaz de dar uma visão geral do produto.
3.3. Programas e dados Descreve em detalhes cada uma das funções do software, incluindo declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
- Instruções para teste
4.1. Pré-requisitos de teste Lista de itens necessários ao teste, incluindo documentos incluídos no pacote, componentes do sistema e material de treinamento.
4.2. Atividades de teste Instruções detalhadas sobre os procedimentos de teste, inclusive instalação e execução de cada uma das funções descritas.
4.3. Registro de teste Informações sobre como os testes foram realizados, de tal forma a permitir uma reprodução destes testes. Deve incluir parâmetros utilizados, resultados associados, falhas ocorridas e até a identidade do pessoal envolvido.
4.4. Relatório de teste Relatório inlcuindo: identificação do produto, hardware e software utilizado, documentos utilizados, resultados dos testes, lista de não conformidade com os requisitos, lista de não conformidade com as recomendações, datas, etc.
Um dos grandes méritos desta norma está na profundidade com que são descritas cada uma das características e subcaracterísticas mencionadas na norma 9126. A norma inclui detalhes que devem estar presentes no produto, tais como:
- Documentação do usuário de fácil compreensão
- Um sumário e um índice remissivo na documentação do usuário
- Presença de um Manual de instalação com instruções detalhadas
- Possibilidade de verificar se uma instalação foi bem sucedida
- Especificação de valores limites para todos os dados de entrada, que deverão ser testados
- Operação normal mesmo quando os dados informados estão fora dos limites especificados
- Consistência de vocabulário entre as mensagens e a documentação
- Função de auxílio (help) com recursos de hipertexto
- Mensagens de erro com informações necessárias para a solução da situação de erro
- Diferenciação dos tipos de mensagem: confirmação, consulta, advertência e erro
- Clareza nos formatos das telas de entrada e relatórios
- Capacidade de reverter funções de efeito drástico
- Alertas claros para as conseqüências de uma determinada confirmação
- Identificação dos arquivos utilizados pelo programa
- Identificação da função do programa que está sendo executada no momento
- Capacidade de interromper um processamento demorado
Outras características importante são a ênfase nos testes e os modelos de relatórios incluídos. Tudo isso facilita grandemente o trabalho do avaliador. Uma versão traduzida desta norma será publicada em breve ABNT.
Qualidade do Processo de Software
Os estudos sobre qualidade mais recentes são na sua maioria voltados para o melhoramento do processo de desenvolvimento de software. Não é que a qualidade do produto não seja importante, ela é. Mas o fato é que, ao garantir a qualidade do processo, já se está dando um grande passo para garantir também a qualidade do produto.
O estudo da Qualidade do Processo de Software é uma área ligada diretamente à Engenharia de Software. O estudo de um ajuda a entender e aprimorar o outro. Em ambas as disciplinas, estuda-se modelos do processo de desenvolvimento de software. Estes modelos são uma tentativa de explicar em detalhes como se desenvolve um software, quais são as etapas envolvidas. É necessário compreender cada pequena tarefa envolvida no desenvolvimento.
Entre os estudos nesta área de maior importância, podemos citar:
- ISO 9000-3 - Normas para aplicação da série ISO 9000 em processos de software
- ISO 12207 - Processos do Ciclo de Vida do Software
- CMM - Capability Maturity Model
- PSP - Personal Software Process
- ISO 15504 - SPICE - Software Process Improvement and Capability dEtermination
- Modelo Trillium
- Metodologia Bootstrap
- Engenharia de Software Cleanroom
Dentre os trabalhos na área de Qualidade de Processo de Software, o único que realmente é norma oficial é o ISO 9000-3, que faz parte da série ISO 9000. Os demais modelos são normas não-oficiais criados por empresas e institutos ou então são normas em estágio de desenvolvimento. Muitos dos modelos estão disponíveis na Internet, em texto integral. No final desta página você encontrará alguns links sobre Modelos de Qualidade de Processo de Software. A seguir serão analisados em maior detalhes alguns destes modelos.
A Série ISO 9000
Esta série é um conjunto de normas da ISO que define padrões para garantia e gerenciamento da qualidade. Veja algumas destas normas abaixo:
- A empresa estabelece o seu sistema de qualidade
- A empresa faz uma solicitação formal a um órgão certificador, incluindo detalhes do negócio da empresa, escopo da certificação solicitada e cópia do manual de qualidade
- O órgão certificador faz uma visita à empresa, colhe mais dados e explica o processo de certificação
- O órgão certificador verifica se a documentação do sistema de qualidade está de acordo com a norma ISO
- O órgão certificador envia uma equipe à empresa com fins de auditoria. Nesta visita, será verificado se todos na empresa cumprem o que está documentado no manual de qualidade.
- O órgão certificador emite o certificado de qualidade
- O órgão certificador realiza visitas periódicas à empresa para assegurar que o sistema continua sendo efetivo
Se você desejar ter o texto integral das normas da série ISO 9000, pode pedir uma cópia à ABNT. Você terá de pagar por ela, mas o valor é pequeno (tanto a ISO 9001 quanto a ISO 9000-3 custam menos de R$25, cada). O site da ABNT na Internet oferece funções de pesquisa e orçamento para compra de normas.
ISO 12207 - Processos do Ciclo de Vida do Software
Este padrão formaliza a arquitetura do ciclo de vida do software, que é um assunto básico em Engenharia de Software e também em qualquer estudo sobre Qualidade do Processo de Software. Esta norma possui mais de 60 páginas e detalha os diversos processos envolvidos no ciclo de vida do software. Estes processos estão divididos em três classes: Processos Fundamentais, Processos de Apoio e Processos Organizacionais.
Veja a lista completa dos processos na tabela abaixo:
Processos Fundamentais
Início e execução do desenvolvimento, operação ou manutenção do software durante o seu ciclo de vida.
Aquisição Atividades de quem um software. Inclui: definição da necessidade de adquirir um software (produto ou serviço), pedido de proposta, seleção de fornecedor, gerência da aquisição e aceitação do software.
Fornecimento Atividades do fornecedor de software. Inclui preparar uma proposta, assinatura de contrato, determinação recursos necessários, planos de projeto e entrega do software.
Desenvolvimento Atividades do desenvolvedor de software. Inclui: análise de requisitos, projeto, codificação, integração, testes, instalação e aceitação do software.
Operação Atividades do operador do software. Inclui: operação do software e suporte operacional aos usuários.
Manutenção Atividades de quem faz a manutenção do software.
Processos de Apoio Auxiliam um outro processo.
Documentação Registro de informações produzidas por um processo ou atividade. Inclui planejamento, projeto, desenvolvimento, produção, edição, distribuição e manutenção dos documentos necessários a gerentes, engenheiros e usuários do software.
Gerência de Configuração
Identificação e controle dos itens do software. Inclui: controle de armazenamento, liberações, manipulação, distribuição e modificação de cada um dos itens que compõem o software.
Garantia da Qualidade
Garante que os processos e produtos de software estejam em conformidade com os requisitos e os planos estabelecidos.
Verificação Determina se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles.
Validação Determina se os requisitos e o produto final (sistema ou software) atendem ao uso específico proposto.
Revisão Conjunta Define as atividades para avaliar a situação e produtos de uma atividade de um projeto, se apropriado.
Auditoria Determina adequação aos requisitos, planos e contrato, quando apropriado.
Resolução de Problemas
Análisar e resolução dos problemas de qualquer natureza ou fonte, descobertos durante a execução do desenvolvimento, operação, manutenção ou outros processos..
Processos Organizacionais
Implementam uma estrutura constituída de processos de ciclo de vida e pessoal associados, melhorando continuamente a estrutura e os processos.
Gerência Gerenciamento de processos.
Infra-estrutura Fornecimento de recursos para outros processos. Inclui: hardware, software, ferramentas, técnicas, padrões de desenvolvimento, operação ou manutenção.
Melhoria Atividades para estabeler, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software.
Treinamento Atividades para prover e manter pessoal treinado.
A norma detalha cada um dos processos acima. Ela define ainda como eles podem ser usados de diferentes maneiras por diferentes organizações (ou parte destas), representando diversos pontos de vista para esta utilização. Cada uma destas visões representa a forma como uma organização emprega estes processos, agrupando-os de acordo com suas necessidades e objetivos.
As Visões têm o objetivo de organizar melhor a estrutura de uma empresa, para definir suas gerências e atividades alocadas às suas equipes. Existem cinco visões diferentes: contrato, gerenciamento, operação, engenharia e apoio. Veja na figura abaixo como estas visões se relacionam aos processos.
CMM - Capability Maturity Model
Este "Modelo de Maturidade da Capacidade" é uma iniciativa do SEI (Software Engineering Institute) para avaliar e melhorar a capacitação de empresas que produzem software. O projeto CMM foi apoiado pelo Departamento de Defesa do Governo dos Estados Unidos, que é um grande consumidor de software e precisava de um modelo formal que permitisse selecionar os seus fornecedores de software de forma adequada. Embora não seja uma norma emitida por uma instituição internacional (como a ISO ou o IEEE), esta norma tem tido uma grande aceitação mundial, até mesmo fora do mercado americano. O modelo, publicado em 1992, não é extenso e pode ser obtido na própria Internet com facilidade. O CMM também é chamado de SW-CMM (Software CMM).
Maturidade
O CMM é um modelo para medição da maturidade de uma organização no que diz respeito ao processo de desenvolvimento de software. A definição do que é "Maturidade" pode ser melhor compreendida através da análise do quadro abaixo:
Organizações maduras Organizações imaturas
Papéis e responsabilidades bem definidos Processo improvisado
Existe base histórica Não existe base histórica
É possível julgar a qualidade do produto Não há maneira objetiva de julgar a qualidade do produto
A qualidade dos produtos e processos é monitorada
Qualidade e funcionalidade do produto sacrificadas
O processo pode ser atualizado Não há rigor no processo a ser seguido
Existe comunicação entre o gerente e seu grupo Resolução de crises imediatas
Níveis
O CMM classifica as organizações em cinco níveis distintos, cada um com suas características próprias. No nível 1, o das organizações mais imaturas, não há nenhuma metodologia implementada e tudo ocorre de forma desorganizada. No nível 5, o das organizações mais maduras, cada detalhe do processo de desenvolvimento está definido, quantificado e acompanhado e a organização consegue até absorver mudanças no processo sem projudicar o desenvolvimento. Veja a tabela abaixo:
Nível CMM Descrição
Inicial O processo de desenvolvimento é desorganizado e até caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e heróicos.
Repetível Os processos básicos de gerenciamento de projeto estão estabelecidos e permitem acompanhar custo, cronograma e funcionalidade. É possível
repetir o sucesso de um processo utilizado anteriormente em outros projetos similares.
Definido Tanto as atividades de gerenciamento quanto de engenharia do processo de desenvolvimento de software estão documentadas, padronizadas e integradas em um padrão de desenvolvimento da organização. Todos os projetos utilizam uma versão aprovada e adaptada do processo padrão de desenvolvimento de software da organização.
Gerenciado São coletadas medidas detalhadas da qualidade do produto e processo de desenvolvimento de software. Tanto o produto quanto o processo de desenvolvimento de software são entendidos e controlados quantitativamente.
Otimizado O melhoramento contínuo do processo é conseguido através de um "feedback" quantitativo dos processos e pelo uso pioneiro de idéais e tecnologias inovadoras.
Uma empresa no nível 1 não dá garantia de prazo, custo ou funcionalidade. No nível 2, a empresa já consegue produzir bons softwares, no prazo e a um custo previsível. O nível 3 garante um excelente nível de qualidade, tanto no produto quanto no processo de desenvolvimento como um todo. Não há, no mundo, muitas empresas que tenham chegado aos níveis 4 e 5...
Áreas-chave de processo (Key Process Areas ou KPAs)
Exceto no nível 1, todos os níveis são detalhados em áreas-chave de processo. Estas áreas são exatamente aquilo no que a organização deve focar para melhorar o seu processo de desenvolvimento de software. Para que uma empresa possa se quailificar em um determinado nível de maturidade CMM, deve estar realizando os processos relacionados às áreas-chave daquele determinado nível. Todas as áreas-chave estão citadas na tabela abaixo:
Nível CMM Foco Áreas-chave de processo
Inicial Pessoas competentes e heróis
Repetível Processos de gerenciamento de projetos
- Gerenciamento de requisitos
- Planejamento do projeto
- Visão geral e acompanhamento do projeto
- Gerenciamento de subcontratados
- Garantia da qualidade do software
- Gerenciamento de configuração
- Definido Processos de engenharia e apoio • Foco do processo organizacional
- Definição do processo organizacional
- Programa de treinamento
Visão geral e acompanhamento do projeto
Resultados reais são acompanhados de acordo do com o planejamento do software Quando os resultados apresentam um significativo desvio do planejamento do software, são tomadas ações corretivas que são acompanhadas até o final do projeto Mudanças nos compromissos assumidos são feitas em comum acordo com os grupos e indivíduos afetados Gerenciamento de subcontratados
O contratante seleciona subcontratos qualificados O contratante e os subcontratatos estão de acordo no que diz respeito aos compromissos assumidos um com o outro. O contratante e os subcontatados mantém uma comunicação constante O contratante acompanha os resultados reais do subcontratado de acordo com os compromissos assumidos Garantia da qualidade do software
As atividades de garantia de qualidade de software são planejadas A conformidade dos produtos de software e atividades com os padrões, procedimentos e requisitos é verificada objetivamente. Os grupos e indivíduos afetados são informados das atividades de garantia de qualidade de software e de seus resultados. Questões realacionadas à não conformidade que não são resolvidas dentro do projeto de software são encaminhadas à gerência geral Gerenciamento de configuração As atividades de gerenciamento de configuração são planejadas. Os produtos de trabalho de software são identificados, controlados e estão disponíveis. Mudanças nos produtos de trabalho identificados são controladas. Os grupos e pessoas afetadas são informados da situação atual e projetada dos produtos de trabalho de software. Foco do processo organizacional São coordenadas atividades de desenvolvimento e melhoramento do processo de software em toda a organização Os pontos fortes e fracos do processo de desenvolvimento de software utilizado são identificados, de acordo com um padrão de processo. São planejadas atividades de desenvolvimento e melhoramento do processo, a nível de organização.
- Definido
Definição do processo organizacional
O processo padrão de desenvolvimento de software da organização é desenvolvido e mantido. A informação relacionada ao uso do processo padrão de desenvolvimento de software é coletada, revisada e disponibilizada.
Programa de treinamento As atividades de treinamento são planejadas É fornecido treinamento para o desenvolvimento de habilidades e conhecimentos necessários para realizar o gerenciamento do software e as funcões técnicas. As pessoas no grupo de engenharia de software e outros grupos relacionados a software recebem o treinamento necessário para realizar as suas funções Gerenciamento de software integrado
O processo de software definido para o projeto é uma versão adaptada do processo padrão de desenvolvimento de software da organização O projeto é planejado e gerenciado de acordo com o processo de desenvolvimento de software definido para o projeto Engenharia de produto de software
As atividades de engenharia de software são definidas, intregradas e consistentemente realizadas para produzir o software. Os produtos de trabalho do software são mantidos consistentes entre si. Coordenação intergrupos Todos os grupos de traabalho afetados concordam com os requisitos dos cliente. Todos os grupos de trabalho afetados concordam com os acordos entre os grupos de engenharia Os grupos de engenharia identificam, acompanham e resolvem todas as questões intergrupos. Revisão conjunta Atividades de revisão conjunta são planejadas Defeitos nos produtos de trabalho são identificados e removidos. Gerenciamento quantitativo dos processos
As atividades de gerenciamento quantitativo dos processos são planejadas A performance do processo de desenvolvimento de software definido para o projeto é controlada quantitativamente A capacidade do processo desenvolvimento de software padrão da organização é conhecida em termos quantitativos.
Gerenciado
Gerenciamento da qualidade de software
As atividades de gerenciamento da qualidade de software do projeto são planejadas. Objetivos mensuráveis da qualidade do produto de software e suas prioridades são definidos. O progresso real em direção à realização dos objetivos de qualidade para os produtos de software é quantificado e gerenciado.
- Otimizado Prevenção de defeitos As atividades de prevencão de defeitos são planejadas As causas comuns de defeitos são procuradas e identificadas As causas comuns de defeitos são priorizadas e sistematicamente eliminadas.
