Comparativo Entre o Método Ágil XP e uma Visão Tradicional de Desenvolvimento de Software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE SISTEMAS DE INFORMAÇÃO DISCIPLINA: INE 5632 PROJETOS II Comparativo Entre o Método Ágil XP e uma Visão Tradicional de Desenvolvimento de Software EDUARDO CÔRTE HEIDRICH FLORIANÓPOLIS, 2005

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE SISTEMAS DE INFORMAÇÃO DISCIPLINA: INE 5632 PROJETOS II Comparativo Entre o Método Ágil XP e uma Visão Tradicional de Desenvolvimento de Software Orientador: Prof. Dr. Ricardo Pereira e Silva Banca Examinadora: Patrícia Vilain Jovelino Falqueto EDUARDO CÔRTE HEIDRICH FLORIANÓPOLIS, 2005

Índice 1 INTRODUÇÃO...6 1.1 Objetivos... 6 1.2 Objetivos Específicos... 7 1.3 Justificativa... 7 1.4 Trabalhos Relacionados... 8 1.5 Estrutura do Trabalho... 8 2 A VISÃO DE UMA ABORDAGEM NÃO ÁGIL DE DESENVOLVIMENTO DE SOFTWARE...9 2.1 O CMMI... 9 2.2 CMMI Representação em Estágios... 9 2.3 CMMI Representação em Estágios Nível 2... 10 2.3.1 Gerenciamento de Requisitos... 11 2.3.2 Planejamento de Projeto... 11 2.3.3 Monitorização e Controle de Projeto... 12 2.3.4 Gerenciamento de Contrato com o Fornecedor... 13 2.3.5 Medição e Análise... 13 2.3.6 Garantia de Qualidade de Processo e Produto... 14 2.3.7 Gerenciamento de Configuração... 14 2.4 CMMI Representação em Estágios Nível 3... 15 2.4.1 Desenvolvimento de Requisitos... 15 2.4.2 Integração do Produto... 16 2.4.3 Verificação... 16 2.4.4 Validação... 17 2.4.5 Treinamento Organizacional... 17 2.4.6 Gerenciamento de Risco... 17 2.4.7 Análise de Decisão e Solução... 18 2.5 Aspecto Tecnológico... 19 2.5.1 Etapas do Ciclo de Vida... 19 2.5.2 Modelos de ciclo de vida... 20 2.5.3 Produtos gerados... 20 2.6 Check List... 21 3 MODELO ÁGIL DE DESENVOLVIMENTO DE SOFTWARE...23 3.1 The Agile Alliance... 23 4 XP - EXTREME PROGRAMMING...31 4.1 Utilização... 31 4.2 Planejamento... 32 4.2.1 Estórias dos Usuários... 32 4.2.2 Planos de Entrega... 33 4.2.3 Entregas e Iterações... 33 4.2.4 Velocidade do Projeto... 34

4.2.5 Pessoas... 35 4.2.6 Reuniões... 35 4.2.7 Adaptações... 35 4.3 Design... 36 4.3.1 Simplicidade... 36 4.3.2 Cartões CRC... 36 4.3.3 Prototipação... 37 4.3.4 Funcionalidades... 38 4.3.5 Refatoração... 38 4.4 Codificação... 39 4.4.1 Disponibilidade do Cliente... 39 4.4.2 Padrões de Desenvolvimento... 39 4.4.3 Testes de Unidade... 40 4.4.4 Programação em Duplas... 40 4.4.5 Integrações... 41 4.4.6 Código comum... 42 4.4.7 Otimização... 42 4.4.8 Horas Extras... 42 4.5 Testes... 43 4.5.1 Testes de Unidade... 43 4.5.2 Tratamento de Bugs... 43 4.5.3 Testes de Aceitação... 43 4.6 Check List... 44 5 COMPARATIVO...47 5.1 É feito um levantamento de requisitos detalhado?... 49 5.2 Os requisitos são acompanhados ao longo do processo para garantir que estão sendo atingidos?... 49 5.3 Requisitos são aprofundados? Envolvem particularidades de tecnologia ou restrições de design?... 49 5.4 É feito um levantamento do escopo do projeto?... 50 5.5 É desenvolvido um plano para o projeto, que prevê tempo, esforços e recursos? 50 5.6 A gerência do projeto controla se tudo ocorre dentro do cronograma?... 50 5.7 É feito um plano de contenção que preveja e trate riscos do projeto?... 51 5.8 Tudo que é produzido é verificado e testado?... 51 5.9 Os produtos são avaliados para saber se fazem aquilo a que se propuseram?.. 52 5.10 Problemas que surgem ao longo do projeto são tratados formalmente? Existe algum tipo de categorização de problemas?... 52 5.11 Existem formas de treinamento e atualização dos funcionários da organização em prol dos interesses da mesma? Exemplo: Treinamento do processo de desenvolvimento... 52 5.12 É feito algum tipo de coletagem de dados de resultados dos projetos?... 52 5.13 Esses dados são trabalhados antes de serem armazenados?... 53 5.14 São feitas análises nesses dados com divulgação dos resultados?... 53

5.15 Existe uma equipe que garante que o processo é seguido mesmo em momentos de estresse?... 53 5.16 É feito controle de versão do código e de publicação de versões?... 54 5.17 Alterações feitas são documentadas e explicadas?... 54 5.18 A partes do produto desenvolvido se unem adequadamente e funcionam?... 54 5.19 Existe um processo para compra e aquisição de produtos e serviços?... 54 5.20 Essas aquisições são feitas por contratos formais com fornecedores?... 55 5.21 É gerada uma documentação dos requisitos?... 55 5.22 É gerada uma documentação das alterações dos requisitos?... 55 5.23 É gerado algum tipo de documento com o planejamento do processo? Incluindo escopo, cronograma, estimativas, modelos e métricas.... 55 5.24 XP no Processo CMMI... 56 5.25 Contribuições de XP... 56 5.26 Conclusão... 57 6 CONCLUSÃO...59 6.1 Resultados Obtidos... 59 6.2 Limitações... 60 6.3 Trabalhos Futuros... 60 6.4 Considerações Finais... 61 7 BIBLIOGRAFIA...62

