Guilherme de Sá Gevaerd. Uma Ferramenta de Avaliação de Maturidade de Processo de Software Baseado no CMMI e MPS.BR

Transcrição

1 Guilherme de Sá Gevaerd Uma Ferramenta de Avaliação de Maturidade de Processo de Software Baseado no CMMI e MPS.BR Joinville 2009

2 Guilherme de Sá Gevaerd Uma Ferramenta de Avaliação de Maturidade de Processo de Software Baseado no CMMI e MPS.BR Relatório Final de Trabalho de Conclusão de Curso (TCC) apresentado ao Curso de Graduação em Ciência da Computação, da Universidade do Estado de Santa Catarina (UDESC), como requisito parcial a disciplina de Trabalho de Conclusão de Curso. Orientador: Prof. Edson Murakami Joinville 2009

3 Guilherme de Sá Gevaerd Uma Ferramenta de Avaliação de Maturidade de Processo de Software Baseado no CMMI e MPS.BR Relatório Final de Trabalho de Conclusão de Curso (TCC) apresentado ao Curso de Ciência da Computação da UDESC, como requisito para a obtenção parcial do grau de BACHAREL em Ciência da Computação. Aprovado em BANCA EXAMINADORA Prof. Edson Murakami Prof. Denio Duarte Prof. Luciana Rita Guedes

4 Resumo Um dos grandes desafios que as organizações vêm enfrentando é a pressão para desenvolver softwares de qualidade com esforços e custos cada vez menores. As experiências têm mostrado que as organizações que possuem processos de software baseados nas práticas de modelos de melhoria de processos como CMMI e MPS.BR têm conseguido reduzir ou eliminar estes problemas. Este trabalho consiste na definição e implementação de uma ferramenta para avaliação de maturidade de processo de software com base nos modelos CMMI e MPS.BR, que permitirá, de forma automática, mostrar o percentual de correlação entre os respectivos modelos. Palavras-chaves: CMMI, MPS.BR, avaliação de maturidade, processos de software.

5 Abstract One of the major challenges that organizations will face is the pressure to develop software with quality efforts and costs ever minors. Experiments have shown that organizations that have processes of software based practice models to improve the processes like CMMI and MPS.BR is to reduce or eliminate these problems. This work is the definition and implementation of a tool for assessing process maturity of software based the CMMI models and MPS.BR, which will in an automatic way to show the percentage of correlation between the their models. Keywords: CMMI, MPS.BR, assessment of maturity, the software processes.

6 Sumário Lista de Figuras 6 Lista de Tabelas 8 1 Introdução Objetivo Objetivos Específicos Metodologia Trabalhos Correlatos Organização do Trabalho CMMI Histórico Áreas de Atuação Representações do CMMI Estrutura do CMMI Componentes Obrigatórios Componentes Esperados Componentes Informativos MPS.BR Histórico Modelo Modelo de Referência MR-MPS Representação

7 3.4 Estrutura SCAMPI Classes SCAMPI Processo de Avaliação Planejamento e Preparação da Avaliação Condução da Avaliação Divulgação dos Resultados MA-MPS Histórico Processo de Avaliação Protótipo da Ferramenta Avaliação CMMI / SCAMPI Avaliação MPS.BR / MA-MPS Correlação Correlação MPS.BR Correlação CMMI Modelagem e Experimentação Ambiente Requisitos - Casos de Uso UCS01 - Realizar Avaliação UCS02 - Realizar correlação entre os modelos UCS03 - Gerar Gráficos - Resultados UCS04 - Realizar o mapeamento dos processos em relação ao modelo específico UCS05 - Cadastrar projetos

8 7.2.6 UCS06 - Cadastrar Modelos Análise e Design Arquitetura do Sistema Diagrama de Classe Diagrama de Sequência Implementação Design Conclusão Trabalhos Futuros Referências Bibliográficas 69

9 Lista de Figuras 2.1 Níveis da Representação Contínua Níveis da Representação Estagiada Representação Estagiada Representação Contínua Niveis de Maturidade MPS.BR [MPS.BR 2007] Componentes MPS.BR [MPS.BR 2007] Pirâmide com os níveis de maturidade do CMMI e MPS.BR Fases SCAMPI Exemplo de uma parte do protótipo para avaliação SCAMPI Sub-pratica Scampi B Scampi A MPS.BR Exemplo de uma parte do protótipo do MPS.BR Sub-Práticas MPS.BR Resultados Esperados MPS.BR Diagrama de Casos de Uso UCS UCS UCS UCS

10 7.6 UCS UCS Visão Lógica da Arquitetura para a avaliação Diagrama de classe para o CMMI Diagrama de classe para o MPS.BR Diagrama de sequência para a avaliação Diagrama de sequência para Realizar Correlação entre os modelos Diagrama de sequência para Gerar Gráficos (Resultados) Primeira tela da ferramenta Segunda tela da ferramenta, usada para o modelo CMMI Aba PID para o modelo CMMI Aba Avalição para o modelo CMMI Aba SCAMPI A para o modelo CMMI Aba SCAMPI B para o modelo CMMI Aba Relatório Geral para o modelo CMMI Aba Correlação para o modelo MPS.BR

11 Lista de Tabelas 2.1 Disciplinas abordadas pelo modelo CMMI Regras para caracterizar o Grau de implantação dos atributos de processo na organização [MPS.BR 2007] Caracterização das Sub-Prática do CMMI Caraterização de Práticas Específicas do CMMI Escala para caracterização do grau de implementação de um resultado esperado do processo e de atributos de processo nos projetos Regras para caracterizar os resultados esperados do MPS.BR Correlação GRE Correlação GRE Correlação GRE Correlação GRE Correlação GRE Correlação SP Correlação SP Correlação SP Correlação SP Correlação SP

12 9 1 Introdução No processo de desenvolvimento de qualquer serviço, é necessário seguir algumas etapas ordenadas contidas em um conjunto de tarefas. A esse conjunto de tarefas que envolvem atividades, restrições e recursos, com objetivo de alcançar uma saída desejada dá-se o nome de processo. Em um desenvolvimento de software pode-se definir que um processo é o conjunto de tarefas realizadas desde a sua concepção até a sua implementação, entrega, utilização e manutenção [Pfleeger 2004]. Diante do cenário tecnológico atual, os produtos de software têm atingido um crescimento considerável, tanto em tamanho quanto em complexidade, aumentando assim os problemas enfrentados em seu desenvolvimento. Assim, com objetivo de desenvolver produtos com o nível de qualidade exigido, faz-se necessária uma abordagem direcionada ao processo produtivo do software visando aperfeiçoar cada vez mais o ciclo de vida do software [Gomes, Oliveira e Rocha 2001]. Essa abordagem direcionada identifica os processos críticos para definir ações de melhorias e objetivos estratégicos, sendo auxiliada por modelos definidos como modelos de maturidade de processos. O conceito de maturidade vem da percepção de que empresas maduras desenvolvem projetos de maneira mais sistemática e atingem seus objetivos de forma consistente e eficiente em relação às imaturas. O modelo CMMI é estruturado em cinco níveis, onde cada nível caracteriza, por meio de uma avaliação, o estágio das capacidades em que se encontram os processos da organização [Siqueira 2007]. O CMMI define uma avaliação dos processos de uma organização a partir de áreas de processos, as PA s(process Area). Cada PA corresponde a um grupo de processos que, quando executados de modo coletivo, atingem um objetivo, proporcionando uma melhora significativa nesta área. O método de avaliação do modelo CMMI é denominado SCAMPI [Itaborahy et al. 2005]. O método SCAMPI tem como base a verificação dos Indicadores de Implementação na Prática (Practice Implementation Indication - PII), que é representado por artefatos diretos que representam a finalidade básica da realização da prática. Sem isto,

13 1 Introdução 10 a mesma não pode ser considerada realizada, e por artefatos indiretos que apóiam a realização da prática, reforçando a indicação da realização da prática; onde estes artefatos são produzidos pela execução do processo, ou por afirmações da organização avaliada [ITABORAHY 2005]. Outro modelo de qualidade de processo de software é o MPS.BR que é um programa para melhoria de processo do software, criado no Brasil que visa atender principalmente, as micros, pequenas e médias empresas. Está em desenvolvimento desde 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOF- TEX), onde conta também com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Este programa baseia-se no contexto de maturidade e capacidade de processo para avaliação e melhoria da qualidade e produtividade de produtos de software. É composto pelo Modelo de Referência (MR-MPS), o Método de Avaliação (MA-MPS) e o Modelo de Negócio (MN-MPS) [MPS.BR 2007]. O Método de Avaliação (MA-MPS) possui requisitos que são baseados na norma ISO/IEC , no ARC do CMMI e os específicos do modelo MPS.BR. Composto basicamente pelos requisitos e atividades dos métodos, indicadores para avaliação e características da qualificação dos avaliadores para o modelo. As atividades do método de avaliação são baseadas principalmente no método SCAMPI [Weber 2005], sendo assim possível fazer a correlação entre os mesmos. O presente trabalho é uma extensão do TCC que está implementando uma ferramenta de avaliação baseado no SCAMPI classe C [Carvalho 2008]. Neste contexto, este trabalho tem o objetivo de propor e implementar uma ferramenta que avalia a maturidade de processos de software baseado nos modelos de maturidade de processo CMMI e MPS.BR baseados no método de avaliação SCAMPI classes A e B e no MA-MPS. Essa ferramenta deverá permitir também a verificação da correlação entre os modelos. O escopo de implementação neste trabalho foi a avaliação de processos e correlação da área de processos Gerenciamento de Requisitos como é chamado no CMMI, e Gerência de Requisitos para o MPS.BR.

