Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming

Transcrição

1 Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming T. M. R. Dias 1 ; G. F. Moita 2 ; M. P. Silva 3 ; B. Ferreira 1 ; A. M. Silva 1 1 IFMG Instituto Federal de Minas Gerais Campus Bambuí, Faz. Varginha Rodovia Bambuí/Medeiros Km 05 Cep: Bambuí MG. thiagomagela@gmail.com, brunoferreira.bf@gmail.com, alissonmarques@gmail.com 2 Centro Federal de Educação Tecnológica de Minas Gerais. Av. Amazonas, 5253, Nova Suiça, Cep: Belo Horizonte, MG, Brasil gray@dppg.cefetmg.br 3 Centro Universitário de Formiga, Av. Dr. Arnaldo Senna, 328, Água Vermelha, Cep: Formiga, MG, Brasil Michel.silva@gmail.com Resumo. Este artigo trata se de um estudo exploratório sobre a Metodologia de Desenvolvimento Ágil Extreme Programming (XP) e do Modelo de Referência MPS.BR (Melhoria do Processo de Software Brasileiro). São descritos no trabalho os conceitos que envolvem a metodologia XP bem como os do modelo de referência MPS.BR. É apresentada ainda uma análise da viabilidade de se adotar práticas e valores desta metodologia de desenvolvimento de software ao modelo de referencia, a fim de avaliar e identificar quais práticas e valores são mais adequados para adoção pelo modelo de referência bem como as restrições a algumas práticas. O objetivo principal deste trabalho é identificar quais as práticas de XP são aplicáveis no desenvolvimento de software baseado no modelo MPS.BR. Palavras chaves: Extreme Programming, Modelo de Referência MPS.BR, Qualidade de Software.

2 1 INTRODUÇÃO Há algum tempo atrás a construção de Software não tinha nenhum processo definido, não havia controle e o custo para construção destes sistemas era alto e o seu ciclo de vida era bastante curto. Como estes custos aumentavam cada vez mais, principalmente pelo fato dos sistemas a cada dia estarem mais complexos, empresas que tinham necessidades de alterar este quadro a fim de economizar custos e otimizar processos observaram que a criação de um modelo para desenvolvimento de software que pudesse otimizar estes custos e atender a demanda cada vez mais crescente poderia ser uma alternativa interessante. Espelhar-se na Engenharia tradicional para a construção de software foi então um caminho que teoricamente seria promissor a seguir. Neste cenário surge a Engenharia de Software que segundo Sommerville (2007) é uma disciplina de engenharia relacionada com todos os aspectos da produção de software. Com este novo caminho para se desenvolver software alguns problemas foram resolvidos e novas necessidades foram incorporadas à construção de software como a reutilização de parte do software e a componentização que visa construir sistemas a partir de pedaços com uma grande facilidade a fim de tornar o processo menos oneroso. Atualmente, uma metodologia derivada do Manifesto Ágil (Beck ET al., 2001) surge a fim de tornar a tarefa de construir software menos árdua e com resultados mais significativos. Esta metodologia é conhecida como Extreme Programming (XP). É uma metodologia dita informal já que se ajusta muito bem a softwares que mudam de requisitos rapidamente e tem por base boas práticas de programação ao extremo (Teles, 2005). Juntamente à Engenharia de Software surge também o conceito de qualidade de software, que segundo Vasconcelos (2005) o termo em geral está relacionado à uma série de aspectos tais como normalização e melhoria de processo, medições, padrões e verificações, entre outros. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente. Neste contexto, um comitê criado para melhoria do software nacional denominado SOFTEX, tentou tomar uma medida que se adequasse à realidade das empresas brasileiras e baseado em outros modelos como SCAMPI, SPICE e no próprio CMMI, fez surgir o MPS-BR (Melhoria do Processo de Software Brasileiro). Esta abordagem, além de conter as melhores práticas de cada uma das metodologias de avaliação citadas, tem uma melhor adaptação à realidade nacional, que é formada de empresas médias e pequenas que pretendem obter qualificação a um custo acessível e de valor reconhecido. Levando o que foi descrito em consideração, este trabalho visa realizar um estudo sobre a viabilidade de práticas e valores de XP no processo de desenvolvimento de software baseado no modelo MPS-BR. O XP não tem uma cultura de definição de processos suficientemente fixada a ponto de estar em conformidade com as metodologias de qualificação como o MPS-BR. No entanto, tanto XP como o MPS-BR tem ganhado grande popularidade em empresas de médio e grande porte e a fácil implantação e rápida adaptação ao processo pretendida por XP também é o foco do MPS-BR, justificando a aplicabilidade de XP em busca da maturidade do modelo MPS-BR. 2 MODELO DE REFERÊNCIA MPS-BR O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro 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).

