Mapeando a Metodologia Catalysis em relação ao CMMI

Transcrição

1 Mapeando a Metodologia Catalysis em relação ao CMMI Cleber Augusto Pivetta, Felipe Ricardo Zottis, Gustavo Mantovani Victor F. Araya Santander, Elder Elisandro Schemberger UNIOESTE - Universidade Estadual do Oeste do Paraná Rua Universitária, Jardim Universitário. Caixa Postal CEP Cascavel, PR {cleberpivetta,rpguto}@yahoo.com.br {elderes,frzottis}@gmail.com,vfasantander@unioeste.br Resumo. Este artigo tem o objetivo de mapear a metodologia de desenvolvimento baseado em componentes Catalysis em relação ao modelo de avaliação de maturidade CMMI (Capability Maturity Model Integration). Este mapeamento permite observar como a metodologia estudada pode satisfazer as áreas chaves de cada nível do CMMI, além de fornecer as organizações que utilizam esta metodologia uma forma de verificar o processo de desenvolvimento visando à qualidade do software produzido. 1. Introdução O processo de desenvolvimento de software é uma área em constante evolução, na qual diversas metodologias de projeto têm surgido com o intuito de auxiliar na organização e na gerência do processo de engenharia de software, a fim de gerar produtos software de alta qualidade. A necessidade de se produzir software de qualidade tem exigido dos desenvolvedores cada vez mais estudos aprofundados e aperfeiçoamentos objetivando a utilização de técnicas e ferramentas da área de engenharia de software da melhor forma possível. Dentre as principais metodologias de desenvolvimento de software, destacam-se as que consideram o desenvolvimento baseado em componentes [1]. Estas têm como perspectivas de desenvolvimento a concepção e implementação de componentes que possam ser posteriormente reutilizados, bem como o desenvolvimento de aplicações a partir de componentes pré-construídos. Neste contexto, a metodologia Catalysis é amplamente utilizada pela forma que incorpora conceitos, procedimentos e notações que facilitam a identificação e generalização de componentes, além do aproveitamento de componentes existentes. O presente artigo visa estudar esta metodologia contrastando com os níveis de maturidade do CMMI (Capability Maturity Model Integration) a partir de um mapeamento que demonstra como a metodologia Catalysis satisfaz cada área chave do CMMI. Este artigo está organizado da seguinte forma. A Seção 2 apresenta algumas características importantes para garantir a reusabilidade de um componente, bem como uma breve descrição das quatro fases de desenvolvimento da metodologia Catalysis. A Seção 3 apresenta uma visão geral do CMMI descrevendo objetivamente seus cinco 118

2 níveis de maturidade. A Seção 4 apresenta uma comparação entre as áreas chaves de cada nível do CMMI e a metodologia Catalysis como forma de avaliação e discussão da qualidade do processo. Finalmente, na Seção 5 encontram-se as considerações finais obtidas frente a este trabalho, bem como uma breve discussão sobre trabalhos futuros. 2. Desenvolvimento Baseado em Componentes O desenvolvimento baseado em componentes (DBC) pode ser caracterizado pela utilização de partes já desenvolvidas ou pelo desenvolvimento de partes independentes que são integradas para atingir algum objetivo [2]. Esta abordagem possibilita um suporte ao rápido desenvolvimento, pois as aplicações podem ser desenvolvidas a partir de componentes pré-fabricados reduzindo consideravelmente o tempo de produção do software. Além disso, uma coleção cada vez maior de componentes de software estará disponível para os desenvolvedores, promovendo a reutilização de software. Uma das maiores vantagens desta abordagem está em promover o reuso. Contudo reutilizar componentes pode ser considerado um desafio. Segundo Brow [3], um componente deve possuir três características para garantir a reusabilidade. 1. Separação da especificação da implementação: no desenvolvimento baseado em componentes a especificação é separada de como ele é implementado, permitindo que as implementações sejam alteradas sem impactar o sistema. Logo, um componente pode se adaptar prontamente a novos requisitos de operação; 2. Encapsulamento de dados e processos: o acesso às funcionalidades de um componente está limitado às operações fornecidas por sua interface, o que diminui o impacto das mudanças de algum componente; 3. Independência de tecnologia de componentes: o modelo deve ser detalhado para que o código possa ser gerado para uma variedade de plataformas. Isso deve reduzir os custos de implementação da mesma implementação em outras plataformas. Neste contexto cabe destacar o Catalysis, uma metodologia de desenvolvimento baseado em componentes que engloba todas as fases do ciclo de vida do sistema, desde a especificação até a implementação. Este método não define uma seqüência rígida de passos no processo de desenvolvimento, mas um conjunto de conceitos que orientam o desenvolvedor no sentido de adaptar estas idéias da melhor forma em seu projeto. O Catalysis define quatro fases de desenvolvimento, conforme segue [4]: a) Especificação de Requisitos: Esta fase do processo está focada no entendimento do problema, bem como a delimitação do contexto do sistema, a definição dos requisitos (funcionais e não funcionais) [5] e questões organizacionais. São utilizadas algumas técnicas especificas para descrever o modelo de negócios e requisitos do projeto. O mind map é uma representação informal da estrutura dos principais termos e conceitos que estão relacionados. Tem por objetivo obter uma visão geral do comportamento do sistema e suas funcionalidades. O diagrama de contexto identifica os atores no domínio e suas interações. Este diagrama tem por objetivo mostrar ao desenvolvedor quais são as 119

