CMMI

O CMMI (Capability Maturity Model Integration) um modelo de referncia que contm prticas (Genricas ou Especficas) necessrias maturidade em disciplinas especficas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI uma evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI foi baseado nas melhores prticas para desenvolvimento e manuteno de produtos. H uma nfase tanto em engenharia de sistemas quanto em engenharia de software, e h uma integrao necessria para o desenvolvimento e a manuteno. A verso atual do CMMI (verso 1.3) foi publicada em 27 de outubro de 2010 e apresenta trs modelos:

CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e servios. CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisio e terceirizao de bens e servios. CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de servios.

Uma das premissas do modelo "A qualidade influenciada pelo processo", e seu foco "Melhorar processo de uma empresa".

Representaes[editar]
O CMMI possui duas representaes: "contnua" ou "por estgios". Estas representaes permitem organizao utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representao Contnua[editar]
Possibilita organizao utilizar a ordem de melhoria que melhor atende os objetivos de negcio da empresa. caracterizado por: Nveis de Capacidade (Capability Levels): Nvel 0: Incompleto (Ad-hoc) Nvel 1: Executado Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Gerenciado quantitativamente --- REMOVIDO DA v.1.3 Nvel 5: Em otimizao --- REMOVIDO DA v.1.3

Nesta representao a capacidade medida por processos separadamente, onde possvel ter um processo com nvel um e outro processo com nvel cinco, variando de acordo com os interesses da empresa.

No nvel 1(um) o processo executado de modo a completar o trabalho necessrio para a execuo de um processo. No nvel 2(dois) sobre planejar a execuo e confrontar o executado contra o que foi planejado. No nvel 3(trs) o processo construdo sobre as diretrizes do processo existente, e mantido uma descrio do processo. No nvel 4(quatro) quando o processo gerenciado quantitativamente atravs de estatsticas e outras tcnicas. No nvel 5(cinco) o processo gerido quantitativamente alterado e adaptado para atender s necessidades negociais/estratgicas da empresa.

A representao contnua indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando j utiliza algum modelo de maturidade contnua ou quando no pretende usar a maturidade alcanada como modelo de comparao com outras empresas.

Representao Por Estgios[editar]

Disponibiliza uma seqncia pr-determinada para melhoria baseada em estgios que no deve ser desconsiderada, pois cada estgio serve de base para o prximo. caracterizado por Nveis de Maturidade (Maturity Levels): Nvel 1: Inicial (Ad-hoc) Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao

Nesta representao a maturidade medida por um conjunto de processos. Assim necessrio que todos os processos atinjam nvel de maturidade dois para que a empresa seja certificada com nvel dois. Se quase todos os processos forem nvel trs, mas apenas um deles estiver no nvel dois a empresa no ir conseguir obter o nvel de maturidade trs. Esta representao indicada quando a empresa j utiliza algum modelo de maturidade por estgios, quando deseja utilizar o nvel de maturidade alcanado para comparao com outras empresas ou quando pretende usar o nvel de conhecimento obtido por outros para sua rea de atuao.

reas de Processo[editar]
O modelo CMMI v1.2 (CMMI-DEV) contm 22 reas de processo. Em sua representao por estgios, as reas so divididas da seguinte forma: Nvel 1: Inicial (Ad-hoc) No possui reas de processo. Nvel 2: Gerenciado / Gerido Gerenciamento de Requisitos - REQM (Requirements Management) Planejamento de Projeto - PP (Project Planning) Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control) Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management)

Medio e Anlise - MA (Measurement and Analysis) Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance) Gerncia de Configurao - CM (Configuration Management)

Nvel 3: Definido Desenvolvimento de Requisitos - RD (Requirements Development) Soluo Tcnica - TS (Technical Solution) Integrao de Produto - PI (Product Integration) Verificao - VER (Verification) Validao - VAL (Validation) Foco de Processo Organizacional - OPF (Organizational Process Focus) Definio de Processo Organizacional - OPD (Organizational Process Definition) Treinamento Organizacional - OT (Organizational Training) Gerenciamento Integrado de Projeto - IPM (Integrated Project Management) Gerenciamento de Riscos - RSKM (Risk Management) Anlise de Deciso e Resoluo - DAR (Decision Analysis and Resolution)

Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Desempenho de Processo Organizacional - OPP (Organizational Process Performance) Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)

