UNIDAVI - UNIVERSIDADE PARA O DESENVOLVIMENTO DO ALTO VALE

DO ITAJAÍ

FACITEC – FACULDADE DE CIÊNCIA E TECNOLOGIA

BSI – BACHARELADO DE SISTEMAS DE INFORMAÇÃO

ENGENHARIA DE SOFTWARES

PROF.: Fábio Alexandrini

ACADÊMICOS: Paulo Luis Steinhauser

Rodrigo Schlickmann

Normas e Modelos de Qualidade de SW

ISO 9126 - Norma para qualidade de produtos de software ISO 14598 - Guias para avaliação de produtos de software ISO 12119 - Norma para qualidade de pacotes de software ISO 12207 - Processos de ciclo de vida do software. NBR ISO 9000-3 -Diretrizes para aplicação da norma ISO 9001 ao

desenvolvimento, fornecimento e manutenção de software. SPICE / ISO 15504 - Projeto da ISO/IEC para avaliação de

processo de desenvolvimento de software. CMM - Capability Maturity Model. Modelo do Software Engineering

Intitute (SEI) para avaliação de processos de software. PSP - Personal Software Process - Modelo do SEI que define

disciplinas para qualidade pessoal do engenheiro de software.

O que é CMM?

O CMM - Capability Maturity Model (Modelo de Maturidade da Capabilidade)

é um modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas-chave que são requeridas para aumentar a maturidade desses processos. Ele prevê cinco níveis de maturidade: inicial, repetível, definido, gerenciado e otimizado.

O que é CMM?

O modelo foi proposto por Watts S. Humphrey, a partir das propostas de Philip B. Crosby, e vem sendo aperfeiçoado pelo Software Engineering Institute – SEI da Carnegie Mellon University

http://www.sei.cmu.edu

OS CRIADORES

Watts_S._Humphrey

Philip B. Crosby

Modelos CMM

Modelos CMM

Software Acquisition CMM (SA-CMM) : usado para avaliar a maturidade de uma organização em seus processos de seleção, compra e instalação de softwares desenvolvidos por terceiros.

Systems Engineering CMM (SE-CMM) : avalia a maturidade da organização em seus processos de engenharia de sistemas, concebidos como algo maior que o software. Um “Sistema” inclui o hardware, o software e quaisquer outros elementos que participam do produto completo. Se um novo caça está sendo desenvolvido, o avião é o “Sistema”, incluindo aí todo software que nele esteja embarcado.

Modelos CMM

Integrated Product Development CMM (IPD-CMM) : ainda mais abrangente que o SE-CMM, inclui também outros processos necessários à produção e suporte ao produto, tais como suporte ao usuário, processos de fabricação etc.

People CMM (P-CMM) : avalia a maturidade da organização em seus processos de administração de recursos humanos no que se refere a software; recrutamento e seleção de desenvolvedores, treinamento e desenvolvimento, remuneração etc.

CMMI

O CMMI - Capability Maturity Model Integration foi criado pelo SEI como uma integração e evolução dos modelos: SW-CMM - Capability Maturity Model for Software; SECM - System Engineering Capability Model, e IPD-CMM - Integrated Product Development CMM. O CMMI é um modelo alinhado com a Norma ISO/IEC 15504 e é apresentado em duas representações: uma por estágio (como o CMM), e outra contínua (semelhante à ISO/IEC 15504).

História do CMM

O CMM surgiu durante a década de 1980 como um modelo para avaliação de risco na contratação de empresas de software pela Força Aérea Norte-Americana, que desejava ser capaz de avaliar os processos de desenvolvimento utilizados pelas empresas que concorriam em licitações, como indicação da previsibilidade da qualidade, custos e prazos nos projetos contratados. Para desenvolver este modelo, a Força Aérea constituiu, junto à Carnegie-Mellon University, o SEI (Software Engineering Institute), o qual, além de ser o responsável pela evolução do CMM, realiza diversas outras pesquisas em Engenharia de Software.