1 Introdução O presente trabalho visa auxiliar o uso de XP (Extreme Programming), por meio de um comparativo entre a abordagem de desenvolvimento de software ágil, proposta pela Agile Alliance e a abordagem tradicional (que seria classificável como não ágil). XP será a metodologia utilizada para ilustrar o processo ágil e também o foco principal do projeto, a ser avaliada para uso no escopo de projetos de pequeno e médio porte. O fator agregador será o ambiente físico de desenvolvimento, que deve ser pequeno, ou seja, com uma equipe pequena, pois XP não exige tantos papéis distintos e centra muito a idéia de trabalho em equipe, sendo desenvolvido em paralelo. Inicialmente, é procedida uma explanação de um modelo de processo tradicional, suas rotinas, focado principalmente na parte de planejamento de projetos, que é uma parte que no modelo de processos ágil recebe pouco foco. Em seguida, é apresentado o modelo de processos ágil proposto pela Agile Alliance[AGILE], para que se possa deixar clara a filosofia do processo e os enfoques que são propostos pelo mesmo. O próximo passo é exemplificar o modelo de processos ágil com XP, que será apresentado em detalhes, com suas regras e práticas. A seguir, apresenta-se uma comparação dos modelos de projetos diretamente, apontando as vantagens e desvantagens que se obteria utilizando um modelo de processo ágil, utilizando a metodologia XP para exemplificar exatamente o tratamento que deve ser dado em cada situação abordada. Com isso, pretende-se mostrar que em um ambiente de desenvolvimento pequeno como se pode trabalhar otimizando melhor os recursos, evitando correrias em relação a prazos, entregando software de boa qualidade tendo como foco sempre a satisfação do cliente. 1.1 Objetivos

O objetivo do trabalho é roteirizar o uso de uma metodologia ágil passo a passo, no caso XP e fazer uma comparação direta de suas características com os requisitos de um modelo de processo tradicional entenda-se tradicional por já consagrado e reconhecido, tal como o CMMI (Capability Maturity Model Integration). 1.2 Objetivos Específicos Esclarecer o que e qual é a filosofia da abordagem ágil para desenvolvimento de software proposta pela Agile Alliance; Apresentar detalhadamente Extreme Programming para esclarecer dúvidas e desentendimentos de seu processo; Mostrar as vantagens e desvantagens da aplicação de XP comparado a uma abordagem não ágil; Apresentar padrões de projetos utilizados em XP que podem ser utilizados também em outras metodologias; Roterizar uma forma para a adoção de XP como metodologia para desenvolvimento de um projeto e; Mostrar as vantagens e desvantagens que XP deve trazer para um ambiente de desenvolvimento pequeno, composto por poucas pessoas; para a qualidade do software e em relação à satisfação do cliente. 1.3 Justificativa Muitos ambientes corporativos trabalham sem ter um processo definido e sofrem as conseqüências do mercado por isso, que seriam perda de contatos e cliente por não terem controle do que estão produzindo ou por não saberem estimar o tempo e custo do produto que estão vendendo. Nesse contexto, é plausível apresentar XP com uma solução para empresas que têm encontrado dificuldades na utilização de algum modelo de

processo e encaixem-se no perfil proposto nesse trabalho. Para isso XP precisa ser apresentado em detalhes, passo a passo, tendo seu processo comparado com outros modelos. Isso serviria de subsídio para uma empresa avaliar se é ou não adequado adotar XP como um todo, ou se pelo menos certas práticas poderão ser adotadas para melhorar processos já existentes. 1.4 Trabalhos Relacionados A tese de mestrado de Alexandre Zanatta [ZANATTA], de dezembro de 2004 pela Universidade Federal de Santa Catarina, trata de um assunto semelhante. Ele faz a extensão de uma metodologia ágil para adequação ao processo CMMI, ou seja, é feita uma adaptação do Scrum (metodologia ágil de desenvolvimento) para que o mesmo possa ser utilizado como processo de desenvolvimento que esteja apto a certificação do CMMI. 1.5 Estrutura do Trabalho No capítulo dois é apresentado um modelo de processos tradicional, baseado na visão de processos do CMMI, considerando a versão em estágios e nos princípios da Engenharia de Software[PRESSMAN]. No capítulo três é apresentada a visão da Agile Alliance na abordagem ágil de desenvolvimento de software. No capítulo quatro é apresentada a metologia Extreme Programming. No capítulo cinco é feito um comparativo entre Extreme Programming e o modelo tradicional apresentado. No capítulo 6 é feita a conclusão desse trabalho. No capitulo 7 estão as referências bibliográficas.

2 A visão de uma abordagem não ágil de Desenvolvimento de Software Nessa parte do trabalho será apresentada uma abordagem não ágil de desenvolvimento de projetos software. A abordagem apresentada será baseada no modelo Capability Maturity Model Integration (CMMI). 2.1 O CMMI O CMMI é um modelo que contém práticas essenciais para o desenvolvimento e melhoramento de processos, pois processos de qualidade tendem a gerar produtos de qualidade. A abordagem do CMMI é feita no nível gerencial, não tratando diretamente o aspecto tecnológico ou o produto[silva]. Criado pela SEI (Software Engineering Institute), o CMMI foi influenciado por modelos anteriores principalmente o CMM-SW (Capability Maturity Model for software), em Português, Modelo de Maturidade da Capacitação para software.. Devido às várias versões de CMM para finalidades diversas, a SEI iniciou o chamado CMMI (CMM Integration), que contou com a colaboração da indústria e do governo Norte Americano, sendo patrocinado pela DoD (U.S. Department of Defense), o Departamento de Defesa Norte Americano. Seu objetivo era de unificar e resolver diferenças dos modelos anteriores, unificando os CMMs para usarem as mesma terminologia, processos de avaliação e estrutura, para ficarem compatíveis com a norma ISO/IEC 15504, conhecido também como Spice [ZANATTA]. O CMMI tem duas versões: Em Estágios e Contínua. Esse trabalho apresentará a versão Em Estágios. 2.2 CMMI Representação em Estágios