3 operações do sistema e quais atores estão relacionados a fim de executá-las. O cenário mostra a sequência de passos ou tarefas inseridas em uma ação no sistema. Normalmente é utilizado para ações não descritas no diagrama de contexto. b) Especificação do Sistema: Esta fase descreve o comportamento externo do sistema. Procura-se modelar soluções de software para os modelos de domínio previamente identificados na especificação de requisitos. É obtida nesse estágio a especificação dos tipos do sistema, a qual contém o modelo de tipos (atributos e associações) e o conjunto de ações relacionadas a este modelo. São desenvolvidas nesta fase as especificações de operações, snapshots e modelos de tipos. A especificação de operação define as pré e pós condições em termos de entrada e atributos do objeto. Os snapshots mostram o subconjunto de valores de atributos que existem antes e depois da execução de uma operação descrita nos cenários, ou seja, a representação dos efeitos de uma operação. Os modelos de tipo identificam cada ação do sistema, especificando-a como uma operação sobre o tipo. Representa a interação com outros tipos e as operações no qual o tipo interage. c) Projeto de Arquitetura: O objetivo desta fase é a implementação interna do sistema, composta por duas partes relacionadas: a arquitetura da aplicação e a arquitetura técnica. A arquitetura da aplicação implementa a lógica do negócio como uma coleção de componentes que se colaboram. É uma descrição de um conjunto de ações entre um grupo de objetos. A arquitetura técnica mostra a colaboração entre componentes de tecnologia e as dependências estáticas. Abrange todas as partes independentes de domínio como hardware e plataforma de software, banco de dados, ferramentas entre outras. d) Projeto Interno de Componentes: O objetivo desta fase é definir uma estrutura interna, bem como suas interações que satisfaçam requisitos tecnológicos, comportamentais e de engenharia de software para cada componente. São desenvolvidos diagramas de classes, interação e de estados. O diagrama de interação especifica a interação dos objetos para atingir o resultado de uma operação. Para cada operação especificada, o objeto que recebeu a requisição deve ser identificado. O diagrama de estados representa os estados de uma classe, no caso do Catalysis, correspondem aos estados de uma operação. O diagrama de classes consiste das classes que compõe o sistema, seus atributos e operações, e as associações entre elas. 3. CMMI Muitos problemas de desenvolvimento de software foram evidenciados durante as décadas de 60 e 70, período que ficou conhecido como Crise do Software [6]. Dentre as principais causas desta crise pode-se citar: a inexistência de métricas de construção de software e a imprecisão quanto a cronogramas e custos envolvidos no projeto [7]. Este fato justificou a necessidade da criação de padrões de qualidade de desenvolvimento de software, para que as empresas desenvolvedoras pudessem garantir aos seus clientes um produto final de qualidade, atendendo as expectativas destes. O CMMI (Capability Maturity Model Integration) desenvolvido pelo SEI (Software Engineering Institute) [8] constitui um modelo de referência que determina 120