3 O MPS.BR (Softex 2009) é composto por três partes: MR-MPS, Modelo de referência para melhoria do processo de software, que será explicado a seguir; MA-MPS, Método de avaliação para melhoria do processo de software, que tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em organizações que implementaram o MR-MPS; e MN-MPS, Modelo de Negócio, que consiste em regras para a implementação do MR-MPS pelas empresas de consultoria, de software e avaliação, o que o faz acessível a empresas de médio e pequeno porte. O modelo de referência MR-MPS define níveis de maturidade que são uma combinação entre os processos e sua capacidade. Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos da norma ISO/IEC 12207: processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento). Outro conceito utilizado no modelo é o de Capacidade, que é a habilidade que o processo possui em atingir os objetivos. A definição dos processos segue os requisitos para um modelo de referência de processo apresentados na ISO/IEC , declarando o propósito e os resultados esperados de sua execução. Isso permite avaliar e atribuir graus de efetividade na execução dos processos. As atividades e tarefas necessárias para atender ao propósito e aos resultados esperados não são definidas neste guia, devendo ficar a cargo dos usuários do MR-MPS. Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível. O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP) é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. 3 EXTREME PROGRAMMING - XP Extreme Programming (XP) é uma metodologia de desenvolvimento de software que surgiu nos Estados Unidos na década de 90. Seu desenvolvedor foi Kent Beck (Beck, 2004). Como uma metodologia de desenvolvimento ágil, tende a buscar a qualidade de

4 forma simples visando atender as necessidades do cliente, seja ele um cliente externo ou um cliente interno. O XP se apresenta como uma solução viável devido sua fácil adaptação à várias realidades. (Teles, 2004) Em XP o cliente passa a ser parte integrante da equipe, com papel fundamental de fornecer informações e corrigir possíveis falhas no planejamento e prioridades do software. Na observação de suas práticas é que se pode perceber, em que realmente a metodologia do XP auxilia, gestores, desenvolvedores e toda equipe no processo de criação do software. Deixando claro os caminhos que devem ser percorridos,permitindo com isto, que todos podem trabalhar com o estado da arte, para usufruírem de todo o potencial de criação. (Teles, 2005) Conforme Tabela 1, a metodologia XP, busca trazer valores e motivações para toda equipe envolvida no projeto de desenvolvimento. Levar confiança ao cliente de que suas necessidades serão respeitadas diante de um informativo de prioridades é de vital importância para que o projeto não seja interrompido. Tabela 1 Valores de Extreme Programming Feedback Simplicidade Comunicação Coragem Mostradas como uma série de atividades a serem seguidas, as práticas de XP norteiam a equipe desenvolvedora durante o projeto. Os valores citados anteriormente, somados as práticas (Tabela 2), resultam em um emaranhado de boas atitudes. Existe ampla confiança no entrosamento entre os valores e práticas, de tal forma que os pontos negativos ou fracos de uma são superados pelos pontos fortes de outra. Tabela 2 Práticas de Extreme Programming Cliente Presente Jogo do Planejamento Integração Contínua Pequenas Versões Metáforas Desenvolvimento Orientado a Testes Projeto Simples Time Coeso Refatoração Testes de Aceitação Ritmo Sustentável Padrões de Codificação Reuniões em Pé Posse Coletiva Programação em Pares Como membros de uma equipe se tem não apenas os programadores, mas também profissionais responsáveis pelos testes e o gerente que irá cuidar dos recursos necessários. Tabela 3. É importante perceber que dentro de uma equipe XP não existem pessoas com ações mais importantes que as outras, não existindo hierarquia. Cada membro faz sua contribuição ao projeto da melhor maneira que for possível. Tabela 3 Membros de Equipe de Extreme Programming Gerente de Projeto Analista de Testes Desenvolvedor Treinador Redator Técnico Rastreador O ciclo de vida em XP é constituído por várias fases que vão sendo vencidas conforme tempo definido anteriormente pela equipe. Existem sugestões de tempo para execução destas etapas, que buscam minimizar problemas com estimativas de tempo e tendem a manter uma constante sustentável no ciclo. Além das fases que o sistema a ser