Este é dividido em 5 estágios de maturidade, que representam a evolução dos níveis de processos dentro de uma organização. Nível 1 significa ser capaz de desenvolver software, sem um processo bem definido e o sucesso depende de esforços pessoais; Nível 2 capacidade de gerenciar um projeto, requisitos e processos que são controlados, medidos e executados; Nível 3 processo de desenvolvimento definido, ou seja, capaz de atingir metas, prazos e custos; Nível 4 gerenciamento quantitativo, aplica-se continuamente técnicas estatísticas para avaliar o processo e; Nível 5 melhoria contínua, capacidade de interferir no processo. Um nível é caracterizado por suas áreas de processo, sendo esses requisitos que têm que ser cumpridos em conformidade com o modelo CMMI. Cada nível possui suas áreas de processo, exceto o nível 1, que não tem nenhuma. As áreas são cumulativas, ou seja, os requisitos de um nível também são requisitos do próximo. Para esse trabalho optou-se por abranger o nível 2 de forma completa e o nível 3 de forma incompleta (excluindo a parte referente à construção, manutenção e uso de um conjunto de processos padrão). Assim, a visão de gerenciamento de um projeto baseada no CMMI nível 2 e parte do 3 estarão apresentadas na forma de um processo que aborda os aspectos gerenciais, de forma a possibilitarem uma comparação com uma abordagem ágil de desenvolvimento. 2.3 CMMI Representação em Estágios Nível 2 Este é o nível onde o projeto passa a ser gerenciado, tudo é estimado, planejado, executado e medido. Compromissos são estabelecidos e tudo é documentado.

A disciplina no Nível 2 garante que mesmo em tempos de estresse as práticas serão mantidas, mantendo a conformidade com a documentação de planejamento. No nível 2, requisitos, processos, produtos e serviços são gerenciados. O estado do desenvolvimento do trabalho fica visível à gerência em pontos definidos, como ao completar uma tarefa. Compromissos são assumidos e revistos se necessários. Os trabalhos são revisados e controlados e tudo deve satisfazer os requisitos, padrões e objetivos estabelecidos [CMMI]. A seguir são apresentadas as áreas de processo do nível 2 do CMMI. 2.3.1 Gerenciamento de Requisitos Gerenciar os requisitos dos produtos do projeto e seus componentes buscando identificar inconsistências entre os requisitos do projeto, o planejado e os produtos do projeto. O gerenciamento dos requisitos pode ser visto em 3 tarefas básicas: compreender, aprovar e mudar. Primeiramente é necessário obter-se compreensão daquilo que está sendo requisitado, tecnicamente e não tecnicamente, pois essa compreensão que suportará o planejamento e execução do projeto. Uma vez compreendido os requisitos é necessário revisá-los com as fontes, para que possam ser então aprovados e incorporados ao projeto. E finalmente, ao longo do desenvolvimento do projeto, encontram-se inconsistências nos requisitos, que podem ser provenientes das fontes, dos produtos de trabalho ou dos requisitos levantados, o que gerará mudança, que deve ser esclarecida, aprovada e então incorporada. Para isso é necessário manter-se uma rastreabilidade bidirecional dos requisitos. 2.3.2 Planejamento de Projeto

Estabelecer e manter os planos que definem as atividades do projeto. Para isso inicia-se com a definição do escopo, que é feita a partir da especificação de requisitos. Com o escopo definido o passo seguinte é o de estimar. Estimar tudo o que será necessário para a conclusão do projeto, esforço, que pode ser especificado em homem-hora, por exemplo, equipamentos e conhecimentos, pois é necessário dispor dos equipamentos necessários e planejar como se lidará com possíveis especificidades técnicas que poderão surgir, e estimativas de tempo para o desenvolvimento do projeto. Nessa etapa também cabe uma análise dos riscos de projeto, que podem ser não apenas técnicos, como também de conhecimentos e externos ao mesmo. Tudo isso deve gerar um plano, cujo cronograma pode ser algo como o Diagrama de Gant, por exemplo, que é utilizado em ferramentas de projeto, como o Microsoft Project. Esse plano pode sofrer alterações ao longo do projeto, forçando um replanejamento, que pode ser proveniente de mudanças de requisitos no projeto ou mudanças de processos, pode ocorrer por falhas de estimativas ou ainda por necessidades de correções de erros cometidos. 2.3.3 Monitorização e Controle de Projeto Prover um entendimento do progresso do projeto de tal forma a se identificar desvios no fluxo planejado e tomar ações corretivas aos problemas. Isso se dá a partir do plano do projeto. Com base no plano se efetua o monitoramento, comunicações e aplicação de ações corretivas de acordo com os desvios que houverem no plano. Para se medir o andamento do projeto compara-se o que foi planejado ao que foi concluído e verificam-se os objetivos intermediários. Manter uma visão do projeto clara é muito importante para identificar-se os desvios no curso planejado para o projeto e tomar-se as ações corretivas, sendo que os desvios

de curso são problemas ou enganos que não permitirão que se atinja os objetivos. No caso dos desvios acontecerem as ações corretivas podem exigir replanejamento, onde devem ser verificados novamente os objetivos, aprovados e então executados. 2.3.4 Gerenciamento de Contrato com o Fornecedor Gerenciar a aquisição de produtos de fornecedores com que se tenham acordos formais. Esses acordos dizem respeito a contratos, licenças ou qualquer tipo de acordo legal que exista entre a organização e o fornecedor. Essa atividade tem como função determinar o tipo de aquisição, os fornecedores a serem utilizados, monitorar as atividades do mesmo, avaliar os produtos entregues e garantir a integração dos mesmos ao projeto. A idéia é que esses produtos desenvolvidos fora da organização não venham gerar problemas para os projetos em desenvolvimento. 2.3.5 Medição e Análise Desenvolver e manter a capacidade de medição, que dá suporte ao levantamento de informações gerenciais objetivas. A primeira atividade a ser desenvolvida nesse aspecto é determinar os objetivos das coletas de dados e análises que devem ser feitas. Para isso, é essencial especificar métricas, forma de coletar os dados, onde armazená-los, que técnicas usar para avaliar os dados, que tipo de relatórios pretende-se ter e qual o mecanismo que será usado para a divulgação desses dados. Uma vez especificado o passo seguinte é implementar a estrutura de medição e análise. Essa estrutura produzirá subsídios para a tomada de decisões de projeto, tais como ações corretivas no surgimento de problemas. A integração das informações obtidas nas atividades de medição e análise ajuda no planejamento e nas estimativas do projeto, permite comparar a