4 um conjunto de processos a fim de representar uma norma de qualidade de software bem como de seus processos de desenvolvimento e suas evoluções. Os processos definidos pelo CMMI visam estabelecer graus de maturidade à uma empresa desenvolvedora de software, bem como critérios e providências necessárias para a evolução desta [7]. O modelo CMMI é reconhecido como um padrão internacional que consolida as melhores experiências da indústria no desenvolvimento de software. Pode-se classificar uma empresa em cinco níveis (de 0 a 5) diferentes de qualidade. Estes por sua vez possuem sub-áreas denominadas KPA s (Key Process Areas Áreas Chaves de Processos) que devem ser implementadas para que um nível seja atingido [8]. No nível 1, denominado Inicial, o desenvolvimento é caótico, ou seja, seus processos não são definidos e muitas vezes são abandonados devido suas dificuldades. O sucesso e a qualidade do produto final dependem estritamente das habilidades individuais dos desenvolvedores. Todo o processo de desenvolvimento é caracterizado como uma caixa preta, pois existe clareza somente em suas fases inicial e final [7] [9]. O nível 2, Repetível, é caracterizado por repetir práticas de desenvolvimento que foram realizadas com sucesso em projetos anteriores. Processos administrativos básicos são estabelecidos e acompanhados para que custos e prazos estipulados sejam respeitados. Todo o processo de desenvolvimento funciona como uma sequência de caixas pretas, onde em cada uma delas encontram-se atividades e artefatos que auxiliam na construção do projeto. Assegura-se no processo todo que ao menos entre as caixas pretas um feedback do andamento do projeto seja estipulado [7] [9]. No nível 3, chamado Definido, existe um processo de desenvolvimento de software bem definido pela empresa, onde para cada desenvolvedor, ou equipe, são atribuídas funções especificas. Os gerentes asseguram que os objetivos de cada equipe ou elemento sejam cumpridos. A caixa preta existente nos níveis anteriores passa a ser neste uma caixa aberta, pois é possível entender e documentar todo o processo de desenvolvimento de software [7] [9]. O nível 4, Quantitativamente Gerenciado, é caracterizado pelo levantamento estatístico da qualidade de atividades e artefatos encontrados durante o desenvolvimento de software. Com base nisto torna-se possível identificar quais áreas estão alavancando ou atrasando o projeto, bem como as causas disto. No nível 5, Otimizado, a empresa focaliza melhorias contínuas no desempenho do desenvolvimento como um todo através de melhorias incrementais e inovações tecnológicas. Estas melhorias são possíveis de implementar devido ao levantamento estatístico realizado durante o nível 4 [7] [9]. 4. Mapeando a metodologia Catalysis em relação aos níveis de maturidade do CMMI Uma das principais preocupações de desenvolvedores e gerentes de projeto está em desenvolver produtos com qualidade de forma rápida e eficaz. Neste sentido é importante analisar como a metodologia Catalysis permite que os níveis de maturidade do CMMI podem ser obtidos. Mais especificamente é importante avaliar as áreas de 121