5 desenvolvido irá passar, a agilidade tenta completar o ciclo de vida de um projeto em XP. O ciclo de vida curto é propício a projetos em que o sistema sofra mudanças de requisitos freqüentemente. Diante do exposto, sente-se que XP possui um ambiente altamente dinâmico e que em algumas situações é difícil manter o controle do processo e gerenciar as equipes envolvidas. Logo, obter um padrão de qualidade com os padrões que as normas de certificação empregam surge como um desafio. Diante disto, para se desenvolver software seguindo o Modelo MPS.BR juntamente com XP é preciso avaliar quais as práticas e valores deste último podem ser aplicados ao Modelo. 4 VIABILIDADE DE XP PARA O MODELO MPS.BR Diante das diferenças existentes entre as abordagens do modelo de Melhoria do Processo de Software Brasileiro e Extreme Programming, parece quase impossível que uma organização de menor porte não tenha que fazer uma escolha entre a consistência do primeiro e da agilidade e flexibilidade do segundo (Santana et al, 2006) Sente-se um anseio para que as organizações se beneficiem das vantagens das metodologias ágeis e também ajustar seu processo com um modelo cuja garantia de qualidade seja comprovada. Mas, ao mesmo tempo, o uso das metodologias ágeis no processo da organização não pode comprometer sua avaliação formal. Apesar de MPS.BR se utilizar da formalidade de documentar os processos e enquanto XP se denomina leve no aspecto de gerar documentos antes da fase de implementação, eles podem conviver na mesma organização. O MPS.BR tem um foco maior no gerenciamento do processo utilizado pela organização. Não indicando a maneira de como realizar determinadas tarefas, mas indicando o que deve ser feito para que a empresa que se utiliza deste modelo atinja determinado nível de maturidade que sustente seu crescimento e que a mesma seja capaz de repetir bons resultados obtidos em outros projetos anteriores. Algumas sinalizações partem do princípio que XP é um processo disciplinado e documentado, mesmo que com poucos documentos que tem foco na equipe de desenvolvimento e no trabalho técnico, não abordam a institucionalização das praticas de uma organização e se limita pouco a questões relativas à gerência de projetos. Desta forma, observamos que XP atende em grande parte alguns dos requisitos do MPS.BR e a grande maioria das metas de cada processo é atendida parcialmente por XP. O que demonstra uma preocupação comum em entregar software de qualidade, apesar desta visão de qualidade provir de ângulos diferentes, o que não as excluem mutuamente. 4.1 NÍVEL G PARCIALMENTE GERENCIADO O nível de maturidade G é composto pelos processos Gerência de Projetos e Gerência de Requisitos. De todos os resultados esperados para o processo de Gerencia de Projetos, identificase que XP não satisfaz alguns deles como, GPR8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados, GPR18. (Nos níveis E, D e C) Um processo definido para o projeto é estabelecido de acordo com a estratégia para adaptação do processo da organização, GPR19. (A partir do nível E) Produtos de trabalho, medidas e experiências documentadas contribuem para os ativos de processo organizacional e GPR25. (A partir do nível B) Dados estatísticos e de gerência da qualidade são incorporados ao repositório de medidas da organização, já os outros são satisfeitos, no entanto com algumas dificuldades. Os problemas identificados neste processo foram: Falta de controle dos recursos utilizados (GPR7); Falta de controle sobre custos e orçamento (GPR5);