História do CMM

O líder do projeto que veio a resultar no CMM foi Watts Humphrey, anteriormente responsável por todo o desenvolvimento de software da IBM, onde aplicou pela primeira vez os conceitos tradicionais de qualidade, largamente conhecidos e utilizados em manufatura, no desenvolvimento e manutenção de software. Neste trabalho, Humphrey baseou-se na sua experiência anterior como engenheiro de hardware.

Evolução

Nov/1986 - início do desenvolvimento do Framework

Set/1987 - lançada uma descrição geral do modelo

1988 - publicado o artigo “Characterizing the Software Process” de Watts Humphrey

1989 - publicado o livro “Managing the Software Process”, de Watts Humphrey

1991/1992 - lançamento e reviões da primeira versão, por Paulk e Weber (TR24 e TR25)

1993 - lançada a versão 1.1 e o livro “The Capability Maturity Model”, de Mark Paulk .

Onde é usado o CMM

Embora, historicamente, o CMM tenha surgido no contexto de grandes empresas de desenvolvimento de software contratadas pelas Forças Armadas dos EUA para projetos militares, tem-se verificado que seus princípios são válidos para todo tipo de projetos de software.

Onde é usado o CMM

Isto não é de se estranhar, já que o CMM nada mais é que a aplicação dos princípios da Qualidade Total e do Gerenciamento de Projetos ao mundo do software. Assim, o CMM tem sido usado com sucesso, na íntegra ou adaptado, nos mais variados tipos de empresas, grandes e pequenas, em várias áreas de atuação. Exemplos ilustrativos desta diversidade incluem:

Onde é usado o CMM

Pequenas software-houses (10 a 20 desenvolvedores)

Grandes Bancos e Seguradoras Empresas de Telecomunicações Fabricantes de hardware com software embarcado

(pagers, aviônicos, componentes automobilísticos, telefones celulares)

Empresas de consultoria em desenvolvimento de sistemas (outsourcing)

Os Cinco Níveis de Maturidade

Nível de maturidade é um estágio evolutivo bem definido em busca de um processo de software maduro. Cada nível de maturidade fornece uma gama de fundamentos para a melhoria contínua do processo. Cada nível compreende um conjunto de objetivos de processos que, quando satisfeitos, estabilizam um componente importante do processo de software. Alcançando cada nível da estrutura de maturidade, estabelecesse diferentes componentes no processo de software, resultando em um crescimento na capabilidade de processo da organização.

Os Cinco Níveis de Maturidade

O CMM está dividido em cinco níveis de maturidade, os quais são: Inicial, Repetível, Definido, Gerenciado e Em Otimização.

Nível 1- Inicial

Inexistência de um ambiente estável para desenvolvimento e manutenção de software.

Ocasionalmente, durante os momentos de crise, procedimentos planejados são abandonados e a atenção é focada na codificação.

Poucos processos definidos, sucesso dependente de iniciativas individuais; ocasionalmente caótico

Nível 1- Inicial

Neste nível, não existem procedimentos padronizados, estimativas de custos e planos de projeto. Cada qual desenvolve como quer, não existe documentação e não há mecanismos de controle que permitam ao gerente saber o que está acontecendo, identificar problemas e riscos e agir de acordo. Como conseqüência, os desvios não são corrigidos e ocorrem os problemas como prazos não cumpridos, orçamentos estourados, software sem qualidade e usuários insatisfeitos. Na verdade, raramente existe um cronograma ou um orçamento. Infelizmente, estima-se que mais de três quartos das empresas norte-americanas encontram-se neste nível, e não há razões para acreditar que a situação seja melhor no Brasil.

Nível 2 - Repetível

Os processos básicos de gestão de projeto são estabelecidos para acompanhar custo, cronograma e funcionalidade. A necessária disciplina do processo existe para repetir sucessos anteriores em projetos com aplicações similares.

Nível 2 - Repetível