performance do desenvolvimento com o que foi planejado, ajuda a identificar e resolver problemas de projeto, serve de suporte para a área de controle de qualidade e serve de base para a incorporação de futuros novos processos. 2.3.6 Garantia de Qualidade de Processo e Produto Prover pessoal e gerenciamento com a finalidade de obter uma avaliação objetiva de processos e produtos de trabalhos associados, isto é, fazer a avaliação dos produtos, procedimentos e serviços efetuados, de acordo com as descrições e os padrões de projeto. Os resultados devem ser documentados e relatados para as equipes e gerências para que possam ser tomadas as devidas ações corretivas. O pessoal responsável por essa área do processo tem como função garantir que o processo e as regras sejam mantidos, mesmo nos momentos mais críticos do projeto. 2.3.7 Gerenciamento de Configuração Estabelecer e manter a integridade dos produtos de trabalho usando identificação de configuração, controle de configuração, administração de estado de configuração e auditorias de configuração. Diz respeito basicamente ao controle de versão e ao controle das alterações, para saber-se o porquê e por quem foram feitas. As versões devem ser controladas para que se possa ter controle e para facilitar a manutenção do que foi produzido. Garantir as versões é um ato de disciplina para que se evite descartes, o que pode acarretar na perda de fontes de uma versão que venha a gerar demanda por manutenção. É responsabilidade do gerenciamento de configuração prover os repositórios, os acessos e controle dos mesmos e fazer a

composição para a publicação de versões. Um exemplo de um software para controle de versão seria o CVS (Concurrent Versions System). 2.4 CMMI Representação em Estágios Nível 3 O nível 3 é o nível definido, onde o processo passa a ter maior maturidade as soluções de projeto passam a ser decididas dentro de um universo previsto, ao invés de uma para cada projeto. O interesse desse trabalho não é de entrar a fundo no desenvolvimento específico do processo, mas sim de apresentar um processo completo, portanto as áreas de processo apresentadas a seguir são complementares do nível 2. Foram deixadas de lado as áreas de processo: foco no processo da organização, definição do processo da organização, solução técnica e gerenciamento de projeto integrado, que tratam a construção, manutenção e uso de um conjunto de processos padrão. Isto porque apresentar um processo de desenvolvimento com o conjunto de atividades previamente definido é um nível de maturidade ainda incomum entre as empresas que adotam processos de desenvolvimento organizados. Abaixo estão apresentadas as áreas de processo pertinentes ao desenvolvimento deste trabalho. 2.4.1 Desenvolvimento de Requisitos A idéia é produzir a analisar requisitos do cliente, do produto e dos componentes de produto. Tais requisitos devem ser analisados, iniciando-se pelos requisitos do cliente, que gerarão os requisitos do produto e este o dos componentes de produto. Na análise de requisitos do cliente podem ser vistos requisitos específicos de design que influenciarão nas escolhas de soluções para o mesmo gerando requisitos diferentes para os produtos.

Os requisitos devem ser esclarecidos, analisados, validados e comunicados para garantir o entendimento de todos os envolvidos no projeto. Todas as necessidades dos envolvidos devem ser coletadas e coordenadas, para o estabelecimento dos requisitos do cliente e o estabelecimento dos requisitos dos produtos e componentes de acordo com os requisitos do cliente. 2.4.2 Integração do Produto É a integração dos componentes do produto para a formação do produto final. A união das partes deve gerar um todo que funcione apropriadamente. Esta área de processo foca em garantir que nos ciclos determinados e nos procedimentos de integração do produto o mesmo tenha suas interfaces compatíveis com os requisitos para que seja montado o produto dos componentes do produto. Uma atenção especial deve ser dada ao gerenciamento das interfaces para garantir a compatibilidade dos componentes do produto. 2.4.3 Verificação O objetivo é verificar os produtos de trabalho. Tudo aquilo que for gerado tem que ser verificado. Todos os produtos gerados devem ser confrontados com os requisitos para ver se cumprem o que foi especificado. Este é um trabalho incremental, pois a verificação de todas as partes vai levar a verificação do produto como um todo. Verificação de performance também faz parte dessa área de processo, bem como a preparação de ações corretivas para o que não estiver de acordo com o requisitado. Seria como fazer um check list de tudo que foi requisitado e confrontar com o que é produzido para garantir que tudo ocorreu conforme o requisitado.

2.4.4 Validação Embora parecido com a verificação, a validação tem com intenção atingir o objetivo ao qual o produto foi proposto, ou seja, o produto deve fazer aquilo para o qual ele foi concebido. Está área de processo certifica que os produtos e seus componentes fazem aquilo para o qual eles foram produzidos dentro do ambiente para o qual eles foram desenvolvidos. Atingir a expectativa do cliente é o objetivo dessa área de processo, enquanto a verificação preocupa-se cumprir os requisitos. 2.4.5 Treinamento Organizacional A organização deve promover treinamentos para garantir que seu pessoal possa desenvolver as habilidades e conhecimentos para realização de suas tarefas com eficiência e eficácia. Os treinamentos que devem ser promovidos são aqueles que vêm de encontro aos interesses organizacionais ao invés daqueles específicos de um projeto. Estes são de responsabilidade dos grupos de desenvolvimento, que deve promover e organizar. As necessidades como aplicação do processo, difusão do mesmo são exemplos do que a organização deve promover a seus funcionários, para garantir que seus processos e padrões sejam seguidos. Promover treinamento é levantar as necessidades de treinamento, prover o treinamento, estabelecer as capacidades desenvolvidas e um registro das mesmas e verificar a eficácia dos mesmos. 2.4.6 Gerenciamento de Risco Gerenciar risco é uma tarefa árdua e contínua. Sua proposta é fazer a identificação de tudo o que pode impedir o projeto de atingir seus objetivos

durante seu ciclo de vida. Ao identificar um risco o mesmo deve ter suas medidas de contenção planejadas para serem aplicadas no caso do risco se tornar uma realidade. Não apenas os riscos internos devem ser considerados, mas também os externos, que podem afetar fontes de custo, cronograma e a parte técnica. Agressividade no tratamento dos riscos e descoberta precoce dos mesmos é a melhor forma de tratar os riscos, pois quanto mais tardiamente forem descobertos maior será o impacto no projeto, exigindo maior custo e esforço para serem corrigidos. 2.4.7 Análise de Decisão e Solução Ao decorrer do projeto problemas surgirão e necessitarão de uma solução. Esta área de processo trata da forma como esses problemas serão tratados e as soluções e decisões serão dadas. Deve haver um critério para que os problemas sejam avaliados formalmente e solucionados de acordo com um critério formal, para impedir que se façam reuniões com muitas pessoas para decisões que poderiam fazer parte do processo ou dos padrões da organização. O primeiro passo e estabelecer um critério para os problemas serem passados a frente ou decididos localmente. Tendo um critério, alternativas para o problema devem ser identificadas. Selecionar métodos para avaliar as alternativas é o passo seguinte, que será utilizado para avaliar as soluções alternativas que serão selecionadas e baseada nos critérios criados, onde uma deve ser a escolhida. Ter um critério formal para avaliação de problemas ajuda no esclarecimento de problemas e leva a soluções mais genéricas, que irão ao encontro a outros problemas cujos participantes do projeto podem estar envolvidos.