6 Nenhum tratamento de riscos é abordado (GPR6). Com relação aos resultados que XP não satisfaz, se deve principalmente a alguns destes tratar de documentações que não são o foco de XP e citar ativos de processos organizacional onde temos que se a comunidade for criada apenas para o desenvolvimento de um determinado software, este recurso passa a ser não tão interessante. Já para os resultados esperados para a Gerencia de Requisitos, pode-se identificar que apenas a GRE5. Mudanças nos requisitos são gerenciadas ao longo do projeto, não é satisfeito por XP, todos os outros são satisfeitos. O único problema identificado foi: XP não define nenhuma matriz de rastreabilidade entre requisitos, planos de projetos ou e produtos de trabalho (GRE5). Para tentar contornar esta dificuldade poderia criar uma matriz de rastreabilidade de estórias ou mesmo uma tabela de controle de releases, constando quais estórias foram implementadas nele e quais linhas básicas foram geradas no mesmo. 4.2 NÍVEL F GERENCIADO O nível de maturidade F é composto pelos processos do nível anterior (G) acrescidos dos processos Aquisição, Gerência de Configuração, Garantia da Qualidade e Medição. Dentre todos os processos, a Aquisição é o único que não se aplica a XP, pois a metodologia prioriza softwares livres e/ou código aberto. Esta preferência implica em outro contrato de licença (Santana et al, 2006). Dentre os resultados da Gerencia de Configuração, pode-se identificar que apenas o GCO5. Modificações em itens de configuração são controladas e disponibilizadas e GCO7. O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados, são satisfeitas parcialmente por XP, todas os outros XP não satisfaz. Os problemas identificados foram: XP não define nenhum critério para seleção de itens de configuração; (GCO2); XP não estabelece sistemas de gerência de configuração (GCO1); XP não realiza qualquer auditoria em seu processo (GCO6). Para contornar este problema uma solução seria atribuir responsáveis pelos itens de configuração e formar um grupo de configuração e ainda identificar, definir e colocar artefatos sob uma linha básica. Já para a Garantia da Qualidade, observa-se que dois resultados GQA2. A aderência dos processos executados às descrições de processo padrões e procedimentos é avaliada objetivamente e GQA4. Ações corretivas para não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalonamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução, são satisfeitas por XP, os outros XP satisfaz parcialmente. Os problemas identificados foram: XP não avalia de maneira objetiva a aderência de produtos e processos aos padrões, procedimentos e requisitos aplicáveis (GQA1); XP não registra problemas e não conformidades (GQA3). Pode-se criar nota para registrar problemas e mudanças e armazená-la no sistema de gerência de configuração desde que este último esteja criado e definido. Por fim, dentre os resultados esperados do processo de Medição, identifica-se que dois deles MED2. Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado e MED6. Os dados e os resultados de análises são armazenados, são atendidos parcialmente por XP, os outros XP satisfaz. Os problemas identificados foram: XP não prioriza as medidas escolhidas. (MED2). XP não armazena claramente os dados colhidos (MED6); Para contornar esta situação pode-se criar prioridades para as medidas escolhidas.