14 1.1 Objetivo Objetivo Objetivo geral: Desenvolvimento de uma ferramenta de código aberto para avaliação de maturidade em processos de software baseada nos modelos CMMI e MPS.BR, que permita verificar a correlação entre os respectivos modelos do npivel de maturidade de processo Gerenciamento de Requisitos Objetivos Específicos 1. Realizar um estudo dos modelos de melhoria de processos CMMI e MPS.BR para a contextualização do trabalho; 2. Realizar um estudo dos métodos de avaliação SCAMPI e MA-MPS para poder realizar a correlação entre os mesmos; 3. Realizar um estudo da área de processo Gerenciamento de Requisitos para fazer a correlação entre os modelos; 4. Fazer uma pesquisa dos trabalhos correlatos para ver o andamento das pesquisas neste contexto; 5. Propor um método de conversão entre os métodos SCAMPI e MA-MPS; 6. Definir arquitetura para desenvolvimento da ferramenta; 7. Desenvolver um protótipo para validar a proposta; 8. Implementar a ferramenta; 9. Realizar testes a fim de verificar a consistência e efetividade da ferramenta para a validação do modelo proposto; 1.2 Metodologia O desenvolvimento do trabalho será baseado no TCC em andamento [Carvalho 2008], que está realizando uma avaliação SCAMPI classe C e em um levantamento bibliográfico que serviu como base para o direcionamento do tema escolhido. Antes da implementação da ferramenta, foi desenvolvido um protótipo para validação da proposta

15 1.3 Trabalhos Correlatos 12 e por fim a implementação e utilização da ferramenta. Esse trabalho foi acompanhado e orientado pelo professor orientador que propôs as correções pertinentes a cada etapa do desenvolvimento. Onde as etapas de desenvolvimento forão desde estudo e pesquisa sobre os modelos CMMI e MPS.BR, seus respectivos métodos de avaliação SCAMPI e MA- MPS, a área de processo Gerência de Requisitos nos dois modelos até o desenvolvimentos dos protótipos e o da própria ferramenta. 1.3 Trabalhos Correlatos Existem várias ferramentas de avaliação como, a CMMI Quest v1.2 que atende as especificações do modelo CMMI com o método SCAMPI, e tem como objetivo o envio de relatórios da avaliação por meio de coleta de dados [HMandS 2006]. Existe também uma ferramenta para o modelo MPS.BR, que tem o objetivo de mostrar detalhadamente as atividades que devem ser alcançadas no nível G de maturidade do MPS.BR, obter um percentual dos graus de alcance de todo o processo de avaliação e auxiliar o avaliador na identificação das práticas que requerem maior investimento de esforços para melhoria de seus processos [Santos e Amorim 2007]. Existem diversas outras ferramentas, como as para o modelo SPICE, das quais podemos citar a PISA, a SEAL e a SPICE LITE [Xavier 2005], que não entram no contexto deste trabalho, pois tratam de um outro modelo de maturidade de software que é mais utilizado nos países da Europa. Entretanto, a maioria das ferramentas são proprietárias e não apresentam a funcionalidade de mostrar correspondência com outros modelos de maturidade, como se pretende fazer neste trabalho com CMMI e MPS.BR. A FAPS, uma ferramenta para apoiar uma avaliação integrada de processos de software que reúne os requisitos de modelos e normas de referência reconhecidos nacional e internacionalmente como os modelos MPS.BR, CMMI e a norma ISO/IEC em um único processo de avaliação. A ferramenta desenvolvida quando aplicada deve permitir que uma organização realize uma avaliação alinhada com os requisitos de todos os modelos e normas supraciados simultaneamente [Thiry et al. 2008].

16 1.4 Organização do Trabalho Organização do Trabalho A introdução do trabalho é apresentada no Capítulo 1, mostrando o objetivo do mesmo, com os objetivos específicos, a metodologia para sua realização, os trabalhos correlatos e a própria organização do trabalho. Nos Capítulos 2, 3, 4 e 5 apresentam os conceitos teóricos utilizados neste trabalho. Apresentando um breve histórico dos modelos CMMI e MPS.BR, suas estruturas, representação e seus métodos de avaliação SCAMPI e MA-MPS, respectivamente. Especificando como funciona o processo de avaliação de cada método, e os resultados esperados dos mesmos. A proposta para a ferramenta é apresentada no Capítulo 6, mostrando o protótipo desenvolvido para cada método de avaliação, uma avaliação específica para classe B e classe A do método SCAMPI, mais uma para o MA-MPS e também a correlação entre os modelos. Mostrando ainda um exemplo do funcionamento do protótipo em planilha para a área de processo Gerência de Requisitos e a correlação da mesma apresentada em tabelas correlacionando cada sub-prática. A modelagem e a implementação é apresentada no Capítulo 7, onde são expostos os casos de uso identificados para a ferramenta e também como ela funciona. As considerações finais são apresentadas no Capítulo 8, com a conclusão para o trabalho apresentado com base nos estudos e resultados alcançados com a implementação e os trabalhos futuros. Finalmente no Capítulo 9 são apresentadas as referências bibliográficas utilizadas na elaboração deste trabalho.

17 14 2 CMMI Diante da existência de inúmeros modelos de maturidade que ajudam na otimização dos processos em suas áreas específicas, existe o modelo CMMI (Capability Maturity Model Integration) que consiste das melhores práticas que envolvem o desenvolvimento e manuten- ção de produtos e serviços abrangendo o ciclo de vida do produto desde sua concepção até a entrega e manutenção. O projeto do CMMI foi realizado com intuito de evitar a utilização de múltiplos modelos (CMM s), sendo ele uma combinação dos modelos SW-CMM, modelo de maturidade voltado ao desenvolvimento de software, e SECM, modelo de maturidade para sistemas de engenharia. A combinação desses modelos originou um framework que engloba multiplas áreas sendo flexível o suficiente para suportar diferentes abordagens [Chrissis, Konrad e Shrum 2003]. 2.1 Histórico A necessidade de uma abordagem integrada para melhoria de processos surgiu em resposta à adoção de diversos modelos e normas de qualidade vigentes por parte das organizações. Como cada modelo tem uma área de aplicação específica, as organizações tinham que aplicar múltiplos modelos de qualidade para atender suas necessidades de negócio. Com essa experiência, ao longo dos anos, foi constatado que a manutenção de múltiplos modelos não é uma tarefa simples e se complica ainda mais devido a necessidade de treinamento do pessoal em diversos modelos de qualidade, bem como da aplicação de diversas metodologias de avaliação. Inevitavelmente os custos para a manutenção desse modelo são bem elevados. Diante deste cenário, em 1997 o SEI (Software Engineering Institute) foi incentivado e contou com a participação do USA Department of Defense (DoD) e do National Defense Industrial Association (NDIA) como principais parceiros no desenvolvimento do projeto CMMI, que surgiu com a proposta de realizar integração de diversos modelos de capacitação e maturidade, os CMM s, que já vinham sendo desenvolvidos desde 1991

18 2.2 Áreas de Atuação 15 [Filho 2005]. Os modelos de capacitação e maturidade integrados pelo CMMI são: The Capacibity Maturity Model for Software(SW-CMM) The Systems Engineering Capacibility Model(SECM) The Integrated Product Development Capability Maturity Model(IPD-CMM) 2.2 Áreas de Atuação Atualmente existem quatro disciplinas abordadas pelo modelo CMMI: engenharia de sistemas, engenharia de software, desenvolvimento integrado de processo e produtos e contratação de fornecedores [Chrissis, Konrad e Shrum 2003]. Os mesmos são apresentados na Tabela 2.1 com sua respectiva área de cobertura. Disciplinas Engenharia de Sistemas Engenharia de Software Desenvolvimento Integrado de Processo e Produto Contratação de Fornecedores Cobertura Cobre o desenvolvimento de sistemas completos, que podem ou não incluir software. Cobre o desenvolvimento de sistemas de software, com foco em abordagens sistemáticas, disciplinadas e quantificáveis para o desenvolvimento, operação e manutenção do software. Abordagem sistemática que possibilita a colaboração nos momentos corretos de atores relevantes ao desenvolvimento dirante a vida do produto. Cobre a aquisição de produtos de fornacedores. Tabela 2.1: Disciplinas abordadas pelo modelo CMMI 2.3 Representações do CMMI A representação para medir a melhoria de processo de software no CMMI pode ser de duas maneiras, contínua e a estagiada, onde cada uma utiliza um termo para

19 2.3 Representações do CMMI 16 representação, nível de capacidade e nível de maturidade, respectivamente. Independente de qual representação foi selecionada, o conceito de níveis é o mesmo. Os níveis caracterizam a melhoria de um estado mal definido até um estado que utiliza informações quantitativas para determinar e gerenciar melhorias que são necessárias para ir ao encontro dos objetos de negócio da organização. Para atingir um nível particular, uma organização deve satisfazer todos os objetivos apropriados da área de processo ou conjunto de áreas de processos independente se é nível de maturidade ou capacidade. O nível de capacidade pertence a representação contínua e é aplicado para atingir melhorias de processos organizacionais nas áreas de processo individuais. Existem seis níveis de capacidade, numerados de 0 a 5, como mostra a Figura 2.1. Figura 2.1: Níveis da Representação Contínua. De acordo com [Castro et al. 2006] são definidos os níveis de maturidade da representação contínua. 0 - incompleto: é um processo que não é executado ou é particularmente executado. Um ou mais dos objetivos específicos da área de processo não foram satisfeitos e não existe nenhum objetivo genérico para este nível, visto que não existe razão para institucionalizar um processo executado parcialmente. 1 - Executado: é um processo que satisfaz os objetivos específicos para a área de processo. Ele suporta e habilita o trabalho necessário para produzir produtos de trabalho. 2 - Gerenciado: é um processo executado que tem a infra-estrutura básica para suportar o processo. É executado e planejado de acordo com as políticas; emprega pessoas especialistas que possuem recursos adequados para produzir saídas contro-