Nvel 5: Em otimizao Gesto de Processo Organizacional - OPM (Organizational Process Management) Anlise Causal e Resoluo - CAR (Causal Analysis and Resolution)

Modelos e reas de processo[editar]

As reas de processo variam com base no modelo escolhido, no sendo as mesmas reas para todos os modelos (CMMI-DEV, CMMI-ACQ ou CMMI-SVC).

ISO/IEC 15504[editar]
A ISO/IEC 15504, tambm conhecida como SPICE, define um "processo para relatrios tcnicos no assessoramento em desenvolvimento de software", e similarmente ao CMMI possui nveis de maturidade para cada processo. O CMMI no baseado nesta norma, mas sim compatvel. A ISO/IEC 15504 define um modelo de referncia de processo que identifica e descreve um conjunto de processos considerados universais e fundamentais para a boa prtica da engenharia de software, e define seis nveis de capacidade, seqenciais e cumulativos que podem ser utilizados como uma mtrica para avaliar como uma organizao est realizando um determinado processo e tambm podem ser utilizados como um guia para a melhoria. A ISO/IEC 15504 define tambm um guia para a orientao da melhoria de processo, tendo como referncia um modelo de processo e como uma das etapas a realizao de uma avaliao de processo. Este guia sugere 8 etapas seqenciais, que inicia com a

identificao de estmulos para a melhoria e o exame das necessidades da organizao. 18,2%: nvel 5 (Optimizing); 4,4%: nvel 4 (Quantitatively Managed); 33,8%: nvel 3 (Defined); 33,3%: nvel 2 (Managed); 1,9%: nvel 1 (Initial); 8,4%: sem qualificao (Not Given).

SUPORTE

SUP.1: Documentao[editar]
desenvolver e manter documentos que registrem informaes produzidas por um outro processo ou atividade. Envolve a produo, controle, manuteno, reviso, aprovao e publicao de documentos e seu acesso.

SUP.2: Gesto de configurao[editar]

Objetivo: estabelecer e manter a integridade de todos os produtos de trabalho de algum processo ou do projeto. Envolve a definio de uma estratgia de gesto de configurao, a identificao de itens de configurao, o controle de acesso e de mudanas de itens, o registro da situao de todos os itens e o seu armazenamento e manuseio de forma controlada.

SUP.3: Garantia de qualidade[editar]

Objetivo: assegurar que os produtos de trabalho e atividades de um processo ou projeto esto de acordo com os requisitos especificados e satisfazem aos planos e regras estabelecidas. Devem ser estabelecidos os procedimentos para o tratamento de desvios a noconformidades com relao a regras, procedimentos e padres. Deve ser coordenada com os processos de verificao, validao, reviso conjunta, auditoria e resoluo de problemas. As pessoas responsveis pela garantia da qualidade devem ter autonomia organizacional e autoridade para realizarem as suas tarefas sem interferncias dos responsveis pelo desenvolvimento do software.

SUP.4: Verificao[editar]
Objetivo: confirmar que cada produto de trabalho ou servio resultado de um processo reflete corretamente s especificaes de entrada do processo. Envolve a definio de uma estratgia de verificao, de critrios de verificao para todos os produtos de trabalho e para as atividades de verificao. Deve assegurar que os defeitos encontrados sero removidos dos produtos de trabalho e que os resultados sero disponibilizados para os clientes Normalmente envolve a realizao de testes e est relacionado aos processos ENG.1.6 e ENG.1.7.

Pode tambm fazer uso de tcnicas como peer reviews, provas formais e anlise de rastreabilidade.

SUP.5: Validao[editar]
Objetivo: confirmar que esto satisfeitos os requisitos para o uso pretendido de cada produto de trabalho ou servio resultado de um processo. Envolve a definio de uma estratgia de validao, de critrios de validao para todos os produtos de trabalho e para as atividades de validao. Deve assegurar que os problemas encontrados sero resolvidos, que os resultados sero disponibilizados para os clientes e para outras organizaes internas e que os produtos so adequados para o uso pretendido. Normalmente est relacionado ao processo de teste de integrao e teste de software ENG.1.7.