5 processo chave e como as respectivas metas podem ser satisfeitas. A seguir é realizada esta avaliação. Nível 2 (Gerenciado) sobre Catalysis Áreas Chaves Metas Catalysis Gestão de Requisitos Planejamento de Projeto Monitoramento e Controle de Projeto Gestão de Contrato com Fornecedor Medição e Análise Gerenciar os requisitos. São definidos os requisitos do sistema, bem como sua documentação e controle. Planos, produtos e atividades devem estar condizentes com os requisitos definidos. Estabelecer estimativas para uso no planejamento e acompanhamento do projeto. Elaborar um plano de projeto onde todas as atividades e compromissos assumidos são planejados e documentados. Obter comprometimento da equipe em relação a seus compromissos. Monitorar o projeto em relação ao plano. Acompanhamento dos resultados do projeto confrontandoos com o planejamento. Gerenciar ações corretivas até o encerramento se ocorrer desvios significativos de planejamento. Alterações devem ser realizadas em comum acordo da equipe. Estabelecer acordos com o fornecedor. Deve-se planejar e determinar estes acordos. Satisfazer os acordos com o fornecedor. Executar e controlar estes acordos. Alinhar as atividades de medição A definição de requisitos e suas relações são realizadas a partir de mapas conceituais (mind maps). São especificados e documentos em diagramas de Business Collaboration (exemplo: use cases [10]). Marcos (milestones) apropriados, definidos ao fim de cada fase do processo iterativo possibilitam o controle e garantia da adequação dos produtos aos requisitos definidos. Iterações e incrementos são definidos seguindo um modelo de processo em espiral. O planejamento das atividades é definido em pacotes de alto nível, possibilitando o refinamento e monitoramento à medida que processo avança. Estes pacotes definem as unidades básicas de trabalho e gestão de configuração. Servem também para separar as diferentes áreas de conhecimento. Grande parte deste planejamento é centrada na estrutura e objetivo dos conteúdos dos pacotes, incluindo documentos, modelos, testes e código. O processo e iterativo e incremental, possibilita revisão e evolução a cada iteração. O gerente de projeto tem como objetivo manter a previsibilidade e monitoramento do projeto, cronograma, uso produtivo de recursos, incluindo código existente ou familiar e custos relacionados. O projeto compreensível, consistente e documentado possibilita acesso a todos os stakeholders. Não especifica a gestão de contrato com fornecedor. A organização deve ser responsável por essa tarefa. Defini-se padrões para o projeto no qual se incluem inspeções e métricas. 122

6 Garantia da Qualidade de processo e Produto Gestão de Configuração e análise. Fornecer resultados das medições. Deve-se controlar os dados das medições e comunicar os resultados a equipe. Processos e produtos de trabalho são avaliados objetivamente. Fornecer um entendimento objetivo como comunicar as garantias de qualidade e questões de não-conformidade, além de estabelecer registros. Estabelecer Baselines. As atividades de gestão de configuração são planejadas. Rastrear e controlar alterações. Os produtos de trabalho de software são identificados e controlados. Contudo, não se especifica na metodologia se estes dados são controlados e comunicados a equipe. A garantia de qualidade não é de fato uma atividade formal no Catalysis. O que é realizado são entregas de versões parciais do produto seguido de documentação. As pré condições, pós condições, mudanças e refinamentos são realizados de acordo com a necessidade do cliente. O controle de versão é mantido através da publicação das mudanças em pacotes. Estes possuem um atributo que identifica o estado do pacote (alterável ou publicado). As variações e versões são revisadas após as publicações. Estabelecer integridade. Alterações nos produtos de trabalho são controladas e as pessoas afetadas informadas. Tabela 1. Avaliação do Catalysis considerando o nível Gerenciado (2) Nível 3 (Definido) sobre Catalysis Áreas Chaves Metas Catalysis Desenvolvimento de Requisitos Solução Técnica Integração de Produto Desenvolver os requisitos do cliente. Desenvolver os requisitos do produto. Analisar e validar os requisitos com métodos detalhados. Elaborar e selecionar as soluções de componentes de produto. Elaborar o design do produto ou dos componentes do produto, bem como suas interfaces. Implementar e documentar o design do produto. Preparar as atividades de integração dos produtos. Os requisitos são desenvolvidos e analisados em um processo iterativo. Não especifica métodos da validação. Sugere sessões Joint - Application Development (JAD) entre a equipe de desenvolvimento, cuja finalidade é um entendimento comum sobre os requisitos para a fase de implementação. As soluções são definidas e selecionadas a partir dos requisitos do sistema. Os produtos ou componentes do produto são projetados como modelos de tipo, especificando suas ações no sistema (alguns componentes também podem ser comprados). São descritas as regras e padrões utilizados na implementação (exemplo: MVC (model-view-controller)). Os produtos são desenvolvidos como componentes de software. Suas interfaces são especificadas e testadas. 123