No Nível Repetível, as políticas de gestão de projeto de software e os procedimentos para implementá-las são estáveis. O planejamento e a gestão de novos projetos são baseados na experiência adquirida em projetos similares. Um dos objetivos alcançados no nível 2 é a institucionalização dos processos para os projetos de software, possibilitando que as organizações repitam as práticas bem sucedidas desenvolvidas em projetos anteriores, apesar dos processos específicos implementados pelos projetos serem diferentes. Um processo efetivo pode ser caracterizado como hábil, documentado, robusto, treinado, medido e com capacidade de poder ser melhorado.

Nível 2 - Repetível

Os projetos nas organizações de nível 2 possuem controles básicos de gestão de software. Os compromissos realistas do projeto são baseados em resultados observados em projetos anteriores e nos requisitos do projeto atual. Os gerentes de software do projeto acompanham custos, cronogramas e funcionalidades do software; os problemas com compromissos são identificados quando surgem.

Nível 2 - Repetível

Os requisitos e os produtos de trabalho de software desenvolvidos para satisfazê-los são armazenados de forma criteriosa e a integridade dos mesmos é controlada. Os padrões do projeto de software são definidos e a organização garante que eles sejam seguidos fielmente. Existindo subcontratados, o projeto de software trabalha em conjunto com os mesmos, visando fortalecer a relação cliente-fornecedor.

Nível 2 - Repetível

A capabilidade de processo de software das organizações de nível 2 pode ser resumida como sendo disciplinada, uma vez que o planejamento e o acompanhamento de projeto de software são estáveis e os sucessos mais recentes podem ser repetidos. Os processos estão sob um controle efetivo de um sistema de gestão de projeto, seguindo planos realistas baseados no desempenho de projetos anteriores.

Áreas-chave do nível 2

As áreas-chave de processo do Nível 2 são focadas em assuntos de projeto de software relacionados com o estabelecimento de controles básicos de gerência de projeto. As descrições de cada área-chave do Nível 2 são apresentadas a seguir:

Áreas-chave do nível 2

Gerenciamento dos Requisitos Planejamento do Projeto de

Software Gerenciamento do Projeto de

Software Gerência do Subcontrato de

Software Garantia da Qualidade de Software Gerência de Configuração de

Software

Gerenciamento dos Requisitos

O propósito do Gerenciamento de Requisitos é estabelecer um entendimento comum entre o cliente e o projeto de software sobre os requisitos do cliente que serão tratados pelo projeto. Este acordo com o cliente é a base para o planejamento e para a gerência do projeto de software. A coordenação do relacionamento com o cliente depende da observância de um efetivo processo de controle de alteração.

Planejamento do Projeto de Software

O propósito do Planejamento de Projeto de Software é estabelecer planos razoáveis para a execução das atividades de gerência e desenvolvimento de projeto de software. Estes planos constituem a base necessária para se gerenciar o projeto. Sem planos realistas, uma gestão efetiva de projeto não pode ser implementada.

Gerenciamento do Projeto de Software

O propósito do Acompanhamento e Supervisão de Projeto de Software é estabelecer a adequada visibilidade do progresso real, de tal maneira que a gerência possa tomar ações efetivas quando o desempenho do projeto sofre um desvio significativo com relação ao planejado.

Gerência do Subcontrato de Software

O propósito da Gestão de Subcontratação de Software é selecionar subcontratados qualificados e gerenciá-los de modo efetivo. Esta área-chave combina os assuntos relativos à Gestão de requisitos, Planejamento de Projeto de Software e Acompanhamento e Supervisão de Projeto de Software, para obter um controle básico de gestão, juntamente com a necessária coordenação da Garantia de Qualidade de Software e da Gestão de Configuração de Software, que são aplicadas apropriadamente aos subcontratados.

Garantia da Qualidade de Software

O propósito da Garantia de Qualidade de Software é fornecer uma gestão com visibilidade apropriada sobre os processos utilizados e produtos desenvolvidos pelo projeto de software. A Garantia de Qualidade de Software é parte integrante da maioria dos processos de gerência e de desenvolvimento de software.