20 2.3 Representações do CMMI 17 ladas; é monitorado, controlado e revisado; é avaliado pela aderência com a descrição do processo. 3 - Definido: é um processo gerenciado que é adaptado a partir de um conjunto de processos padrão da organização de acordo com as diretrizes de adaptação da organização e contribui com produtos de trabalho, medidas e outras informações de melhoria de processo para os ativos de processo da organização. 4 - Gerenciado Quantitativamente: é um processo definido que é controlado utilizando técnicas estatísticas ou quantitativas. Objetivos quantitativos para a qualidade e desempenho do processo são estabelecidos e utilizados como critério no gerenciamento do processo. A qualidade e desempenho do processo são entendidos em termos estatísticos e gerenciados através da vida do processo. 5 - Em otimização: é um processo gerenciado quantitativamente que é melhorado baseado em um entendimento de causas comuns de variação pertencentes ao processo. O foco de um processo em otimização é a melhoria contínua do desempenho do processo através de melhorias incrementais e inovadoras. O nível de maturidade pertence à representação por estágios e é aplicado para atingir melhorias de processos organizacionais através de múltiplas áreas de processo. Existem cinco níveis de maturidade, numerados de 1 a 5 como mostra a Figura 2.2. Figura 2.2: Níveis da Representação Estagiada. De acordo com [Castro et al. 2006] são definidos os níveis de maturidade da representação estagiada.1 - Inicial: os processos de nível 1 são geralmente ad hoc e caóticos. A organização normalmente não provê um ambiente estável que suporte

21 2.3 Representações do CMMI 18 os processos. O sucesso nessas organizações depende da competência e heroísmo das pessoas e não de processos experimentados. Nesse nível, as organizações freqüentemente produzem produtos que ainda se caracteriza pela tendência de excesso de comprometimentos, abandono do processo durante as crises e uma incapacidade de repetir os sucessos. 2 - Gerenciado: os projetos da organização tem assegurado que as requisições são gerenciadas e os processos são planejados, executados, medidos e controlados. A disciplina de processo refletida pelo nível de maturidade 2 ajuda a assegurar que praticas existentes são mantidas durante os tempos de crise. Quando estas práticas estão no lugar correto, os projetos são executados e gerenciados de acordo com os seus planos documentados. No nível 2, o status dos produtos de trabalho e a entrega de serviços são visíveis para o gerenciamento em pontos definidos. Comprometimentos são estabelecidos e revisados quando necessário. Os produtos de trabalho e serviços satisfazem as suas especificações de processos, padrões e procedimentos. 3 - Definido: os processos são bem caracterizados e entendidos e são descritos em padrões, procedimentos, ferramentas e métodos. O conjunto de processos padrão da organização que são a base para a maturidade nível 3, é estabelecido e melhorado periodicamente. Esses processos padrão são utilizados para estabelecer uma consistência através da organização. Os projetos estabelecem os seus processos definidos, adequando o conjunto de processos padrão da organização de acordo com as diretrizes organizacionais. Uma distinção critica entre os níveis de maturidade 2 e 3 é o escopo dos padrões, descrições dos processos e procedimentos. No nível 2, os padrões, as descrições dos processos e procedimento podem ser diferentes em cada instancia especifica do processo. No nível 3, os padrões, as descrições dos processos e procedimentos são adaptados a partir do conjunto de processos padrão da organização e são mais consistentes, exceto pelas diferenças permitidas pelo guia de adaptação. Outra diferença é que os processos descritos no nível 3 são mais rigorosos que o nível Quantitativamente Gerenciado: a organização e projetos estabelecem objetivos quantitativos para a qualidade e desempenho do processo e as utiliza como critério para gerenciamento de processos. Objetivos quantitativos são baseados nas necessidades dos clientes, usuários finais, organização e implementadores do processo. A qualidade e desempenho do processo são entendidos em termos estatísticos e são gerenciados durante a vida dos processos. As medidas de qualidade e desempenho do processo são incorporadas no repositório de medidas da

22 2.4 Estrutura do CMMI 19 organização para dar suporte a tomadas de decisão baseadas em fatos. Causas especiais de variação do processo são identificadas e, quando apropriado, as origens das causas são corrigidas para prevenir futuras ocorrências. Uma distinção critica entre maturidade nível 3 e 4 é a previsibilidade de desempenho do processo. No nível 4, o desempenho do processo é controlado utilizando técnicas estatísticas ou quantitativas e é quantitativamente previsível. No nível 3, os processos são somente previsíveis qualitativamente. 5 - Em otimização: uma organização melhora continuamente seus processos baseado em um entendimento quantitativo de causas comuns de variação pertencentes ao processo. A maturidade nível 5 foca na melhoria contínua de desempenho do processo através de um processo incremental, inovador e de melhorias tecnológicas. Os objetivos da melhoria de processo quantitativo para a organização são estabelecidos, continuamente revisados para refletir as mudanças dos objetivos de negocio e utilizados como critério no gerenciamento da melhoria do processo. Uma distinção entre os níveis de maturidade 4 e 5 é o tipo de variação do processo tratado. No nível 4, a organização esta preocupada com o tratamento de causas especiais da variação do processo e providenciar previsibilidade estatística dos resultados. Em- bora os processos possam produzir previsíveis, os resultados podem ser insuficientes para atingir os objetivos estabelecidos. No nível 5, a organização esta preocupada com o tratamento das causas comuns da variação e mudança do processo para me- lhorar o seu desempenho e atingir os objetivos de melhoria de processo quantitativos estabelecidos. 2.4 Estrutura do CMMI O CMMI está estruturado em sete componentes: Níveis de Maturidade, Áreas de Processo, Metas Específicas, Práticas Específicas, Meta Genérica, Práticas Genéricas e Características Comuns [Chrissis, Konrad e Shrum 2003]. A relação entre estes componentes pode ser observada nas Figuras 2.3 e 2.4, onde é mostrada a representação por estágio e a contínua, respectivamente. Os Níveis de Maturidade são um conjunto de patamares que são alcançados à medida que se evolui no processo de projeto. As Áreas de Processo são denominadas PA (Process Area). Cada PA possui

23 2.4 Estrutura do CMMI 20 Figura 2.3: Representação Estagiada. Figura 2.4: Representação Contínua.

24 2.4 Estrutura do CMMI 21 um conjunto de atividades relacionadas a uma determinada área que, quando realizadas adequadamente, atendem um conjunto de metas consideradas importantes para aumentar a capacidade desse processo Componentes Obrigatórios As Metas Específicas são utilizadas nas avaliações para ajudar a verificar se uma PA é satisfeita. As Metas específicas estabelecem as características que descrevem o que deve ser implementado para satisfazer uma PA. Uma Meta Genérica aparece repetidamente em muitas PAs. Na representação por estágios, cada PA possui apenas uma meta genérica. Atender a uma meta genérica significa obter um melhor controle para planejar e implementar os processos associados com a PA, portanto indicando que esses processos são efetivos, repetíveis e duráveis. As metas genéricas são componentes do modelo necessários e são usados nas avaliações para determinar se uma PA é atendida Componentes Esperados As Práticas Específicas correspondem ao nível mais detalhado de descrição. Uma prática específica é uma atividade considerada importante para auxiliar a atingir a meta específica à qual ela está ligada. As Práticas Genéricas estabelecem itens para garantir que o processo é treinado, disseminado, praticado por todos na organização (institucionalização). Enquanto as práticas específicas estabelecem as atividades especificas para cada PA, as genéricas cuidam da infra-estrutura que a organização precisa ter para garantir que o processo está realmente implantado. As Práticas Genéricas estão organizadas em quatro categorias distintas denominadas Características Comuns: compromissos, habilidades, diretivas de implementação e verificações. Essas características estabelecem as necessidades de institucionalização. Compromissos (commmitment to perform) - descrevem as ações que a organização deve realizar para se assegurar que o processo está estabelecido. Habilidades (ability to perform) - descreve as pré-condições que devem existir no

25 2.4 Estrutura do CMMI 22 projeto ou na organização para que o processo de software seja implementado competentemente. Diretivas de implementação (directing implementation) - refere-se às práticas relacionadas com o desempenho do processo, gerenciamento da integridade dos produtos de trabalho do processo, e envolvimento dos principais interessados. Verificação da Implementação (verifying implementation) - Descreve os passos para se assegurar que as atividades são realizadas em conformidade com o processo estabelecido Componentes Informativos Componentes informativos provêm detalhes que ajudam as organizaçoes a planejarem como utilizarão os componentes esperados e obrigatórios. Subpráticas, produtos de trabalho típicos, amplificaçoes de disciplinas, elaboração de práticas genéricas, títulos de objetivos e práticas, notas de objetivos e práticas e referências, são todos componentes do modelo informativo.

26 23 3 MPS.BR O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). A SOFTEX é uma entidade privada, sem fins lucrativos, que desenvolve ações de empreendedorismo, capacitação, financiamento e suporte à geração de negócios no Brasil e no exterior. 3.1 Histórico De acordo com [Prado 2000], as alterações que estão ocorrendo nos ambientes de negócios têm motivado as empresas a modificarem estruturas organizacionais e processos produtivos, saindo da visão tradicional baseada em áreas funcionais em direção a redes de processos centrados no cliente e com foco nos resultados. A competitividade depende, cada vez mais, do estabelecimento de conexões nestas redes, criando elos essenciais nas cadeias produtivas. Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Desta forma, assim como para outros setores, qualidade é fator crítico de sucesso para a indústria de software. Para que o Brasil tenha um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando à oferta de produtos de software e serviços correlatos conforme padrões internacionais de qualidade. Em 2003, no início da concepção do MPS.BR, dados da Secretaria de Política de Informática e Tecnologia do Ministério da Ciência e Tecnologia (MCT/SEITEC), mostravam que apenas 30 empresas no Brasil possuíam avaliação SW-CMM R (Capability Maturity Model): 24 no nível 2; 5 no nível 3; 1 no nível 4; e nenhuma no nível 5. A qualidade do processo de software no Brasil pode ser dividida em dois