7 Verificação Validação Foco no Processo Organizacional Definição do Processo Organizacional Treinamento Organizacional Revisar e garantir a compatibilidade de todas as interfaces. Montar os componentes do produto, avaliar esses componentes e entregar o produto. Selecionar e preparar os produtos para a verificação de acordo com procedimentos e critérios. Realizar e analisar a revisão por pares. Verificar os produtos de trabalho selecionados. Selecionar e preparar os produtos para a validação de acordo com procedimentos e critérios. Validar o produto ou os componentes de produto e analisar os resultados. Verificar os produtos de trabalho selecionados e tomar ações corretivas se necessário. Determinar as oportunidades de melhorias de processo. Planejar e implementar as atividades de melhorias de processo, de acordo com um padrão de processo. Implementar os ativos de processo da organização e incorporar lições aprendidas. Estabelecer ativos de processo da organização. É desenvolvido e mantido um processo padrão de desenvolvimento de software da organização. Toda informação vinculada ao uso do processo padrão é coletada, revisada e disponibilizada. Estabelecer uma capacidade de treinamento organizacional. Fornecer treinamento necessário. Realiza os treinamentos e sua eficiência é avaliada. Define a estrutura lógica com um pacote de colaboração entre os componentes. As dependências entre esses componentes são explicitamente documentadas. A verificação é realizada tendo como base as pós condições advindas do cliente (estas são descritas formalmente). Não menciona a realização e análise da revisão por pares. A validação pode ser realizada a partir de storyboards, protótipos de interface do usuário, CRC (class, responsability and collaboration). A análise dos resultados não é realizada segundo um processo formal. Não discute formas de melhoramento do processo organizacional. Define que há fases pré-determinadas, porém não há um padrão rígido de processo. Especifica simplesmente que deve-se utilizar treinamentos, mas não como realizá-los e avaliá-los. 124

8 Gestão Integrada de Projeto Gestão de Risco Usar processo definido do projeto. Deve ser planejado e gerenciado de acordo com o processo definido para o projeto. Coordenar e colaborar com os Stakeholders relevantes e suas dependências. Preparar para a gestão de riscos. Planejar e definir os parâmetros de riscos, bem como uma estratégia de gestão. Identificar e analisar riscos. Elaborar e implementar planos para amenizar esse riscos. Análise de Decisão Avaliar alternativas. Deve-se estabelecer guias e critérios de avaliação. Identificar e avaliar soluções alternativas e selecionar soluções. Utiliza-se de padrões de contexto e de fases de desenvolvimento, porém não gerencia o ambiente de trabalho dos Stakeholders e problemas de coordenação. O desenvolvimento em espiral promove uma abordagem de prevenção de riscos precoce. Em cada ciclo os riscos são definidos, avaliados e possíveis mudanças são realizadas nos ciclos futuros. Práticas explícitas e antecipadas de modelagem da arquitetura, avaliação, implementação e construção de padrões de infra-estrutura são sugeridas para reduzir estes riscos. Um processo de refinamento recursivo leva a uma correta tomada de decisão. As decisões tomadas são relacionadas principalmente a arquitetura do sistema. Sugerida a definição de uma boa arquitetura, no qual conduz a escolhas regulares e consistentes. A avaliação e seleção das soluções não são especificadas. Tabela 2. Avaliação do Catalysis considerando o nível Definido (3) Nível 4 (Gerenciado Quantitativamente) sobre Catalysis Áreas Chaves Metas Catalysis Desempenho do Processo Organizacional Gestão Quantitativa de Projeto Estabelecer baselines e modelos de desempenho. Os processos são selecionados e então são estabelecidos medidas, objetivos de qualidade, baselines e modelos para o desempenho do processo. Gerenciar o processo quantitativamente. Gerenciar estatisticamente o desempenho dos subprocessos selecionados por medidas e técnicas analíticas. Não descreve se realiza uma avaliação do desempenho do processo. A gestão quantitativa do projeto não é realizada. Tabela 3. Avaliação do Catalysis considerando o nível Gerenciado Quantitativamente (4) 125