Gerência de Configuração de Software

O propósito da Gestão de Configuração de Software é estabelecer e manter a integridade dos produtos do projeto ao longo de todo o ciclo de vida. A Gestão de Configuração de Software é parte integrante da maioria dos processos de gerência e de desenvolvimento de software.

Avaliações CMM no Brasil

No último relatório do SEI/CMU, publicado em setembro de 2005 com dados até junho do mesmo ano, o Brasil encontra-se em 14º lugar dentre os países com maior número de avaliações CMM realizadas por esse instituto (após ter permanecido na 13ª posição desde dezembro de 2001), sendo o único país da América Sul que aparece com mais de 20 avaliações (29).

Empresas Qualificadas no Brasil

Fonte: http://www.mct.gov.br

Qualificações CMMI no Brasil

Qualificações CMMI no Brasil

Depoimento de uma empresa

com CMM Nível 2

(BSI Tecnologia)

Bsi Tecnologia

As mudanças que a empresa passou para receber a certificação, tanto na área física, tecnológica e pessoal. [Marcelo Chamorro] Os colaboradores tiveram

que tornar público seus conhecimentos e práticas, institucionalizando as mesmas para todos. E isso trouxe os benefícios de uma empresa de comportamento mais uniforme e interativo com as necessidades do mercado.

Alguns dos benefícios que tiveram:

Processos definidos e documentados Definição e uso de padrões Gestão de requisitos Planejamento de Atividades Acompanhamento periódico Maior visibilidade dos projetos Gerência da Configuração Ênfase na Garantia da Qualidade - Processo e Produto Redução do nível de resistência a mudanças e melhoria do

clima organizacional

As reais vantagens de ser certificado

• [Marcelo Chamorro] O processo de regularização das atividades, a própria maturidade das pessoas e dos processos já são ganhos efetivos da empresa, fora isso, a empresa se qualifica para empreitadas maiores frente a empresas governamentais do tipo Petrobrás, etc.

O tempo que demora o processo para a certificação

• [Marcelo Chamorro] Depende do seu nível inicial. Um bom approach é realizar um diagnóstico inicial por auditores credenciados. Nossa sensibilidade para este assunto, pois ainda estamos em evolução é a seguinte: Nível 2: 18 meses Nível 3: 12 meses Nível 4 e 5: 10 meses

O custo para o processo em geral(aproximadamente)

[Marcelo Chamorro] Podemos dizer com mais certeza para a atividade de fábrica de programas, para projetos custa mais devido aos ferramentais de testes: Nível 3 - CMMI: US$ 500,000.00 sendo

que a parte do certificador fica por volta de US$ 30,000.00. Isto incluindo tudo, inclusive despesas de transportes, licenças, literaturas, curso team member e SCE.

Como funciona o processo? O que é avaliado? De que forma? Quem avalia?

[Marcelo Chamorro] O processo é composto por alguns passos importantes:

1º Diagnóstico inicial - Avaliação classe C 2º Curso básico de CMMI - Formação de team

members 3º Definição e implantação das PA - Process áreas 4º Avaliação da eficácia da implantação 5º Avaliação Classe B - Passa / Não passa. O

certificador verifica se a empresa pode ir para a avaliação final

Como funciona o processo? O que é avaliado? De que forma? Quem avalia?

6º Ajustes / maturação dos processos e coleta de evidências

7º Curso SCE (Antes era SCAMPI - CMM) para todos team members

8º Avaliação oficial 9º Registro oficial no site do SEI

Nota importante: A maturidade da empresa é verificada desde o primeiro contato agendamento e cumprimento de datas, material utilizado, etc.)

Fontes:

http://www.bsitecnologia.com.br http://pt.wikipedia.org/wiki/CMM http://www.gnosisbr.com.br http://www.inatel.br http://www.pernambuco.com http://www.mct.gov.br http://www.spress.com.br http://www.sei.cmu.edu http://www.cpqd.com.br