27 3.1 Histórico 24 tipos de empresas, as micro, pequenas e médias empresa e as grandes empresas. Em [Prado 2000] é salientado que no topo da pirâmide, normalmente, estavam as empresas exportadoras de software e outras grandes empresas que desejavam atingir níveis mais altos de maturidade (4 ou 5) do CMMI-SE/SWSM por estágio e serem formalmente avaliadas pelo SEI (Software Engineering Institute), em um esforço que pode levar de 4 a 10 anos. Na base da pirâmide, em geral, encontrava-se a grande massa de micro, pequenas e médias empresas de software brasileiras, com poucos recursos e que necessitam obter melhorias significativas nos seus processos de software em 1 ou 2 anos. Segundo [MPS.BR 2007], a coordenação do Programa MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). Através destas estruturas, o MPS.BR obtém a participação de representantes de universidades, instituições governamentais, centros de pesquisa e de organizações privadas, os quais contribuem com suas visões complementares que agregam qualidade ao empreendimento. O FCC tem como principais objetivos assegurar que as Instituições Implementadoras (II) e Instituições Avaliadoras (IA) sejam submetidas a um processo adequado de credenciamento e que suas atuações não se afastem dos limites éticos e de qualidade esperados, além de avaliar e atuar sobre o controle dos resultados obtidos pelo MPS.BR. Por outro lado, cabe à ETM exercer sobre os aspectos técnicos relacionados ao Modelo de Referência (MR-MPS) e Método de Avaliação (MA-MPS), tais como a concepção e evolução do modelo, elaboração e atualização dos guias do MPS.BR, preparação de material e definição da forma de treinamento e de aplicação de provas, publicação de relatórios técnicos e interação com a comunidade visando à identificação e aplicação de melhores práticas [MPS.BR 2007].) O foco principal do MPS.BR, embora não exclusivo, está nas pequenas e médias empresas. Busca-se que ele seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também espera-se que o MPS.BR seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras, estando em consonância

28 3.2 Modelo 25 com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software. 3.2 Modelo As normas ISO/IEC e ISO/IEC foram usadas como base técnica para definir o modelo MPS.BR. Considerando a importância do modelo CMMI para organizações brasileiras que atuam em mercados internacionais, também foi considerado o CMMI como um complemento técnico para a definição dos processos do modelo MPS.BR [MPS.BR 2007] Modelo de Referência MR-MPS De acordo com o [MPS.BR 2007], o modelo de referência MR-MPS é documentado sob a forma de três guias: o Guia Geral do MPS.BR, o Guia de Aquisição do MPS.BR e o Guia de Implementação do MPS.BR. O Guia Geral provê uma definição geral do modelo MPS.BR. O MR-MPS está em conformidade com a norma ISO/IEC 15504, satisfazendo os requisitos para modelo de referência de processos definidos na ISO/IEC [MPS.BR 2007]. Os processos do MR-MPS são descritos em função de seu propósito e dos resultados esperados de uma implementação bem sucedida, que, por sua vez, são utilizados para avaliar a implementação. Cada processo definido no MR-MPS tem um conjunto de resultados necessário e suficiente para atingir o propósito do processo. Os processos do MR-MPS são uma adaptação dos processos da norma ISO/IEC e suas emendas e são compatíveis com as áreas de processo do CMMI-DEV. O MR-MPS define sete níveis de maturidade de processos para organizações que produzem software: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). O nível G é o primeiro estágio de maturidade e o nível A é o mais maduro. Cada um dos níveis de maturidade possui um conjunto de processos e atributos de processos que indicam onde a unidade organizacional tem que colocar esforço para melhoria, de forma a atender aos seus objetivos de negócio e ao MR.MPS

29 3.3 Representação 26 [MPS.BR 2007]. 3.3 Representação Os objetivos e práticas do MPS.BR estão distribuídos em sete níveis de maturidade que vão do nível G, parcialmente gerenciado, até o A, em otimização [MPS.BR 2007] e [MPS.BR 2007]. De acordo com [Weber 2008], os níveis de maturidade são definidos em duas dimensões: a dimensão de capacidade de processos e a dimensão de processos. A dimensão de capacidade de processos do MR-MPS é constituída de um framework de medição. Dentro do framework, a medida da capacidade é baseada em um conjunto de atributos de processo (AP). O MR-MPS, em total conformidade com a ISO/IEC , define nove AP: AP 1.1 (o processo é executado), AP 2.1 (o processo é gerenciado), AP 2.2 (os produtos de trabalho do processo são gerenciados), AP 3.1 (o processo é definido), AP 3.2 (o processo está implementado), AP 4.1 (o processo é medido), AP 4.2 (o processo é controlado), AP 5.1 (o processo é objeto de inovações), AP 5.2 (o processo é otimizado continuamente). Cada AP contém um conjunto de resultados de atributo de processo (RAP) utilizados para avaliar a implementação de um AP. A dimensão de processo do MR-MPS é constituída do conjunto de processos que deve ser avaliado para o nível de maturidade pretendido. A Figura 3.1 mostra os níveis de maturidade do MR-MPS, apresentando os processos e atributos de processos de cada nível. [Weber 2008] destaca que o primeiro nível de maturidade é o G (Parcialmente Gerenciado) que é composto pelos processos mais críticos de gerência. De modo a melhorar o controle dos projetos, a organização deve implementar processos de apoio para o desenvolvimento de software. Estes processos constituem o próximo nível do MRMPS, o F (Gerenciado). O nível E (Parcialmente Definido) possui o conjunto de processos que apóiam a institucionalização e melhoria de processos padrão para guiar projetos de software. Com a infra-estrutura para execução e melhoria de processos estabelecida na organização, o próximo passo é focar na melhoria de processos de engenharia de software mais técnicos. Estes são os processos de engenharia, agrupados no nível de maturidade D (Largamente Definido). O nível C é composto por processos de engenharia de software complementares à gerência de projetos. Adicionalmente, o processo Desenvolvimento para

30 3.3 Representação 27 Figura 3.1: Niveis de Maturidade MPS.BR [MPS.BR 2007] Reuso foi inserido a fim de possibilitar o estabelecimento de um programa de reutilização para desenvolver ativos e artefatos através da engenharia de domínio, em consonância com as definições da ISO/IEC Emenda 1. Por fim, os níveis de maturidade B e A são os de alta maturidade focando na melhoria contínua de processos. A adoção de um nível de maturidade significa a obtenção de um grau de melhoria nas competências para a realização de um conjunto de tarefas ou atividades onde todos os objetivos são atendidos. O uso de níveis de maturidade possibilita estabelecer patamares de evolução e indicar onde a organização deve direcionar esforços. Todo o processo de evolução do nível de maturidade MPS.BR é cumulativo e crescente de maneira que para se obter um nível superior é requerido que se possua obrigatoriamente todos os seus níveis predecessores. Uma correspondência entre os níveis de maturidade do MR-MPS e CMMI pode ser delineada. A organização diferente dos níveis de maturidade no MR-MPS tem dois motivos: i) prover um caminho para o aumento da maturidade ao reduzir o número de processos a serem implementados nos primeiros níveis de maturidade; ii) dar visibilidade

31 3.4 Estrutura 28 aos resultados da melhoria de processos em um tempo menor. 3.4 Estrutura Conforme Vasquez (2005), toda a base técnica utilizada para construção do MPS.BR está em conformidade com os requisitos internacionais, pois é baseada nas normas ISO/IEC 12207, ISO/IEC também conhecida como Software Process Improvement and Capability determination (SPICE) e CMMI-SE/SWSM, que referem-se à qualidade de software, o que faz do MPS.BR um modelo completamente aderente às normas internacionais. De acordo com o MPS guia (2006), o MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. Dentro desse contexto, o MPS.BR possui três componentes: o Modelo de Referência (MR-MPS), o Método de Avaliação (MA-MPS) e o Modelo de Negócio (MN-MPS), que estão descritos por meio de documentos em formato de guias conforme apresenta a Figura 3.2. Figura 3.2: Componentes MPS.BR [MPS.BR 2007] Os Guias são apresentados a seguir: Guia Geral: contém a descrição geral do MPS.BR e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação.

32 3.4 Estrutura 29 Guia de Implementação: série de sete documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS. Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito de forma a apoiar as instituições que queiram adquirir produtos de software e serviços correlatos. Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). Após o término da apresentação dos modelos de maturidade de processo de software CMMI e MPS.BR, pode-se identificar a correlação entre os modelos de acordo com os níveis de maturidade de processo de cada modelo mostrados na Figura 3.3, que por exemplo o nível 2 do CMMI é representado pelo F e G do MPS.BR.Nos próximos capítulos será exposto os métodos de avaliação dos respectivos modelos, o SCAMPI e o MA-MPS. Figura 3.3: Pirâmide com os níveis de maturidade do CMMI e MPS.BR

33 30 4 SCAMPI Standard CMMI Appraisal Method for Process Improvement (SCAMPI) é um método de avaliação para o modelo CMMI. O SCAMPI tem como objetivo determinar o nível de aderência de um processo na organização às praticas do CMMI. A avaliação é feita de forma colaborativa por uma equipe que é liderada por um avaliador autorizado pelo SEI e possui três classes de avaliação: A, B e C. A escalação e adequação de cada classe permitem que as mesmas sejam sobrepostas. Estas sobreposições permitem aumentar o nível de detalhamento e abrangência da avaliação. O método SCAMPI é apropriado para as organizações que querem comparar os resultados alcançados de seus processos de melhorias com outras do mesmo ramo. Isto pode ser realizado pois ao final da avaliação é determinado o nível de maturidade alcançado pela empresa [Team 1997]. 4.1 Classes SCAMPI Uma avaliação SCAMPI de classe A satisfaz todos os requisitos para uma avaliação CMMI. Ela possibilita a identificação de pontos fortes e fracos dentro dos processos, priorizar os planos de melhoria, focar nas melhorias mais benéficas à organização e identificar os riscos de aquisição ou desenvolvimento em relação ao modelo CMMI [Team 1997]. As avaliações de Classe B e C tem a intenção de apoiar no foco das aplicações individuais tanto para multi-eventos, melhorias posteriores, aquisição ou consultas. Aplicados progressivamente, as três classes de avaliação podem ser adaptadas para fortalecer a integração dos dados das avaliações futuras [Hayes et al. 2005]. A avaliação Classe C tem o foco na aderência ao modelo. Ao final da avaliação é medida a fidelidade das práticas da empresa com o modelo CMMI. As práticas são avaliadas sem a preocupação com a implementação e sim com o que as pessoas fazem e planos para implementações futuras. É uma preparação para a avaliação Classe A. As práticas são classificadas em Fidelidade Alta, Fidelidade Médio ou Fidelidade Baixa[Carvalho 2008].