SUP.6: Reviso Conjunta[editar]

Objetivo: permitir ao cliente a visibilidade do andamento do desenvolvimento quando comparado ao especificado no contrato. As revises formais dever tratar, ao longo de todo o ciclo de vida de desenvolvimento, tanto dos aspectos tcnicos quanto administrativos. Envolve: revises peridicas em datas pr-estabelecidas da situao de produtos e atividades por todas as partes interessadas, da soluo de todas as pendncias, problemas e desvios encontrados.

SUP.7: Auditoria[editar]
Objetivo: determinar, de forma independente, a conformidade de produtos identificados e atividades com planos, requisitos e com o contrato. Deve ser definida a estratgia de programao da auditoria, especificando quais itens sero auditados contra quais regras. A auditoria deve ser conduzida por pessoal independente quele que executa o desenvolvimento e os problemas encontrados devero ser comunicados aos responsveis para a devida ao corretiva.

SUP.8: Resoluo de Problemas[editar]

Objetivo: assegurar que todos os problemas encontrados sejam analisados, resolvidos (ao corretiva) e que tendncias sejam observadas visando o planejamento e execuo de aes preventivas.

***************************************************************

A ISO/IEC 12207 a norma ISO/IEC que define processo de desenvolvimento de software. A norma internacional ISO/IEC 12207 [1] tem como objetivo principal estabelecer uma estrutura comum para os processos de ciclo de vida e de desenvolvimento de softwaresvisando ajudar as organizaes a compreenderem todos os componentes presentes na aquisio e

fornecimento de software e, assim, conseguirem firmar contratos e executarem projetos de forma mais eficaz.

Estrutura[editar]
Os processos na ISO/IEC 12207 so de responsabilidade de uma organizao, mas no so exclusivos desta, ou seja, uma organizao pode executar um ou mais processos e um processo pode ser executado por uma ou mais organizaes. Neste caso, uma das organizaes ser a responsvel pelo processo total, mesmo que tarefas individuais sejam realizadas por pessoas diferentes. Os processos so agrupados, por uma questo de organizao, de acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Esse agrupamento resultou em 4 diferentes classes de processos, que so: Processos fundamentais; Processo de apoio; Processos organizacionais; Processos de adaptao.

Processos fundamentais[editar]
Os processos fundamentais so necessrios para que um software seja executado. Eles iniciam o ciclo de vida e comandam outros processos. So eles: Aquisio: possui o propsito de obter o produto e/ou servio que satisfaa suas necessidades; Fornecimento: possui o propsito de prover um produto e/ou servio; Desenvolvimento: possui o propsito de transformar um conjunto de requisitos em um produto ou sistema de software; Operao: possui o propsito de operar o produto no seu ambiente e prover suporte aos usurios; Manuteno: possui o propsito de modificar o produto de software e depois dar liberao para o uso.

Processos de apoio[editar]
Os processos de apoio auxiliam outro processo. Eles so usados para garantir a qualidade, mas no so fundamentais. So eles: Documentao: possui o propsito de prover, manter um registro de informaes de software; Gerncia de configurao: possui o propsito de estabelecer e manter a integridade de todos os produtos de trabalho (artefato) de um processo do projeto; Garantia da qualidade: possui o propsito de prover garantia de que os produtos e processos esto em conformidade com o requisitos (padres/normas) pr-definidos; Verificao: possui o propsito de confirmar que os produtos e/ou servios refletem os requisitos especificados; Validao: possui o propsito de confirmar que os requisitos para o uso especfico de um produto e/ou servio so atendidos; Reviso conjunta: possui o propsito de manter o entendimento (gerencial comum com os stakeholders);

Auditoria: possui o propsito de determinar independentemente a conformidade dos produtos e processos contra os requisitos definidos; Resoluo de problema: possui o propsito de assegurar que todos os problemas levantados sejam analisados e resolvidos; Usabilidade; Contrato.