7 4.3 NÍVEL E PARCIALMENTE DEFINIDO O nível de maturidade E é composto pelos processos dos níveis de maturidade anteriores (G e F), acrescidos dos processos Avaliação e Melhoria do Processo Organizacional, Definição do Processo Organizacional, Gerência de Recursos Humanos e Gerência de Reutilização. O processo Gerência de Projetos sofre sua primeira evolução retratando seu novo propósito: gerenciar o projeto com base no processo definido para o projeto e nos planos integrados. Com relação aos resultados esperados para Avaliação e Melhoria do Processo Organizacional, pode-se recomendar que XP atenda em parte a dois resultados, AMP1. A descrição das necessidades e os objetivos dos processos da organização são estabelecidos e mantidos e AMP2. As informações e os dados relacionados ao uso dos processos padrão para projetos específicos existem e são mantidos. Com relação aos outros se observa que XP não satisfaz. Os problemas encontrados foram: XP não realiza avaliações em seu processo (AMP3 e AMP4); XP não mantém descrições das necessidades e objetivos de processos (AMP1). Para contornar parte dos problemas gerados pode-se descrever de forma não burocrática as necessidades e objetivos dos processos da organização e criar uma verificação dos processos. Para o processo de Definição do Processo Organizacional, dentre os resultados esperados, identifica-se que um deles é completamente aplicável DFP5. Uma estratégia para adaptação do processo padrão para o produto ou serviço é desenvolvida considerando as necessidades dos projetos e outro é parcialmente atendido, DFP4. As descrições dos modelos de ciclo de vida a serem utilizados nos projetos da organização são estabelecidas e mantidas. Com relação aos outros se observa que XP não satisfaz. Alguns dos problemas encontrados foram: Falta de um repositório de medidas mantido (DFP6); Não manter um ambiente de trabalho padrão (DFP7). A fim de poder contornar algumas das dificuldades apresentadas e também de atender aos outros resultados esperados poderia obter-se uma maior flexibilidade como ambiente de trabalho e criar o repositório de medidas. Com relação aos resultados esperados para a Gerencia de Recursos Humanos, pode-se citar que dois deles, GRH8. Uma estratégia apropriada de gerência de conhecimento é planejada, estabelecida e mantida para compartilhar informações na organização além da GRH10. O conhecimento é prontamente disponibilizado e compartilhado na organização, são satisfeitos por XP em especial quando se diz respeito à disponibilização e compartilhamento de conhecimento, no entanto outros dois resultados, GRH2. Indivíduos com as habilidades e competências requeridas são identificados e recrutados, além do GRH9. Uma rede de especialistas na organização é estabelecida e um mecanismo de apoio à troca de informações entre os especialistas e os projetos é implementado, são parcialmente satisfeitos, o restante não são atendidos por XP. Alguns dos problemas encontrados foram: Recursos necessários são identificados antes do início do projeto (GRH1); A troca de informações deve ser uma meta constante (GRH9); Não existe uma estratégia de treinamento planejada (GRH3 e GRH4). Uma forma eficaz de evitar que haja desgaste desnecessário com treinamentos e correndo desta forma risco de atrasos que não é um dos princípios de XP deve-se identificar as necessidades antes do início do projeto e pessoas com as devidas qualificações sejam alocadas para cada função. Mecanismos para troca de informações entre todos os envolvidos deve ser criado para disseminação de informações e conhecimento.