34 4.1 Classes SCAMPI 31 A avaliação classe B avalia o estado do desenvolvimento de novos projetos por meio de avaliações incrementais monitorando a implementação empresarial preparando para uma busca por melhoria. O resultado do SCAMPI B é uma caracterização de riscos das práticas adotadas. Ela serve para determinar o grau de risco para se conseguir passar em uma avaliação SCAMPI classe A. As práticas são classificadas em: Alto Risco, Média Risco ou Baixo Risco[Carvalho 2008]. A avaliação Classe A é focada na institucionalização. O resultado é uma caracterização das práticas de modo a qualificar àquelas que levam a objetivos satisfatórios e torná-las institucionalizadas[carvalho 2008]. O escopo deste trabalho para o método de avaliação SCAMPI é focado nas classes A e B. O SEI define institucionalização como a maneira impregnada de fazer negócio que uma organização segue rotineiramente como parte de sua cultura corporativa. Este conceito é mencionado nos componentes genéricos (objetivos e práticas) indicando que o trabalho é realizado e que existe comprometimento e consistência na realização do processo, isto é assegurando um processo repetitível, consistente e duradouro[filho 2005]. De acordo com [Filho 2005] método SCAMPI é embasado principalmente na verificação de dados fornecidos pela organização como evidências objetivas da implementação das práticas. Além das três formas de coleta de dados definidas no ARC (instrumentos, documentação e entrevistas), o SCAMPI também considera apresentações como dados válidos para avaliação. Os dados coletados como evidências objetivas são classificados pelo método como Indicadores de Implementação das Práticas (PIIs) que são: Artefatos Diretos: Fornecem evidencias diretas tangíveis como resultados da implementação das praticas. São os resultados objetivados explicitamente pelas praticas do modelo e a principal fonte de dados para discernimento sobre a cobertura de tais práticas. Os artefatos diretos são comprovados pelos outro dois tipos de indicadores. Alguns exemplos são: Produtos típicos de trabalho Produto alvo das práticas específicas que envolvem estabelecer e manter Documentos, produtos, materiais de treinamento, entre outros. Artefatos Indiretos: são conseqüências da implementação de uma pratica mas não

35 4.2 Processo de Avaliação 32 são contemplados como seu principal objetivo. Segue alguns exemplos: Produtos típicos de trabalho, os auxiliares, não os principais mas que também são listados nos modelos Relatórios de reuniões, resultados de revisões, relatórios de status, métricas de performance, entre outros. Afirmações: informações orais ou escritas fornecidas pelos stakeholders que suportam ou confirmam a implementação das práticas. Respostas de questionários, entrevistas e apresentações são exemplos deste tipo de PII. 4.2 Processo de Avaliação O método SCAMPI consiste em 3 fases: Planejamento e Preparação da Avaliação, Condução da Avaliação e Divulgação dos Resultados. Cada fase é subdividida em outras etapas que serão descritas a seguir juntamente com suas estradas e saídas, conforme a- presentadas em [Filho 2005]. As etapas e suas subdivisões podem ser observadas na Figura 4.1. Figura 4.1: Fases SCAMPI

36 4.2 Processo de Avaliação Planejamento e Preparação da Avaliação A base de uma avaliação SCAMPI está na verificação dos Indicadores de Implementação de Prática (Practice Implementation Indicators - PII), representados por artefatos diretos e indiretos produzidos pela execução do processo, ou por afirmações da organização avaliada, que equivalem a artefatos indiretos. Os artefatos diretos representam a finalidade básica da realização da prática, sem eles a prática não pode ser considerada realizada. Os artefatos indiretos apóiam a realização da prática, embora não sejam sua finalidade principal. Sua existência reforça a indicação de realização da prática. As afirmações são representadas por declarações orais ou escritas, colhidas em entrevistas e questionários, ou apresentações realizadas pela organização aos avaliadores, que confirmem a realização de uma prática [Itaborahy et al. 2005]. Análise de requisitos O principal objetivo deste processo consiste na definição dos objetivos da avaliação alinhados com os objetivos da organização. O líder da equipe de avaliação auxilia o patrocinador nesta tarefa. As entradas (requisitos, restrições iniciais e informações do processo) são analisadas e os objetivos da avaliação são sumarizados, conjuntamente com o escopo da organização e do modelo e outras informações, no documento de Entrada da Avaliação. As demais entradas envolvem replanejamento e redefinição desses elementos e, consequentemente, exigem reformulação do referido documento. Desenvolvimento do plano de avaliação O segundo processo dessa fase tem como objetivo desenvolver o Plano de Avaliação e tem como principal entrada a Entrada da Avaliação. Os participantes da avaliação também são contemplados e relatados no plano, assim como, a revisão inicial das evidências objetivas que influenciam na definição do cronograma, custo e riscos associados a avaliação. Seleção e preparação da equipe Este processo consiste na identificação e treinamento (ou certificação de que os membros já são devidamente qualificados) da equipe de avaliação. Suas entradas

37 4.2 Processo de Avaliação 34 principais são o plano de avaliação e materiais de treinamento da equipe. Após a execução deste processo todos os membros da equipe serão identificados e estarão aptos a executar a avaliação. como: Diversas restrições sobre a composição da equipe são impostas pelo método O líder da avaliação deve ser autorizado pelo SEI. Experiência em anos média e total da equipe de avaliação. Realização de cursos de treinamento do SEI nos modelos do CMMI. Número de integrantes. Obtenção e análise de evidência de objetivo inicial O conjunto de evidências objetivas iniciais (PIIs) é a principal entrada deste processo, a partir da qual a equipe de avaliação realiza revisão inicial e determina se os aspectos definidos no Plano de Avaliação (e consequentemente na Entrada da Avaliação) são satisfatórios diante da cobertura de dados apresentada. Os resultados desta revisão são fornecidos para a próxima fase que planejará a coleta dos demais dados necessários para alcançar a cobertura desejada e, caso necessário, para os processos Analisar Requisitos e Desenvolver Plano de Avaliação para replanejamento. Os participantes da avaliação identificados, que serão responsáveis pelo fornecimento dos dados para a equipe da avaliação, também são preparados nesta etapa. É contemplada também, a administração dos instrumentos (vistorias, questionários, base de dados de evidências objetivas, descrição das PIIs, etc.) com os quais os participantes podem contar para fornecer os dados à equipe de avaliação. Preparação para a coleta de evidência de objetivo O último processo da fase de preparação e planejamento envolve a verificação de que a avaliação pode ser conduzida a partir da revisão das evidências objetivas realizada no processo anterior; e a produção e replanejamento do Plano de Coleta de Dados que sumariza as estratégias a serem seguidas na fase de Condução da Avaliação

38 4.2 Processo de Avaliação Condução da Avaliação Nesta fase o ponto principal consiste na investigação focada das evidências objetivas. A principal preocupação desta fase é obter dados suficientes para cobertura do escopo do modelo selecionado e obter uma amostra representativa da aplicação contínua do processo que deverá cobrir as fases do ciclo de vida que a organização utiliza. Exame de evidência de objetivo As evidências objetivas são examinadas e relacionadas as práticas do modelo e as atividades são regidas pelo Plano de Coleta de Dados. Verificação e validação de evidência de objetivo Nesta etapa é realizada a verificação da implementação das práticas para cada instância do processo e validação das descobertas preliminares (draft ou preliminary findings), junto a membros da organização, descrevendo brechas (gaps) que demonstram os pontos fracos na implementação das práticas do modelo. Documentação de evidência de objetivo As notas produzidas pela equipe de avaliação ao longo da verificação dos dados são consolidadas, a presença/ausência de evidências objetivas para as práticas do modelo registradas, e os pontos fracos (gaps) das práticas implementadas são documentados. Geração de resultados de avaliação As caracterizações das práticas são baseadas no consenso da equipe da avaliação e definem a extensão da implementação das práticas para a organização. A partir das caracterizações para o nível organizacional a pontuação para satisfação dos objetivos pode ser derivada neste processo e sucessivamente as pontuações de nível de maturidade ou nível de capacitação.

39 4.2 Processo de Avaliação Divulgação dos Resultados Nesta última etapa os resultados da avaliação são divulgados para o patrocinador e para a organização avaliada. Os resultados são incorporados ao Registro da Avaliação de acordo com o nível de sigilo desejado pelo patrocinador, definido na primeira fase. O Relatório da Avaliação é encaminhado ao SEI e adicionado a uma base de dados que sumariza os perfis de maturidade e capacitação da comunidade. Entrega de resultados de avaliação Este processo compreende a apresentação dos resultados (descobertas finais e ADS) para o patrocinador e a organização. O ADS(Appraisal Disclosure Statement) consiste num sumário que descreve as pontuações geradas como saídas da avaliação e as condições e restrições sob as quais a avaliação foi realizada. Arquivamento das informações de avaliação Este processo endereça a manipulação final dos dados da avaliação contemplado o que deve ser mantido no Registro da Avaliação e quais dados devem ser arquivados ou descartados da maneira apropriada de acordo com o nível de proteção requisitado pelo patrocinador. Um Relatório da Avaliação é preparado para ser enviado ao SEI.

40 37 5 MA-MPS O MA-MPS é um documento Guia de Avaliação e descreve o Método de Avaliação para melhoria de Processo de Software (MA-MPS) e é composto basicamente pelos requisitos do método, atividades do método, indicadores para avaliação e características da qualificação dos avaliadores. Este método permite a realização de avaliações em unidades organizacionais segundo o modelo MPS [MPS.BR 2007]. 5.1 Histórico Os requisitos do MA-MPS são baseados nos requisitos do método de avaliação definidos na norma ISO/IEC , os requisitos definidos no ARC do CMMI e os requisitos específicos do Projeto MPS.BR. Desta forma, o método é compatível com a ISO/IEC e ARC do CMMI e, adequado às pequenas e médias empresas. As atividades do método de avaliação são baseadas principalmente no método Standard CMMI Appraisal Method for Process Improvement (SCAMPI) [ SEI 2001], com elementos dos métodos QuickLocus [Koran 2003] e MARES [Anacleto 2004]. 5.2 Processo de Avaliação Uma avaliação tem início quando o patrocinador da avaliação seleciona uma Instituição Avaliadora (IA) credenciada pela SOFTEX, para realizar a avaliação. Posteriormente, são formadas mini-equipes para realizar a avaliação através dos projetos concluídos e em andamento de uma organização. Em seguida, é realizada a confecção dos documentos contendo os resultados dessa avaliação que terá validade de três anos [MPS.BR 2007]. Segundo a ISO/IEC uma avaliação deve ser conduzida com base em dados definidos de entrada para a avaliação utilizando um Modelo de Avaliação de Processo conforme a um ou mais Modelos de Referência de Processo. Para satisfazer os requisitos da ISO/IEC para um Modelo de Avaliação de Processo, a Equipe Técnica do