9 Nível 5 (Em Otimização) sobre Catalysis Áreas Chaves Metas Catalysis Inovação Organizacional Análise de Causa e Solução de Problemas Selecionar melhorias. Coletar e analisar propostas de melhorias, selecionando as melhorias pilotos para implantação. Implantar melhorias. Planejamento e gerenciamento da implantação além da medição dos efeitos das melhorias. Determinar causas de defeitos. Tratar as causas dos defeitos. O Catalysis não especifica como a seleção e implementação de melhorias possam aumentar a capacidade de uma organização, bem como atingir objetivos de qualidade e desempenho de processo. Não descreve como realiza a análise de causa e solução de problemas. Tabela 4. Avaliação do Catalysis considerando o nível Em Otimização (5) Analisando as tabelas, pode-se observar que a metodologia apresenta bom suporte para obter o nível gerenciado, porém algumas áreas chaves tais como gerência de contrato com fornecedor e medição e análise necessitam de um esforço maior por parte da organização, pois o Catalysis não especifica como devem ser realizadas. A necessidade de um maior controle em termos organizacionais se mostra evidente ao não tratar de forma consistente melhorias no processo de desenvolvimento padrão no nível 3, inviabilizando a satisfação de áreas chaves tais como foco no processo organizacional e definição de processo organizacional. Finalmente os dois últimos níveis necessitam de um alto grau de informação associada e mantida pela organização, que de certa forma são brevemente descritos ou considerados de responsabilidade da organização e não do processo de desenvolvimento proposto pelo Catalysis. 5. Considerações finais e trabalhos futuros O objetivo deste trabalho foi realizar uma avaliação sobre a metodologia Catalysis relacionando-a aos níveis de maturidade propostos no CMMI. Verificou-se que a maioria destas KPAs são asseguradas de forma parcial pela metodologia, pois seu foco principal está relacionado ao processo de desenvolvimento, bem como modelagem, projeto, análise e detalhamento na especificação e implantação de componentes de software. Avaliando estes aspectos, pode-se afirmar que a metodologia estudada possui uma abordagem insuficiente a respeito das responsabilidades organizacionais, isto de acordo com os requisitos CMMI. Entretanto, a própria metodologia não segue um padrão rígido de processo e sua adaptação depende principalmente da maturidade de desenvolvimento de software da empresa usuária. Então, neste sentido pode-se considerar para uma organização com um bom nível de maturidade nos seus processos organizacionais poderia potencialmente satisfazer algumas das áreas e metas que a metodologia Catalysis não trata explicitamente. 126

10 Em relação a trabalhos relacionados pouco se observou na literatura da área, sendo este fato inclusive uma das principais motivações para a realização da análise apresentada neste trabalho. Um dos trabalhos que pode ser citado é o apresentado em [9] o qual parte de um principio semelhante, onde visa a avaliação do Processo Unificado em relação ao nível 2 do CMMI. Como trabalhos futuros, pretende-se estudar e propor possíveis soluções para as metas e práticas específicas do CMMI não cobertas pela metodologia Catalysis no sentido de explorar as lacunas encontradas nas comparações. Também pretende-se contactar empresas de desenvolvimento de software na região que utilizam a metodologia Catalysis visando buscar parcerias que permitam avaliar a presente proposta em situações reais. Referências [1] Pressman, R. S., Engenharia de Software. 5a edição, McGraw-Hill, [2] Szypersky, C. Component Software: beyond-oriented programming. Harlow: Addison-Weskey, [3] Brown, A. W.; Short, K. On Components and Objects: The Foundation of Component-Based Development. International Symposium Assessment of Software Tools and Technologies, [4] D'Souza, D. F.; Wills A. C. Objects, components, and frameworks with UML: the catalysis approach, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1998 [5] Kotonya, G.; Sommerville, I. Requirements Engineering: Processes and Techniques. 1a edição, John Wiley & Sons, [6] Brooks, F. P. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, [7] Carvalho, M. S. Mapeando a ISO 9001 para o CMMI, Faculdade Lourenço Filho, Fortaleza, [8] CMMI Product Team, CMMI for Development, Vol 1.2, Carnegie Mellon University, Pittsburgh-USA, agosto de [9] Santander, V. F. A, Vasconcelos, A. M.,Mapeando o Processo Unificado em Relação ao CMM - Nível 2 In: XI Conferência Internacional de Tecnologia de Software, 2000, Curitiba. XI Conferência Internacional de Tecnologia de Software, de Junho. Curitiba: CITS - Centro Internacional de Tecnologia de Software, p [10] Booch, G; Rumbaugh, J; Jacobson, I. UML - Guia do Usuário. Editora Campus,