8 Já o processo de Gerencia de Reutilização, possui resultados esperados que não são claramente abordados por XP, apesar de se ter na reutilização uma prática altamente aceitável, XP trata de outras práticas mais explicitamente. Alguns dos problemas encontrados foram: Não existe uma estratégia de gerenciamento de ativos documentada (GRU1); Falta de um registro de utilização de ativos reutilizáveis (GRU3). Para uma satisfação de XP a este processo uma forma de registrar e controlar a recuperação deve ser criada e ainda uma forma eficiente de comunicação sobre alterações e exclusões/inclusões deve ser disponibilizada. 4.4 NÍVEL D LARGAMENTE DEFINIDO O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores (G ao E), acrescidos dos processos Desenvolvimento de Requisitos, Integração do Produto, Projeto e Construção do Produto, Validação, e Verificação. O processo de Desenvolvimento de Requisitos é satisfeito por XP em todos os seus resultados esperados. Algumas práticas de XP como Cliente Presente e Integração Contínua além do Feedback um dos valores de XP contribuem para que a tarefa de desenvolvimento de requisitos seja satisfeita. Dentre os resultados esperados da Integração do Produto, pode-se citar três que são parcialmente satisfeitos por XP, ITP6. Os componentes do produto são integrados, de acordo com a seqüência determinada e seguindo os procedimentos e critérios para integração, ITP8. Uma estratégia de regressão é desenvolvida e aplicada para uma nova verificação do produto, caso ocorra uma mudança nos componentes do produto (incluindo requisitos, projeto e códigos associados) e ITP9. O produto e a documentação relacionada são preparados e entregues ao cliente, os outros se pode considerar que são atendidos por XP. Alguns dos problemas encontrados foram: Documentação não é preparada para entrega ao cliente (ITP9); Não possui uma estratégia de regressão definida (ITP8); Não é determinada uma seqüência para integração (ITP6). Uma das práticas de XP é a Integração Contínua fazendo com que os resultados esperados deste processo sejam altamente satisfeito. Com o cliente está presente, uma documentação para ser entregue ao cliente não se torna tarefa importante, já que ele ainda terá releases do sistema para testar. Os resultados esperados do processo de Projeto e Construção do Produto, se pode observar que três deles são satisfeitos por XP, PCP1. Alternativas de solução e critérios de seleção são desenvolvidos para atender aos requisitos definidos, PCP2. Soluções são selecionadas para o produto ou componentes do produto, com base em cenários definidos e em critérios identificados e PCP4. As interfaces entre os componentes do produto são projetadas com base em critérios predefinidos, os outros não são satisfeitos. Alguns dos problemas encontrados foram: Documentação não se apresenta como uma necessidade importante (PCP3, PCP7 e PCP8); Produtos e ou componente são projetados e implementados (PCP3). Apesar de XP considerar que a documentação seja importante no processo de construção de um software, ela tem o código como principal documentação, dedicar menos tempo à documentação poderá oferecer mais tempo para outras tarefas. O processo de Validação é amplamente satisfeito por XP principalmente devido as suas práticas de Releases Curtos e Desenvolvimento Guiado por Testes, isto faz com que os resultados esperados sejam satisfeitos mostrando desta forma uma boa aceitação por XP para o processo de Validação.

9 A exemplo do processo de Validação o processo de Verificação é amplamente satisfeito por XP e além das práticas citadas anteriormente temos aqui a Programação em Par que tona a tarefa de verificação um processo altamente satisfeito por XP. 4.5 NÍVEL C DEFINIDO O nível de maturidade C é composto pelos processos dos níveis de maturidade anteriores (G ao D), acrescidos dos processos Análise de Decisão e Resolução, Desenvolvimento para Reutilização e Gerência de Riscos. Neste nível, o resultado GRU3 do processo Gerência de Reutilização (GRU) evolui para adequar esse processo aos resultados do processo Desenvolvimento para Reutilização (DRU). Com relação aos resultados esperados para a Análise de Decisão e Resolução, pode-se considerar que quatro deles, ADR4. Alternativas de solução aceitáveis para o problema ou questão são identificadas, ADR5. Os métodos de avaliação das alternativas de solução são selecionados de acordo com sua viabilidade de aplicação, ADR6. Soluções alternativas são avaliadas usando os critérios e métodos estabelecidos e ADR7. Decisões são baseadas na avaliação das alternativas utilizando os critérios de avaliação estabelecidos, são satisfeitos por XP sendo os outros não satisfeitos. Alguns dos problemas encontrados foram: A definição do problema para a tomada de decisão pode não ser claro (ADR2); Inexistência de guias para análise de decisões (ADR1). A criação de um guia mesmo que seja simples e direto a fim de não causar grande volume de documentação pode apresentar-se como uma alternativa. A prática de Reuniões em Pé favorece a análise das decisões já que os envolvidos se reúnem diariamente para discussões. A exemplo do processo de Gerencia de Reutilização o processo de Desenvolvimento para Reutilização possui resultados esperados que não são claramente abordados por XP, apesar de se ter na reutilização uma prática altamente aceitável por algumas metodologias. Com a prática de Releases Curtos consegue-se ter partes do sistema que possivelmente poderão vir a ser reutilizados em outros softwares, no entanto uma política para armazenamento e controle destes componentes deve ser criada. Conforme dito anteriormente a criação de componentes reutilizáveis não é um dos focos de XP, sendo pouco abordado na literatura. Dentre os resultados esperados do processo de Gerência de Riscos, XP não consegue atender com total satisfação já que não trata dos risco de forma explicita. No entanto, a prática de Releases Curtos faz com que os usuários consigam avaliar o desenvolvimento em tempo real e a identificar desta forma riscos que possam surgir a fim de eliminá-los em tempo hábil. 4.6 NÍVEL B GERENCIADO QUANTITATIVAMENTE Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C), sendo que ao processo Gerência de Projetos são acrescentados novos resultados. Este nível não possui processos específicos. Baseado no princípio de que este nível não possui processos específicos decidiu-se por não detalhar as práticas e valores de XP aplicáveis considerando-se que os processos anteriores citadas que também compõe este nível já estão discutidos. 4.7 NÍVEL A EM OTIMIZAÇÃO Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B), acrescido do processo Análise de Causas de Problemas e Resolução. Dentre os resultados esperados para o processo de Análise de Causas de Problemas e Resolução, observa-se que dois deles são satisfeitos em parte por XP, ACP1. Defeitos e