41 5.2 Processo de Avaliação 38 Modelo (ETM) definiu o método de avaliação MA-MPS e o documentou na forma de um Guia de Avaliação do MPS. Este guia descreve também um processo de avaliação para apoiar a aplicação do MA-MPS. O objetivo do método de avaliação MA-MPS descrito no Guia de Avaliação é verificar a maturidade de uma unidade organizacional na execução dos seus processos de software. Através da investigação e identificação das atividades realizadas e avaliadas por uma organização é possível obter o grau de implementação das práticas possibilitando definir o nível de maturidade. A Tabela 6.3 apresenta as regras que caracterizam o grau de implementação dos resultados esperados no MPS.BR e também a porcentagem de implementação dos resultados. Caracterização Existe evidência de um enfoque completo e sistemático para o atributo no processo avaliado e de sua plena implementação. Não existe pontos fracos relevantes para este atributo no processo avaliado Existe evidência de um enfoque sistemático e de um grau significativo de implementação do atributo no processo avaliado. Existem pontos fracos para este atributo no processo avaliado Existe alguma evidência de um enfoque para o atributo e de alguma implementação do atributo no processo avaliado. Alguns aspectos de implementação não são possíveis de predizer. Existe pouca ou nenhuma evidência de implementação do atributo no processo avaliado. Grau de Implementação Totalmente Implementado (T) Largamente Implementado (L) Parcialmente Implementado (P) Não Implementado (N) Porcentagem de Implementação dos resultados relacionados 85% a 100% 50% a 85% 15% a 50 % 0% a 15 % Tabela 5.1: Regras para caracterizar o Grau de implantação dos atributos de processo na organização [MPS.BR 2007].

42 39 6 Protótipo da Ferramenta Para entender melhor como funciona cada método de avaliação e poder obter a correlação entre os métodos de avaliação de maneira mais fácil, foi analisado como funciona cada método obtendo parâmetros para correlacioná-los, assim foi desenvolvido três protótipos para a ferramenta. Um para o método de avaliação SCAMPI, outro para o MA-MPS e ainda um outro para realizar a correlação entre os modelos. A seguir serão apresentados os protótipos dos métodos de avaliação citados. 6.1 Avaliação CMMI / SCAMPI O protótipo desenvolvido para o projeto tem a finalidade de caracterizar as áreas de processo de uma organização. Como o presente trabalho é uma continuação do TCC do Rogério [Carvalho 2008], foi utilizado o mapeamento das áreas de processo já realizada, o qual definiu o mapeamento da avaliação SCAMPI classe C que verifica a aderência ao modelo CMMI. Neste trabalho foi feita uma avaliação SCAMPI B que define o grau de risco de participar de uma avaliação SCAMPI A. Já o SCAMPI A avalia o grau de institucionalização dos processos da organização em um determinado nível. A Figura 6.1 mostra uma parte do protótipo desenvolvido e do Processo Organizacional, com as respectivas caracterizações das práticas do processo avaliado. A avaliação é dada com o mapeamento do modelo, que no caso é o CMMI, onde possui um processo organizacional para verificar se determinada sub-prática gerou o template necessário para sua validação, onde o template é o documento, a prova para ser gerada a partir da atividade estabelecida pela sub-prática, que pode ser um artefato direto ou indireto, como mostra na Figura 6.1 na aba do Processo Organizacional. O processo de avaliação inicia-se verificando se determinado template existe e está em determinado local, assim atribui-se 1 caso esteja presente e julgado como adequado, 0 caso esteja ausente ou julgado como inadequado e caso não possua um artefato direto ou indireto, este processo da avaliação encontra-se na coluna com o número 1 na Figura 6.1. Outro ponto a ser analisado é se existe Afirmação Verbal, onde a avaliação é definida com 1

43 6.1 Avaliação CMMI / SCAMPI 40 Figura 6.1: Exemplo de uma parte do protótipo para avaliação SCAMPI para presente e 0 para ausente e encontra-se na coluna com o número 2 na Figura 6.1. É analisado também os Pontos Fracos que são definidos do mesmo modo que a Afirmação Verbal, encontrando-se a avaliação na coluna 3 da Figura 6.1 onde é apresentado a caracterização de cada sub-prática na coluna Caracterização. Ao final desses passos, para cada sub-prática, se tem as respectivas caracterizações, onde na Tabela 6.1 mostra como se dá a caracterização de cada sub-prática. Com o preenchimento dos artefatos diretos e indiretos, afirmação verbal e o ponto fraco é dado a caracterização de cada sub-prática, e automaticamente das metas com o resultado das sub-práticas. De acordo com as especificações mostradas na Tabela 6.2. Com estes resultados é apresentado a plotagem de gráficos ao usuário. A Figura 6.2 mostra a caracterização das sub-práticas da área de processo Gerenciamento de Requisitos, que possui um total de 17 sub-práticas. A Figura 6.3 mostra o percentual de aderência no método de avaliação SCAMPI B, mostrando o grau de risco de se ir para uma avaliação classe A e a Figura 6.4 mostra o grau de institucionalização das Práticas Especificas (SP) da área de processo Gerenciamento de Requisitos que possui 5 SP s.

44 6.1 Avaliação CMMI / SCAMPI 41 Figura 6.2: Sub-pratica Figura 6.3: Scampi B Figura 6.4: Scampi A

45 6.1 Avaliação CMMI / SCAMPI 42 Caracterização Significado Completamente Implementado (CI) Artefato(s) direto(s) presente(s) e julgado(s) como adequado(s); Ao menos um artefato indireto e/ou afirmação existente para confirmar a implementação; Nenhum ponto fraco substancial observado. Largamente Implementado (LI) Artefato(s) direto(s) presente(s) e julgado(s) como adequado(s); Ao menos um artefato indireto e/ou afirmação existente para confirmar a implementação; Um ou mais pontos fracos substancias observados. Parcialmente Implementado (PI) Artefato(s) direto(s) ausente(s) ou julgado(s) como inadequado(s); Artefatos indiretos ou afirmação sugerem que alguns aspectos da prática são implementados; Pontos fracos foram documentados. Não Implementada (NI) Qualquer outra situação. Não Aplicável (NA) Quando a prática não está preenchida. Tabela 6.1: Caracterização das Sub-Prática do CMMI. Condição Resultado Observações Todas X X Todas instâncias tem a mesma caracterização; Todas LI ou CI LI Todas instâncias caracterizadas com LI ou CI; Qualquer PI, sem NI LI ou PI A equipe decide a escolha de LI ou PI para a organização; Qualquer NI NI, PI ou LI A equipe decide a escolha de NI, PI ou LI para a organização. Tabela 6.2: Caraterização de Práticas Específicas do CMMI.

46 6.2 Avaliação MPS.BR / MA-MPS Avaliação MPS.BR / MA-MPS O protótipo desenvolvido para o MA-MPS teve que, antes de tudo, ser mapeado o processo a ser avaliado, que no caso foi o Gerência de Requisitos (GRE) com as práticas do modelo MPS.BR. Está área de processo é a que está sendo utilizada para realizar os devidos testes nos protótipos. O mapeamento do modelo se dá através de Resultados Esperados, onde no CMMI é através de Práticas Específicas (SP). Também foi analisado um modo de extrair o produto e as sub-práticas de cada Resultado Esperado do Guia de Implementação do MPS.BR, para assim poder obter melhor a correlação com o método de avaliação SCAMPI. A Figura 6.5 mostra como ficou a modelagem de um Resultado Esperado da área de processo Gerência de Requisitos. Figura 6.5: MPS.BR Após o mapeamento do modelo foi feito a parte do processo organizacional, onde se evidencia se o que foi especificado nos Resultados Esperados foi gerado, sendo caracterizado como artefato direto ou indireto como no CMMI. Em seguida inicia-se a avaliação, que verifica se determinada evidencia existe e está em determinado local, assim atribui-se 1 caso esteja presente e julgado como adequado, 0 caso esteja ausente ou julgado como inadequado e caso não possua um artefato direto ou indireto, este processo da avaliação é mostrado na coluna 1 em vermelho na Figura 6.6. Outro ponto que se tem que analisar é a Afirmação Verbal, que é definida com 1 para presente e 0 para ausente. E também se analisa o Ponto Fraco que é definido do mesmo modo que a Afirmação Verbal, onde são mostrados nas colunas 2 e 3 em vermelho na Figura 6.6, respectivamente. Um ponto que no MA-MPS é diferente na avaliação é que possui mais um campo para ser preenchido, que determina se o Resultado Esperado está fora do escopo da avaliação, onde um x representa que está fora do escopo e o que não e pode ser observado na coluna Fora de Foco da Figura 6.6. A Figura 6.6 mostra como ficou o protótipo da parte do Processo Organizacional e a Avaliação de um resultado esperado.

47 6.2 Avaliação MPS.BR / MA-MPS 44 Figura 6.6: Exemplo de uma parte do protótipo do MPS.BR Com a avaliação concluída para cada sub-prática, a mesma recebe uma caracterização. A Tabela 6.3 mostra como se dá a caracterização de cada sub-prática. Grau de Implementação Totalmente Implementado (T) Largamente Implementado (L) Parcialmente Implementado (P) Não Implementado (N) Não Avaliado (NA) Fora de escopo (F) Caracterização O indicador direto está presente e julgado como adequado; Existe pelo menos um indicador direto e/ou afirmação confirmando a implementação; Não foi notada nenhum ponto fraco substancial. O indicador direto está presente e é julgado como adequado; Existe pelo menos um indicador indireto e/ou afirmação confirmando a implementação; Foi notado um ou mais pontosfracos substanciais. O indicador direto não está presente ou é julgado inadequado; Artefatos ou afirmações sugerem que alguns aspectos do resultado esperado estão implementados; Pontos fracos foram documentadas. Qualquer situação diferente das acima. O projeto não está na fase de desenvolvimento que permite atender ao resultado ou não faz parte do escopo do projeto atender ao resultado. O resultado esperado está fora do escopo da avaliação, conforme documentado no plano da avaliação. Tabela 6.3: Escala para caracterização do grau de implementação de um resultado esperado do processo e de atributos de processo nos projetos Para a caracterização de um resultado esperado no MA-MPS usa-se determi-