2.5 Aspecto Tecnológico Anteriormente foi apresentado o aspecto gerencial processo, que é formado por práticas genéricas que poderiam ser aplicadas basicamente em qualquer atividade, como fazer um bolo. Um bolo pode ser planejado, ter seus requisitos levantados, com sabor, tamanho, cobertura, etc; ter seus riscos avaliados, como calor do forno, qualidade dos ingredientes e etc, mas esse não é o objetivo do trabalho. Nesse trabalho o propósito é produzir software e para isso temos que avaliar o que exatamente deve ser produzido no processo, bem como as etapas do mesmo, como percorrê-las e o que vai ser gerado em cada uma delas. 2.5.1 Etapas do Ciclo de Vida Na produção de software é necessário definir as etapas que serão percorridas no decorrer do processo para a geração do sistema final. Estas etapas devem compreender as tarefas gerenciais citadas acima. A definição do processo será dada em 4 (quatro) etapas: Análise, Projeto, Implementação e Testes. Na etapa de análise é onde será realizada a parte de levantamento de requisitos, planejamento de projeto, estimativas e definição de recursos que serão alocados para o projeto e a modelagem do domínio do problema. Em Projeto será feita a definição dos produtos e componentes que serão desenvolvidos ao longo do projeto. A implementação é a parte onde o código propriamente dito é escrito, ou gerado por alguma ferramenta, ou seja, é basicamente a etapa de programação. A etapa final é a etapa de testes, que compreende desde o teste de unidade até o teste de aceitação do produto.

2.5.2 Modelos de ciclo de vida Existem diversos modelos de ciclo de vida, como o modelo em Cascata e o Code and Fix, que são modelos conceituais. Estes modelos têm como objetivo determinar a forma como as suas etapas serão percorridas. Existem variações entre propostas de divisão de etapas, mas basicamente todas compreendem as atividades previstas acima. Um processo deve definir como as etapas devem ser percorridas, ou seja, definir um ciclo de vida para o projeto. Como citado anteriormente, o modelo em Cascata prevê as mesmas etapas propostas nesse trabalho, que devem ser percorridas de maneira seqüencial, onde ao termino de uma inicia-se a outra. O modelo em V, prevê basicamente as mesmas etapas, só que ao longo de cada uma é gerada uma parte dos planos de testes, sendo que para cada etapa haverá uma de teste referente à mesma. Dentro das etapas citadas, é possível criar novas formas de percorrê-las sem a necessidade de seguir nenhum modelo específico. 2.5.3 Produtos gerados Ao final de cada etapa são gerados produtos, que são na realidade documentação. Por exemplo, ao final da análise deve-se ter uma documentação com definições de requisitos, estimativas de custo e esforço, um cronograma, modelagem do domínio do problema. Ao final da etapa de projeto espera-se ter um plano de ação para a etapa de implementação, que pode ser uma especificação em UML ou outra linguagem de especificação de software, para documentação de entidades, relacionamentos e interação das partes. Quanto à implementação o objetivo é claro, é obter o código. Já quanto à etapa de teste é verificar se cada etapa cumpriu seu papel e encontrar eventuais falhas. Gerar uma documentação do que saiu errado e porque saiu errado, criar uma base de conhecimento para evitar que os mesmo erros venham ser cometidos novamente.

Em resumo, é tudo aquilo que é gerado ao longo do processo de desenvolvimento de um software. 2.6 Check List Aqui está um check list desenvolvido para uma verificação de que as áreas de processo do CMMI citadas no trabalho são implementadas e seguem a proposta do modelo. Pergunta É feito um levantamento de requisitos detalhado? Os requisitos são acompanhados ao longo do processo para garantir que estão sendo atingidos? Requisitos são aprofundados? Envolvem particularidades de tecnologia ou restrições de design? É feito um levantamento do escopo do projeto? É desenvolvido um plano para o projeto, que prevê tempo, esforços e recursos? A gerência do projeto controla se tudo ocorre dentro do cronograma? É feito um plano de contenção que preveja e trate riscos do projeto? Tudo que é produzido é verificado e testado? Os produtos são avaliados para saber se fazem aquilo a que se propuseram? Problemas que surgem ao longo do projeto são tratados formalmente? Existe algum tipo de categorização de problemas? Existem formas de treinamento e atualização dos funcionários da organização em prol dos interesses da mesma? Exemplo: Treinamento do processo de desenvolvimento. É feito algum tipo de coletagem de dados de resultados dos projetos? Esses dados são trabalhados antes de serem armazenados? Check

São feitas análises nesses dados com divulgação dos resultados? Existe uma equipe que garante que o processo é seguido mesmo em momentos de estresse? É feito controle de versão do código e de publicação de versões? Alterações feitas são documentadas e explicadas? A partes do produto desenvolvido se unem adequadamente e funcionam? Existe um processo para compra e aquisição de produtos e serviços? Essas aquisições são feitas por contratos formais com fornecedores? É gerada uma documentação dos requisitos? É gerada uma documentação das alterações dos requisitos? É gerado algum tipo de documento com o planejamento do processo? Incluindo escopo, cronograma, estimativas, modelos e métricas.