Processos organizacionais[editar]
Os processos organizacionais auxiliam a organizao e gerncia geral dos processos e podem ser empregados fora do domnio de projetos e contratos especficos, servindo para toda a organizao. So eles: Gerncia: possui o propsito de organizar, monitorar e controlar a iniciao e o desempenho dos processos; Infra-estrutura: possui o propsito de manter uma infra-estrutura estvel e confivel; Melhoria: possui o propsito de estabelecer, avaliar, controlar e melhorar um processo de ciclo de vida de software; Recursos humanos: possui o propsito de prover e manter recursos humanos adequados mantendo as suas capacitaes consistentes com o negcio; Gesto de ativos: possui o propsito de gerenciar a vida dos ativos (reusveis) desde a concepo at a desativao; Gesto de programa de reuso: possui o propsito de planejar, estabelecer, controlar, monitorar os programas de reuso; Engenharia de domnio: possui o propsito de desenvolver e manter modelos de domnio, arquiteturas e ativos deste domnio.

Processos de adaptao[editar]
Os processos so adaptveis a: Projeto; Organizao; Cultura; Modelo de ciclo de vida, mtodos e tcnicas, e linguagens.

Atividades do desenvolvimento[editar]
Algumas atividades importantes para o desenvolvimento de software sero descritas a seguir. So elas: Implementao; Levantamento de requisitos; Anlise dos requisitos do software; Projeto da arquitetura do software; Projeto detalhado do software; Codificao e testes do software; Integrao do software; Teste de qualificao do software; Instalao do software; Testagem e aprovao do software

Elas foram descritas com base na norma ISO/IEC 12207.

*****************************************************8 Este texto uma reviso bibliogrfica sobre a ISO 9000-3. Qualidade certamente um dos temas mais em moda ultimamente. Muito tem sido dito sobre este termo e nem sempre as pessoas tm tido o cuidado de estabelecer um significado preciso para ele. Segundo o dicionrio Aurlio, qualidade superioridade, excelncia de algo. J Pirsing, no clssico romance Zen e a arte de concertar motocicletas diz: Qualidade no pode ser definida, mais possvel saber o que qualidade. So aspectos de qualidade: unidade, vivacidade, autoridade, economia, sensibilidade, claridade, nfases, fluxo, brilhantismo, proporo,... Uma definio formal que muito citada na bibliografia que trata de qualidade a seguinte: Qualidade a totalidade das caractersticas de uma entidade que lhe confere a capacidade de satisfazer s necessidades expcitas e implcitas (NBR ISO 8402) Embora ela possa parecer muito sucinta, incrivelmente precisa. Outra definio muito citada de qualidade de software : Qualidade de software a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padres de desenvolvimento claramente documentados e a caractersticas implcitas que so esperadas de todo software profissionalmente desenvolvido (Pressman). Outras definies, mais gerais podem nos ajudar a formar um conceito mais amplo sobre qualidade. Podemos dizer que qualidade : estar em conformidade com especificaes, ou seja, quando os produtos possuem as caractersticas que esto descritas no projeto, catlogos ou listas de especificaes; saber que o preo que foi pago por algo, foi o preo justo. (Voc no reclama do preo pago, porque valeu a pena); a adequao para uso, ou seja, quando o produto corresponde ao esperado quanto a seu funcionamento; a presena de mercado, ou seja, quando o produto se destaca dos demais por preo, aparncia, contedo, marca ou qualquer outra razo.

************* Norma ISO 9241-11 Fornece informaes e procedimentos para especificar e avaliar a usabilidade. Explica como as medidas de desempenho e satisfaes dos usurios so usadas para medir componentes de sistemas

Definies e conceitos A usabilidade a capacidade de um produto ser usado por usurios especficos para alcanar objetivos especficos com eficcia, eficincia e satisfao em um contexto especfico de uso Definies e conceitos A eficcia a preciso com que os usurios alcanam objetivos especficos. A eficincia so os recursos gastos para atingir os objetivos especficos A satisfao a ausncia do desconforto e presena de pontos positivos O contexto so os usurios, tarefas, equipamentos e ambientes fsico e ambiental Especificando a usabilidade Os objetivos pretendidos, as caractersticas do usurio, as tarefas, os equipamentos e o contexto devem ser especificados e descritos para que possam ser reproduzidos nos testes.