48 6.3 Correlação 45 nadas regras que são apresentadas na Tabela 6.4 de acordo com o [MPS.BR 2007]. Onde estas regras servem para caracterizar os resultados esperados de um projeto, determinando o grau de implementação de uma área de processo em uma organização. Com a avaliação realizada pode ser mostrado a plotagem de gráficos para uma melhor visualização das práticas implementadas. A Figura 6.7 mostra a caracterização das sub-práticas de acordo com o método de avaliação MA-MPS da área de processo Gerenciamento de Requisitos, que possui um total de 15 sub-práticas. A Figura 6.8 mostra a caracterização dos resultado esperado. Figura 6.7: Sub-Práticas MPS.BR Figura 6.8: Resultados Esperados MPS.BR 6.3 Correlação O protótipo desenvolvido para representar a correlação entre os modelos foi definido verificando os produtos e sub-práticas de cada modelo. Onde que para o modelo MPS.BR foi realizado um modo de extrair os produtos e sub-práticas de cada Resultado Esperado do Guia de Implementação do próprio MPS.BR, para obter uma melhor correlação com o modelo CMMI.

49 6.3 Correlação 46 Caracterização nos projetos avaliados Todas X (isto é, todos T, P, ou N) Todos os projetos terminados X (isto é, todos T, L, P ou N) e os incompletos NA (Não Avaliado) Caracterização Observações agregada para a unidade organizacional X Se todos os projetos têm a mesma caracterização, esta é a caracterização da unidade organizacional; X Se pelo estágio de desenvolvimento dos projetos incompletos o resultado não puder ser evidenciado (NA), a caracterização da unidade organizacional é X; Todos T ou L L Se os projetos forem caracterizados para um resultado esperado como L ou T, caracteriza-se a unidade organizacional como L para este resultado esperado; Todos T ou L e os incompletos NA (Não Avaliado) L Se pelo estágio de desenvolvimento dos projetos incompletos o resultado não puder ser evidenciado, a caracterização da unidade organizacional é L; Existem P, mas não existem L ou P A decisão é da equipe de avaliação; N (Pode existir NA - Não Avaliado) Existe N N, P ou L A decisão é da equipe de avaliação; Resultado esperado F (Fora do escopo) F O resultado esperado foi declarado fora do escopo da avaliação no plano da avaliação. Tabela 6.4: Regras para caracterizar os resultados esperados do MPS.BR Para a Área de Processo Gerenciamento de Requisitos, pode-se realizar uma correlação quase que diretamente. O modelo CMMI possui 5 Práticas Específicas (Spe-

50 6.3 Correlação 47 cific Practice) nomeadas como SP 1.1, SP 1.2, SP 1.3, SP 1.4 e SP 1.5, contendo 17 sub-práticas no total. Já o MPS.BR trabalha com Resultados Esperados e não Práticas Específicas como na CMMI, mas também possui 5 Resultados Esperados, onde são nomeados como GRE 1, GRE 2, GRE 3, GRE 4 e GRE 5, que foram extraidas 15 sub-práticas. Onde a diferença das sub-práticas será explicado pelas Práticas Específicas e Resultados Esperados, mostrando a correlação dos produtos e sub-práticas nas tabelas, onde as duas primeiras colunas são referentes ao modelo CMMI e as outras duas correspondem ao MPS.BR Correlação MPS.BR A correlação para o modelo MPS.BR é realizada a partir de uma avaliação CMMI, sendo que o projeto já tem que estar avaliado para se obter a correlação. Deste modo as sub-práticas dos modelos são relacionadas conforme as Tabelas 6.5, 6.6, 6.7, 6.8 e 6.9. MPS.BR CMMI Tabela 6.5: Correlação GRE 1 MPS.BR CMMI , , 6 Tabela 6.6: Correlação GRE Correlação CMMI A correlação para o modelo CMMI é realizada a partir de uma avaliação MPS.BR, sendo que o projeto já tem que estar avaliado para se obter a correlação. Deste

51 6.3 Correlação 48 MPS.BR CMMI Tabela 6.7: Correlação GRE 3 MPS.BR CMMI 10 14, Tabela 6.8: Correlação GRE 3 MPS.BR CMMI , 10 Tabela 6.9: Correlação GRE 3 modo as sub-práticas dos modelos são relacionadas conforme as Tabelas 6.10, 6.11, 6.12, 6.13, e CMMI MPS.BR Tabela 6.10: Correlação SP 1.1 Quando ocorreu de uma sub-prática nessecitar de mais de uma sub-prática para ser atendida. Por exemplo, quando duas sub-prática do CMMI estiverem correlacionadas com uma do MPS.BR, com o contrário também sendo válido, de acordo com o caracterização das duas será caracterizado a do MPS.BR, para isso utilizou-se o mesmo

52 6.3 Correlação 49 CMMI MPS.BR , 6 Tabela 6.11: Correlação SP 1.2 CMMI MPS.BR Tabela 6.12: Correlação SP 1.3 CMMI MPS.BR Tabela 6.13: Correlação SP 1.4 CMMI MPS.BR Tabela 6.14: Correlação SP 1.5 método para caracterizar as Práticas Específicas do modelo CMMI, que pode ser verificado na Tabela 6.2. E para obter a correlação do MPS.BR para o CMMI utilizou o mesmo método para caracterizar os Resultados Esperados, conforme a Tabela 6.4. Deste modo a correlação pode ser efetuada.

53 50 7 Modelagem e Experimentação No presente capítulo são apresentadas as etapas de modelagem, implementação e testes com a ferramenta no ambiente proposto. Os conceitos necessários já foram vistos, podendo assim serem realizadas. 7.1 Ambiente O ambiente foi desenvolvido na linguagem de programação Java, utilizando o banco de dados MySQL para armazenar os dados referentes as avaliações de cada modelo. Foi utilizado implementação em camadas, e criada uma camada de persistência aos dados, que é a parte responsável por se conectar ao banco de dados e selecionar, extrair, inserir e atualizar as informações no banco. 7.2 Requisitos - Casos de Uso Visando o desenvolvimento da ferramenta de avaliação foram definidos alguns casos de uso, que nada mais são que funcionalidades do sistema. A Fugura 7.1 o Diagrama de Casos de Uso da ferramenta, sendo que os que estão em vermelho são o escopo para o desenvolvimento da ferramenta, pois são os principais para validação da proposta da ferramenta. Nas sub-seções seguintes serão apresentados os casos de uso identificados para a ferramenta proposta, mostrando mais detalhes para a avaliação dos modelos CMMI e MPS.BR e para a correlação entre os mesmos que foram definidos no escopo UCS01 - Realizar Avaliação 1 - Descrição: este caso de uso é para realizar a avaliação de determinada sub-prática, atividade. Onde são adicionados, avaliados os Artefatos Diretos e Indiretos, Afirmações Verbais e Pontos Fracos. A caracterização das sub-práticas é dada de acordo com cada modelo a partir da avaliação dos artefatos diretos e indiretos, a afirmação verbal e os pontos fracos para o CMMI e para o MPS.BR adicionando se é fora de escopo.

54 7.2 Requisitos - Casos de Uso 51 Figura 7.1: Diagrama de Casos de Uso Seguindo regras de negócio específicas de cada modelo. Para a avaliação de determinado projeto caracterizando as Práticas Específicas para o modelo CMMI e Resultados Esperados para o MPS.BR. Onde está avaliação é feita a partir das caracterizações das sub-práticas correspondentes a cada Prática Específica ou Resultado Esperado. Figura 7.2: UCS Fluxo de Eventos: Fluxo Básico: Realizar Avaliação 1. O usuário seleciona o modelo para realizar a avaliação entre o modelo CMMI e MPS.BR; 2. O usuário seleciona o projeto para ser avaliado; 3. O sistema recupera a avaliação para o projeto; 4. O usuário seleciona a sub-prática ou Prática Específica(Resultado Esperado) para ser avaliada; 5. O sistema exibe o formulário com listas para adicionar os indicadores de implementação prática;

55 7.2 Requisitos - Casos de Uso O usuário preenche os indicadores de implementação prática; 7. O sistema calcula e exibe o resultado [A01][A02][A03][A04]; 8. O usuário solicita a gravação da avaliação [A05]; 9. O caso de uso é encerrado. Fluxo alternativo [A01] - Caracterização das Sub-Práticas CMMI 1. O sistema realiza a caracterização e exibe o resultado [RN01]; 2. Retorna ao fluxo básico. [A02] - Caracterização das Sub-Práticas MPS.BR 1. O sistema realiza a caracterização e exibe o resultado [RN02]; 2. Retorna ao fluxo básico. [A03] - Caracterização das Práticas Especificas CMMI 1. O sistema recupera a caracterização das Sub-Práticas; 2. O sistema realiza a caracterização e exibe o resultado [RN03]; 3. Retorna ao fluxo básico. [A04] - Caracterização dos Resultados Esperados MPS.BR 1. O sistema recupera a caracterização das Sub-Práticas; 2. O sistema realiza a caracterização e exibe o resultado [RN04]; 3. Retorna ao fluxo básico. [A05] - Erro de gravação 1. O sistema exibe mensagem de erro; 2. Retorna ao passo 4 do fluxo básico. 3 - Pré Condições: Não existem. 4 - Pós Condições: Caracterizações realizadas. 5 - Regras de Negócio:

56 7.2 Requisitos - Casos de Uso 53 [RN01] Caracterização das Sub-Práticas do modelo CMMI apresentado na Tabela 6.1. [RN02] Caracterização das Sub-Práticas do modelo MPS.BR apresentado na Tabela 6.3. [RN03] Caracterização das Práticas Específicas do modelo CMMI apresentado na Tabela 6.2. [RN04] Caracterização dos Resultados Esperados do modelo MPS.BR apresentado na Tabela UCS02 - Realizar correlação entre os modelos 1 - Descrição: este caso de uso realizará a correlação entre os modelos, gerando um gráfico para apresentar o percentual de correlação. A correlação da área de processo Gerenciamento de Requisitos foi dada a partir de cada sub-prática dos modelos, correlacionando as Práticas Específicas do modelo CMMI com os Resultados Esperados do MPS.BR. Figura 7.3: UCS Fluxo de Eventos: Fluxo Básico: Realizar Correlação entre os Modelos 1. O usuário seleciona o modelo para realizar a avaliação; 2. O usuário seleciona o projeto para ser avaliado; 3. O usuário seleciona a correlaçao; 4. O sitema correlaciona as sub-práticas; 5. O sistema calcula e gera o resultados [B01][B02] 6. O sistema gera o gráfico;

57 7.2 Requisitos - Casos de Uso O caso de uso é encerrado. Fluxo alternativo [B01] - Correlação do CMMI com o MPS.BR 1. O sistema realiza a caracterização das sub-práticas correlacionadas [RN01]; 2. Retorna ao fluxo básico. [A02] - Correlação do MPS.BR com o CMMI 1. O sistema realiza a caracterização das sub-práticas correlacionadas [RN02]; 2. Retorna ao fluxo básico. 3 - Pré Condições: Não existem. 4 - Pós Condições: Correlações realizadas. 5 - Regras de Negócio: [RN01] Caracterização das sub-práticas que possuem mais que uma sub-prática correlacionada. Caracterização conforme a Tabela 6.4. [RN02] Caracterização das sub-práticas que possuem mais que uma sub-prática correlacionada. Caracterização conforme a Tabela UCS03 - Gerar Gráficos - Resultados 1 - Descrição: a geração dos gráficos é dada de acordo com a caracterização das sub-práticas, que por si caracterizam uma prática específica, no caso do CMMI e para o MPS.BR caracterizam os resultados esperados, onde é gerado um gráfico com a porcentagem das caracterizações da área processo UCS04 - Realizar o mapeamento dos processos em relação ao modelo específico 1 - Descrição: mapear os processos da empresa, fazendo uma amarração com o modelo e o projeto específico, definindo os artefatos diretos e indiretos de cada processo,

58 7.3 Análise e Design 55 Figura 7.4: UCS03 podendo Incluir, Alterar, Excluir e Consultar. Figura 7.5: UCS UCS05 - Cadastrar projetos 1 - Descrição: este caso de uso cadastra projetos de uma empresa para poder realizar uma avaliação. Incluir, Excluir, Alterar e Consultar projetos. Figura 7.6: UCS UCS06 - Cadastrar Modelos 1 - Descrição: este caso de uso cadastra o modelo específico, no caso do desde a Área de Processo, Objetivos Específicos, Práticas Específicas, Produtos e Sub-Práticas. E para o MPS.BR a Área de Processo, os Resultados Esperados, Produtos e Sub-Práticas. 7.3 Análise e Design Esta seção transforma os requisitos em um design do sistema a ser implementado, desenvolvendo a arquitetura e adaptando o design para que corresponda as

59 7.3 Análise e Design 56 necessidades da ferramenta. Figura 7.7: UCS Arquitetura do Sistema A arquitetura da ferramenta foi implementada na linguagem de programação JAVA em três camadas, sendo elas, camada de apresentação(view), negócio e dados. Estas camadas devem funcionar de maneira que o software executado em cada uma delas possa ser substituído sem prejuízo ao sistema, isto é, quando algo for corrigido em uma camada não afete as demais. A Figura 7.8 mostra o modelo da arquitetura utilizada para o caso de uso realizar avaliação. Onde a camada de apresentação é a interface da ferramenta, como interage com o usuário, a camada de negócio contém as regras de negócio, as funcionalidades do sistema e camada de dados é onde faz as requisições com o banco de dados. Figura 7.8: Visão Lógica da Arquitetura para a avaliação Para implementar a ferramenta foram utilizadas diversas tecnologias. A interface gráfica foi utilizada a API(Apllication Program Interface) de desenvolvimento

60 7.3 Análise e Design 57 SWING, que é uma API alto nível, sendo mais abstrata. Para mostrar a área de processo na tela para o usuário foi utilizado uma JTree, apresentando a área de processo em forma de árvore, com nós e folhas. A geração do gráfico de resultados foi feito com o JFreeChart, que é uma biblioteca para geração de diversos tipos de gráficos. Para o acesso a SGBD(Sistemas Gerenciadores de Banco de Dados) foi utilizado a API JDBC. Onde não é necessário desenvolver aplicações específicas para cada banco de dados, pois a programação do sistema é a mesma Diagrama de Classe O Diagrama de Classe apresenta as classes e como elas se relacionam em um sistema. A Figura 7.9 mostra o diagrama de classe utilizado para implementação da ferramenta de avaliação para o modelo CMMI. A Figura 7.10 mostra o diagrama de classe para o MPS.BR, onde a principal diferença entre o CMMI se dá no próprio modelo, e não na avaliação, podendo assim ser utilizadas as mesmas classes para a avaliação. Figura 7.9: Diagrama de classe para o CMMI Diagrama de Sequência O Diagrama de Sequência apresenta uma interação de mensagens trocadas entre objetos e classes em um determinado contexto ao longo do tempo. Registrando o

61 7.4 Implementação 58 Figura 7.10: Diagrama de classe para o MPS.BR comportamento de um único caso de uso. Realizar Avaliação - A Figura 7.11 apresenta o Diagrama de Sequência para o caso de uso UCS01. Realizar Correlação entre os Modelos - A Figura 7.12 apresenta o Diagrama de Sequência para o caso de uso UCS02. Gerar Gráficos (Resultados) - A Figura 7.13 apresenta o Diagrama de Sequência para o caso de uso UCS Implementação Nesta seção é descrito o processo de utilização da ferramenta. Apresentando os passos para realizar a avaliação e a correlação com a ferramenta, onde primeiramente escolhe-se em uma tela o modelo com que se deseja fazer a avaliação, CMMI ou MPS.BR. Conforme a Figura Selecionado o modelo, na próxima tela, são mostradas à esquerda as áreas de processo do modelo escolhido, que no caso do CMMI apresenta a Área de Processo, os

62 7.4 Implementação 59 Figura 7.11: Diagrama de sequência para a avaliação

63 7.4 Implementação 60 Figura 7.12: Diagrama de sequência para Realizar Correlação entre os modelos Figura 7.13: Diagrama de sequência para Gerar Gráficos (Resultados)

64 7.4 Implementação 61 Figura 7.14: Primeira tela da ferramenta Objetivos Específicos(SG), Práticas Especificas(SP) e Sub-Práticas com suas descrições, produtos e atividades. Para o MPS.BR apresenta a Área de Processo, os Resultados Esperados e as Sub-Práticas com suas descrições, produtos e atividades. É possível selecionar os projetos cadastrados para serem avaliados, e também para mostrar os já avaliados. A Figura 7.15 mostra como ficou a tela. A tela também possui abas, uma para realizar o PId, que cadastra o caminho que comprova a existência do Artefato Direto e do Indireto de cada Sub-Prática, sendo a mesma selecionada na árvore da área de processo, como é mostrado na Figura Outra aba é onde se realiza a avaliação propriamente dita, que inclui adicionar e excluir Artefatos Diretos e Indiretos, Afirmações Verbais e Pontos Fracos dando suas respectivas avaliações, mostrando uma legenda para a avaliação, com 0 para ausente e 1 para presente. Com estes itens avaliados é mostrada na mesma tela a caracterização de cada Sub-Prática avaliada, e com as mesmas avaliadas para o CMMI mostra também a caracterização de cada Prática Específica, que caracteriza os Objetivos Específicos, caracterizando até a Área de Processo, e para o MPS.BR mostra a caracteriazação dos Resultados Esperados e também da Área de processo, de acordo com o que está selecionado na árvore, como pode ser observado na Figura Sendo está caracterização dada de acordo com as regras e caracterizações de cada modelo apresentadas anteriormente.

65 7.4 Implementação 62 Figura 7.15: Segunda tela da ferramenta, usada para o modelo CMMI Figura 7.16: Aba PID para o modelo CMMI

66 7.4 Implementação 63 Também possui na tela um botão salvar, para gravar no banco de dados as informações das avaliações de cada Sub-Prática e Projeto que está sendo avaliado, que pode ser verificado na Figura Figura 7.17: Aba Avalição para o modelo CMMI A ferramenta possui outras abas que são Resultados, Relatório Geral e Correlação para o modelo MPS.BR e SCAMPI A, SCAMPI B, Relatório Geral e Correlação para o CMMI, que apresentadam resultados em forma de gráficos. A dos Resultados é igual a representação do SCAMPI A apresenta um gráfico da avaliação da caracterização dos Resultados Esperados e das Práticas Específicas, como pode ser observado na Figura Para o CMMI ainda possui a aba para o SCAMPI B, que mostra o grau de risco para se conseguir passar em uma avaliação SCAMPI A, como mostra a Figura Para verificar a caracterização de todas as sub-práticas do modelo selecionado é só clicar na aba Relatório Geral, que pode ser visualizado na Figura Outra aba apresenta a correlação entre os modelos, apresentando o resultado como na Figura 7.21, mas apresentando a correlação ao outro modelo. Por exemplo, se fizer a avaliação do CMMI, mostrará a correlação com o MPS.BR, utilizando o método proposto de correlação exposto na seção 6.3, sendo o contrário também válido.

67 7.4 Implementação 64 Figura 7.18: Aba SCAMPI A para o modelo CMMI Figura 7.19: Aba SCAMPI B para o modelo CMMI

68 7.4 Implementação 65 Figura 7.20: Aba Relatório Geral para o modelo CMMI Figura 7.21: Aba Correlação para o modelo MPS.BR