3 Modelo Ágil de Desenvolvimento de Software Um modelo ágil é um modelo bom o suficiente para atingir certos objetivos, nada mais, isto é, ele tem apenas as características necessárias para atingir objetivos específicos de desenvolvimento e, não visa ir além do que for julgado necessário [AGILE]. Os modelos ágeis são baseados na prática para modelagem efetiva de sistemas baseados em software. Modelagem ágil é uma abordagem onde muitas metodologias se encaixam. 3.1 The Agile Alliance Quem já passou por projeto onde não existiam regras, onde não se tinha processo, sabe que é um grande pesadelo. O desperdício de tempo, de código, a repetição de erros faz com que o produto final fique mal acabado, atrasado e deixe o cliente insatisfeito. Essa situação é algo quem ninguém gostaria de passar e aqueles que passaram não gostariam de repeti-la. A resposta a tal situação é a criação de um processo, algo que possa nos dar confiança para nos livrar dessa insegurança. Temos medo de: Que projeto produza o produto errado; Que o produto seja de baixa qualidade; Que projeto atrase; Que tenhamos que fazer muito esforço adicional ao planejado; Que tenhamos que cancelar compromissos e; Não ter prazer no trabalho[agile]. Os medos fizeram com que processos fossem criados. Muitas condições eram impostas, tudo que era experimentado e trazia bons frutos era utilizado no processo, esperando que fosse funcionar de novo.

Mas a utilização de processos não estava evitando que erros fossem cometidos ou repetidos, então a atitude tomada era a de se colocar mais condições nos processos para evitar que tais erros ocorressem. Com isso, os processos passaram então a crescer demais e tornarem-se um empecilho ao desenvolvimento do projeto, trazendo problemas com atrasos e qualidade. Em torno do ano 2000, haviam muitas empresas sofrendo com os problemas dos processos inflados, ou ainda empresas que não utilizavam processo algum. A adoção de processos pesados (baseados no modelo tradicional) estava crescendo, principalmente nas grandes corporações. Este cenário fez que com em 2001 um grupo de especialistas em desenvolvimento de reunisse em busca de formar uma forma de unir valores e princípios que permitissem desenvolvimento rápido e adaptação a mudança. Esse grupo se chamou de The Agile Alliance. Com a união desse grupo foi concretizado um manifesto pelo desenvolvimento ágil de software que diz: Manifesto para o Desenvolvimento Ágil de Software Estamos descobrindo melhores maneiras de desenvolver software desenvolvendo-o e ajudando outros a desenvolvê-lo. Através desse trabalho chegamos aos valores: Indivíduos e interações acima de processos e ferramentas Software funcionando acima de documentação compreensiva Colaboração com o cliente acima de negociação de contrato Adaptação a mudança acima de seguir o plano inicial Isto é, mesmo havendo valor nos itens da direita, nós valorizamos mais os da esquerda. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn

Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas [MANIFESTO] Extraido e traduzido. O manifesto cita 4 valores fundamentais para a comunidade ágil, que são explicados abaixo: Indivíduos e interações acima de processos e ferramentas Muitas vezes tem-se uma forte tendência a valorizar demais as ferramentas e processos, deixando muito pouco às pessoas que fazem parte dele. As pessoas são a parte mais importante de qualquer processo. De nada adianta um processo bom se o time é ruim, como de nada adianta um bom time se o processo é ruim. A parte mais importante é que os membros do projeto trabalhem como um time, colaborem uns com os outros, havendo um bom ambiente de comunicação. As ferramentas não são a parte principal de nenhum projeto. De nada serve um grande e caro ferramental se o time não sabe usá-lo. Robert Martin, um dos membros fundadores da Agile Alliance, em seu artigo [AGILE] aconselha a se começar do simples. Ele diz para se usar sempre as ferramentas mais simples possível, iniciando preferencialmente pelas que são Software Livre e aprender a fazer diagramações em geral primeiro num quadro ou papel, para adquirir-se primeiro habilidade e prática, para então poder comprar ferramentas mais voltadas as necessidades encontradas. Montar o time é mais importante que montar o ambiente de trabalho. Com o time montado, o ideal é deixá-los escolher o ferramental que precisarão. Software funcionando acima de documentação compreensiva Um software sem documentação torna-se uma dor de cabeça na hora de dar manutenção. Nós humanos temos que fazer algo que seja facilmente

legível e acessível a nós, ou seja, fazer a documentação do que estamos desenvolvendo. O problema é que uma documentação grande demais se torna um empecilho maior que uma pequena. Começando pelo esforço de desenvolvê-la e depois de mantê-la ao longo do projeto, porque se não for mantida deixa de ter qualquer valor, passa a ser algo a atrapalhar o projeto. A melhor forma de treinar um novo membro do grupo é sentar-se junto a ele e passar tudo que foi feito, mostrar-lhe o código e explicar as etapas, pois o time é que mais sabe do projeto e quem mais pode ensinar sobre o mesmo. A mais importante documentação, que não contém ambigüidade, é o código. Não há como o código dizer uma coisa e fazer outra, ele não mente. Para se prevenir da louca corrida por documentação o autor [AGILE] propõe a seguinte regra: Não faça nenhum documento cuja necessidade não é imediata e importante. Colaboração com o cliente acima de negociação de contrato Não é possível descrever um software e colocá-lo num contrato com preço e prazos já fixados. Muitos que tentaram fazê-lo acabaram frustrando-se. É inimaginável querer que um grupo receba uma especificação de software, entre numa sala e volte com um sistema que seja exatamente o que o cliente quer. É necessário haver interação com o cliente. O time de desenvolvimento e o cliente têm que trabalhar junto em busca do produto. Um contrato não deve conter especificação de software e custos e prazo pré-fixados. Ele deve conter a forma como cliente e time de desenvolvimento vão interagir para se atingir o objetivo proposto. Como por exemplo, num projeto de um ano o cliente paga uma mensalidade e na entrega de módulos do sistema ele faria pagamentos maiores. O importante é manter a interação com o cliente, semanalmente pelo menos, ter um feedback rápido e priorizar aquilo que for pedido para ser mudado. Muitas vezes se jogará grandes blocos de código fora, mas vale a pena em nome da satisfação e da qualidade do produto final.