10 outros problemas são registrados, identificados, classificados e selecionados para análise e ACP3. Ações para resolução do problema são selecionadas e implementadas, os outros não são satisfeitos. Alguns dos problemas encontrados foram: Classificação de problemas não existem (ACP1); Identificação de causa raiz de problemas não são feitas (ACP2); Inexistência de um repositório de ações para análise de causas de problemas (ACP5). Para resolução dos problemas XP emprega Reuniões em Pé que promove uma interação constante entre todos os envolvidos e podem desta forma discutir e analisar situações, no entanto, a criação de um repositório para controle e acompanhamento dos problemas pode favorecer o desenvolvimento atual e futuro. 5 CONCLUSÕES Este trabalho baseou-se em um estudo realizado objetivando apresentar os valores e práticas de Extreme Programming que podem ser aplicados ao Modelo MPS.BR. O trabalho demonstra um possível caminho para utilizar XP de forma a estar aderente ao Modelo MPS.BR. Algumas práticas de XP não podem ser aplicadas e outras necessitam ser adaptadas para que possam ser mais bem aproveitadas junto ao MPS.BR. Observa-se a falta de tratamento de aspectos relevantes do desenvolvimento de software por grande parte das metodologias de desenvolvimento. A combinação das metodologias ágeis com seus aspectos seja com base em um modelo de qualidade como o MPS.BR seja com base nos resultados difundidos da engenharia de software, mostra-se uma solução factível e viável para diversos ambientes de desenvolvimento. Além disto, uma metodologia como XP pode ajudar empresas com nenhum processo de software a adquirir a disciplina necessária para produzir um software de qualidade, apoiado em um dos modelos de qualidade reconhecido nacionalmente, tornando-a competitiva no mercado nacional. 6 BIBLIOGRAFIA Beck, Kent et al. (2001), Manifesto for Agile Software Development. Disponível em: < Acesso em: agosto Beck, Kent (2004), Extreme Programming Explained, Addison Wesley. Santana, Célio A., Timóteo, Aline L. e Vasconcelos, Alexandre M. L. (2006), Mapeamento do Modelo de Melhoria do Processo de Software Brasileiro (MPS.Br) para Empresas que utilizam Extreme Programming (XP) como Metodologia de Desenvolvimento. SBQS SOFTEX (2009), MPS.BR Melhoria de Processo de Software Brasileiro, Guias. Disponível em Acesso em agosto de Sommerville, Ian, (2007). Engenharia de Software. 8ª ed.são Paulo. Pearson Addison- Wesley. Teles, Vinicius M. (2004), Extreme Programming,Novatec, São Paulo. Teles, Vinicius M. (2005), Extreme Programming, Dissertação de Mestrado, IM- NCE/UFRJ,Rio de Janeiro. Vasconcelos, Alexandre Marcos Lins de; Maciel, Teresa Maria de Medeiros; Rouiller, Ana Cristina, (2005). Introdução à engenharia de software e aos princípios de qualidade. Lavras: UFLA/FAEPE 7 DIREITOS AUTORAIS Os autores são os únicos responsáveis pelo conteúdo do material impresso incluído no seu trabalho.