Adaptação a mudanças acima de seguir o plano inicial Ao ser traçado um plano, devemos tratá-lo da maneira mais adaptável e flexível possível, pois ele sofrerá mudanças. As mudanças virão porque ao se tratar de software sofre ação de muitas variáveis que são pouco previsíveis. Mesmo o cliente tende a mudar de opinião dentro do tempo de desenvolvimento do software. Uma vez que o cliente veja o software funcionando é provável que ele queira fazer algumas alterações. Muitas vezes o gerente gosta de traçar um plano que descreve todas as etapas do projeto do começo ao fim do desenvolvimento e colocar isso num calendário. O planejamento feito tende a estar totalmente desatualizado em poucas semanas, pois o modelo prevê que mudanças acontecerão e tais mudanças não só mudarão datas, mas tarefas que foram executadas e outras que serão executadas. Além disso, o plano tende a levar a equipe a um espírito de compromisso com o que está ali definido, dificultando as mudanças necessárias. O ideal é fazer um planejamento de curto prazo, ou seja, no máximo algumas semanas à frente. Deve-se planejar apenas o que será feito no nível imediato, pois mudanças que aconteçam serão mais facilmente feitas. Os valores supracitados inspiraram os fundadores da Agile Alliance a doze princípios, que são: Nossa principal prioridade é satisfazer o cliente através de rápida e contínua entrega de software funcionando. O autor [AGILE] cita um estudo feito pela The MIT Sloan Management Review que faz um estudo sobre práticas para ajudar a desenvolve software de alta qualidade. Essa diz que a qualidade aumenta quando partes do software funcionando são entregues mais cedo. Quanto menor e mais breve a parte entregue, maior as chances de sucesso.

Outro ponto interessante é a correlação feita com as entregas seguintes. Quanto menor for o prazo para novas entregas maior a chance do software ter mais qualidade ao final do processo de desenvolvimento. Os processos ágeis têm isso como meta, entregas desde cedo e freqüentes, normalmente a primeira parte já é entregue poucas semanas após o início do desenvolvimento e as seguintes são feitas de poucas em poucas semanas, quando não semanalmente. Receber bem mudanças de requisitos, mesmo que tardiamente. Processos Ágeis usam mudança como vantagem competitiva do cliente. Tratando-se de um processo ágil, o time de desenvolvimento não tem medo da mudança. Pelo contrário, vê isso como uma forma de aprender mais sob o que satisfaz o mercado. É feito um trabalho muito intenso ao longo do desenvolvimento para manter a estrutura do projeto flexível, para ao ter que se fazer qualquer mudança, tal seja pouco impactante. Entregas de software funcionando freqüentemente, semanalmente ou mensalmente, preferindo o menor prazo. O importante é entrega software que funcione, desde o começo do projeto e repetidas vezes, em curtos prazos, durante o projeto. Entregas de papéis e planos têm pouco valor o foco é no produto final que é o que satisfará o cliente. A administração e os desenvolvedores têm que trabalhar juntos diariamente ao longo do projeto. A interação entre time de desenvolvimento, administração e cliente tem que ser constante. Um processo ágil é algo que tem que ser seguido de perto. Faça projetos junto a pessoas motivadas. Dê a elas os suporte e ambiente necessários e confie em sua capacidade. As pessoas constituem a parte mais importante num processo ágil, portanto, elas vêm primeiro. Processo, ambiente e outras variáveis são secundários e mutáveis se estiverem segurando o desenvolvimento do projeto. O modo mais efetivo e eficiente de transmitir informação para o time de desenvolvimento é a conversa frente a frente.

Conversa, comunicação verbal, essa é a mais importante forma usada para comunicação em um processo ágil. Documentos, planos e outras formas não devem ser usadas a não ser que seja fortemente necessárias, mas exclusivamente naquele ponto que foram necessárias. Software funcionando é a forma de medida de progresso. A forma com que se mede o progresso de um software é o quanto de sua funcionalidade está funcionando, ou seja, se 20% das funcionalidades estão funcionando 20% do software está pronto. Não existe medida de fases, ou de documentação o código desenvolvido num processo ágil. Processos ágeis promovem um desenvolvimento sustentável. Clientes e desenvolvedores têm que manter um ritmo constante. Desenvolver um projeto não é como uma corrida de velocidade, mas sim de resistência. Por isso deve se estabelecer um bom ritmo de desenvolvimento e mantê-lo. O time de desenvolvimento faz um esforço para manter todos num único ritmo, sem atropelar ou forçar nada, para que sempre se trabalhe produzindo o software de maior qualidade possível. Atenção contínua a qualidade técnica e de design aumenta a agilidade. A chave para agilidade é qualidade. Todos que estão no time de desenvolvimento estão comprometidos e gerar o código de mais alta qualidade de for possível. Se algo sair errado é concertado no dia e não mais tarde, quando se tiver tempo. Simplicidade a arte de maximizar o trabalho não feito é essencial. Todo código gerado deve ser o mais simples e de melhor qualidade possível. Deve-se focar no hoje, nos problemas de hoje e deixar os de amanhã para amanhã. Caso amanhã tenha que se mudar o código por qualquer que seja o motivos, com certeza essa mudança será fácil. As melhores arquiteturas, requisitos e design dos times que se auto organizam. Responsabilidades não são de um membro do time de desenvolvimento, são do time todo. Não existem responsáveis por cada área, mas todos são

responsáveis por tudo e têm o direito e opinar sobre tudo. O time trabalha junto em todo e qualquer aspecto do projeto. Em intervalos regulares, o time reflete sobre como ser mais eficiente, então melhora e se ajusta as novas formas. Um time que adota um processo ágil revê constantemente a sua forma de trabalho, está sempre tentando melhorar organização, regras, convenções e etc. É sabido que num processo ágil tudo está em constante mudança, então é necessário que o time evolua ao mesmo passo. Ao se desenvolver software é comum passar por problemas e frustrações. Falhar é algo que faz parte da vida de quem trabalha no desenvolvimento de projetos. O crescimento dos projetos faz com que eles vão ficando cada vez mais complexos de entender ao longo do desenvolvimento, que é um dos motivos pela qual as falhas acontecem. O modelo ágil veio com a proposta de simplificar isso, com métodos e práticas simples evitar esse crescimento desenfreado. Para isso muitas metodologias que trabalham dentro desse modelo podem ser aplicadas, a principal delas o XP extreme Programming.

4 XP - Extreme Programming Extreme Programming (XP) é uma metodologia ágil de desenvolvimento de software, que foi criada antes do Manifesto Ágil surgir. Ela foi criada pelo principal membro fundador da Agile Alliance, Kent Beck, em 1996. XP foi aplicada pela primeira vez num projeto da Daimler-Chrysler chamado Chrysler Comprehensive Compensation system (C3), que foi iniciado na metade dos anos 90 utilizando programação orientada a objetos usando Smalltalk. Kent Beck foi chamado para dar auxílio técnico por ser um especialista em Smalltalk. O projeto passou então a ser liderado por Kent Beck e foi convertido para XP em 1997, após ter sido considerado um fracasso [HIGHSMITH]. A XP segue os conceitos propostos na Agile Alliance embora tenha sido criada antes. As propostas no geral são parecidas, pois a XP tem como foco principal a criação de soluções simples, programação em duplas e a liberação constante de versões funcionais do software. Quanto as regras e práticas da XP podemos dizer que ela se divide em quatro partes: Planejamento, Design, Codificação e Testes. 4.1 Utilização XP foi proposta com o intuito de ser aplicado para projetos onde os requisitos sofrem constantes mudanças, ou seja, o cliente não sabe o que ele quer ou o que o sistema deve fazer. Outro ponto importante são os fatores de risco, pois se o projeto precisa ser concluído para uma determinada data o fator de risco é alto, se o sistema é um desafio à equipe maior ainda e se for algo inovador então é enorme. XP com suas técnicas e práticas diminui esse risco e aumenta as chances do processo dar certo. Mais um ponto fundamental é o do tamanho da equipe. XP deve ser usado em equipes pequenas de desenvolvimento, de 2 a 12 desenvolvedores. É

altamente desaconselhável o uso de XP para equipes grandes, pois num projeto com muitas mudanças ou alto risco XP será mais eficaz. As equipes em XP são compostas por desenvolvedores, gerentes e pelo cliente. Todos trabalhando juntos, lado a lado, tirando dúvidas, negociando prazos e escopo e criando testes para validar as funcionalidades. Os domínios de projetos de XP têm que, por obrigatoriedade, aceitar a aplicação de testes de unidade e de funcionalidade. Embora isso desqualifique alguns domínios, a maioria aceita essa especificidade, pois como vantagem, muitas vezes um design será projetado de forma a facilitar os testes. 4.2 Planejamento É uma etapa de preparação para os trabalhos de desenvolvimento. Nela são feitos os levantamentos de requisitos, estimativas e produzidos um plano de entregas. Aqui também são planejadas reuniões e definidas as tarefas de gerência e controle. 4.2.1 Estórias dos Usuários O planejamento inicia-se com algo semelhante a um levantamento de requisitos tradicional, chamado de Estória dos Usuários, só que o mesmo é feito de uma forma menos aprofundada, pois seu objetivo é ter uma visão geral do escopo do projeto e das partes de que ele é composto. Cada umas das Estórias dos Usuários seria uma parte funcional do sistema, um requisito escrito pelo próprio usuário em sua linguagem, sem especificações de tela ou detalhamento de qualquer natureza técnica. Com as Historias dos Usuários prontas é possível se fazer uma estimativa de tempo para o desenvolvimento do sistema em questão, pois os analistas e desenvolvedores terão informações para fazer uma estimativa. É importante

relatar que tal estimativa é feita considerando dias normais, uma equipe focada somente no sistema e nada mais a se fazer. 4.2.2 Planos de Entrega O passo seguinte seria fazer-se uma Reunião de Planejamento de Entregas, ou seja, é uma reunião onde será definida a ordem em que serão feitas entregas e o que será entregue em cada umas delas. Tais definições são feitas pelo usuário. 4.2.3 Entregas e Iterações A definição das entregas é feita de forma cíclica. Os ciclos de desenvolvimento são chamados de iterações. Pegue o projeto e divida-o em aproximadamente uma dúzia de ciclos, cujo tempo de cada um varie entre uma e três semanas. Nunca mais nem menos que isso. Dentro de cada iteração o usuário vai definir quais Estórias vão ser desenvolvidas e entregues, de acordo com a prioridade que o usuário der. Com isso é gera um Plano de Iterações. Este plano pode ser alterado após as primeiras iterações variando de acordo com a Velocidade do Projeto. Os prazos das iterações devem ser levados a sério. Encare cada iteração como se fosse a última. Caso ao longo da iteração fique claro que não será possível entregar tudo que foi planejado marque uma reunião de Planejamento de Entregas e estime novamente as tarefas. Sempre priorize as tarefas que o usuário apontou como mais importantes na iteração. Mesmo que os atrasos ocorridos venham a ser pequenos, o fato de se re-estimar as tarefas faz-se valer mais tarde. Isso manterá o seu projeto nos trilhos e em bom andamento. As iterações garantem que em curto prazo o usuário vai receber partes funcionais de software que podem ser colocadas em produção, pois atendem de forma completa algum cenário ou necessidade que foi requerida. De poucas em

poucas semanas após serem validadas pelo usuário esses módulos devem entrar em produção, o que também ajudará a diminuir o impacto no contato com o novo sistema além do mesmo passar a colher informações que antes eram desperdiçadas. 4.2.4 Velocidade do Projeto A Velocidade do Projeto é a forma de medir o quão rápido o desenvolvimento está acontecendo comparado ao que foi previsto, ou seja, quanto tempo cada Estória da iteração levou para ser desenvolvida comparado ao que foi estimado. Na iteração seguinte, na Reunião de Iteração os usuários podem escolher um número de interações que se encaixe dentro da Velocidade do Projeto da iteração anterior. Definidas as Estórias que farão parte de integração os elas são quebradas em tarefas técnicas e disponibilizadas para que os desenvolvedores escolham as suas de acordo com a velocidade do projeto. Isso permite que depois de uma iteração conturbada, o time de desenvolvimento se ajuste e acabe com pendências anteriores, permitindo também que eles requisitem ao usuário mais tarefas, quando estiverem adiantados e sem pendências. É esperada uma variação na velocidade do projeto para mais ou para menos, mas deve-se observar que quando as alterações ocorrem de forma mais drástica é necessário que haja uma nova Reunião de Planejamento para que se negocie estimavas e prazos. A Velocidade do Projeto é esperada que se altere quando começarem a surgir tarefas de manutenção. XP tem a visão de que a primeira estimativa é a mais difícil. Levantar muitos detalhes não fará da estimativa inicial nada além de um palpite. Faça uma estimativa geral, vislumbrando apenas o todo e gaste o tempo que tradicionalmente é utilizado fazendo especificações longas e detalhadas para desenvolver uma ou duas iterações, meça a Velocidade do Projeto inicialmente e tenha então um palpite melhor.