Curso de Engenharia de Computação ABORDAGENS SOBRE MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE

Transcrição

1 Curso de Engenharia de Computação ABORDAGENS SOBRE MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE Jeferson Teixeira Campinas São Paulo Brasil Dezembro de 2008

2 Curso de Engenharia de Computação ABORDAGENS SOBRE MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE Jeferson Teixeira Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Doutor Adalberto Nobiato Crespo, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Doutor Adalberto Nobiato Crespo Campinas São Paulo Brasil Dezembro de 2008

3 Abordagens sobre métodos de desenvolvimento de software Jeferson Teixeira Monografia defendida e aprovada em 11 de Dezembro de 2008 pela Banca Examinadora assim constituída: Professor Dr. Adalberto Nobiato Crespo (Orientador) USF Universidade São Francisco Campinas SP. Professor M.Sc. Claudio Maximiliano Zaina USF Universidade São Francisco Campinas SP. Professor Esp. Ricardo César Boaretto USF Universidade São Francisco Campinas SP.

4 Dedico este trabalho a minha noiva e futura esposa, Elisa Alonso, por me apoiar em todos os momentos. Dedico também a meus pais, Jair Teixeira e Jocely Rodrigues Teixeira, por todo o carinho e dedicação em toda minha vida.

5 .Agradecimentos Agradeço a Deus por me ter guiado até aqui e por ter me dado a oportunidade de ser quem eu sou. Agradeço a minha noiva e futura esposa, Elisa Alonso, por sempre demonstrar seu amor, apoio e dedicação. Agradeço a meus pais por todo carinho e dedicação em todos os momentos da minha vida, sempre estando prontos para me ajudar e me orientar. Agradeço a todos os professores que tive durante toda a minha vida, que me ensinaram valores que levarei comigo para sempre. Agradeço, finalmente, a meu orientador, Prof. Doutor Adalberto Nobiato Crespo, por ter aceitado me orientar e me conduzir durante toda a realização deste trabalho. v

6 Sumário Lista de Siglas...vii Lista de Figuras...viii Resumo...ix Abstract...x 1 Introdução Contextualização Objetivo Estrutura do Texto Métodos de desenvolvimento de software Metodologias tradicionais de desenvolvimento de software Método cascata Método espiral Outros métodos tradicionais de desenvolvimento de software Prototipação RUP Métodos ágeis de desenvolvimento de software Origem dos métodos ágeis de desenvolvimento de software Valores ágeis Características comuns entre métodos tradicionais e métodos ágeis Scrum XP Outros métodos ágeis Crystal Methods Feature-Driven Development (FDD) Dynamic Systems Development Method (DSDM) Projeto Desenvolvido Levantamento de necessidades e requisitos Interação com o cliente Número de indivíduos que compõe a equipe de desenvolvimento Grau de maturidade dos indivíduos que compõe a equipe de desenvolvimento Prazos e custos da construção de um software Testes e entrega do software para o cliente Manutenção do software em produção Conclusão Vantagens dos métodos ágeis em relação aos métodos tradicionais Desvantagens dos métodos ágeis em relação aos métodos tradicionais Características necessárias que uma equipe de desenvolvimento de software deve ter para utilizar métodos ágeis Contribuições Trabalhos futuros...54 Referências Bibliográficas...55 vi

7 Lista de Siglas CMMI DSDM FDD MPS.BR RAD RUP UP XP Capability Maturity Model Integration Dynamic Systems Development Method Feature-Driven Development Melhoria de Processos de Software Brasileiro Rapid Application Development Rational Unified Process Unified Process Extreme Programming vii

8 Lista de Figuras Figura 1 Histórico de publicação de metodologias de desenvolvimento de software...7 Figura 2 Método cascata...11 Figura 3 Método Espiral...14 Figura 4 Fases e volume de atividades para cada atividade do RUP...16 Figura 5 Comparação de custo de mudança entre cascata e XP...22 Figura 6 Ciclo de desenvolvimento do Scrum...31 Figura 7 Valores e práticas de XP...35 Figura 8 Esquema do Crystal Methods...37 viii

9 Resumo Este trabalho descreve os princípios básicos do métodos tradicionais e dos métodos ágeis de desenvolvimento de software, apresentando suas principais características e definições. Os métodos tradicionais de desenvolvimento de software são abordados nesse trabalho devido a sua grande utilização na indústria de software e também devido a sua importância histórica, por se tratarem dos primeiros métodos de desenvolvimento de software criados, em especial o método cascata, que foi o primeiro método de desenvolvimento de software utilizado pela indústria de software e, em alguns lugares, é utilizado até hoje. Continuando o enfoque em relação aos métodos tradicionais, é descrito o método Espiral, que foi o primeiro método que utilizou técnicas iterativas e incrementais, e também são brevemente citados os outros métodos tradicionais de desenvolvimento (Prototipação e RUP). Já em relação aos métodos ágeis de desenvolvimento de software, é descrita a origem desses métodos bem como os valores ágeis, definidos através do Manifesto Ágil, que compõe quatro definições básicas dos métodos ágeis de desenvolvimento de software. Os métodos Scrum e XP são apresentados e detalhados, dando enfoque em suas principais características. Os dois métodos foram escolhidos por serem atualmente os mais utilizados entre os adeptos aos métodos ágeis de desenvolvimento. O trabalho se encerra com a comparação entre os métodos tradicionais e os métodos ágeis, analisando algumas de suas características comuns. Também é feita a análise em relação as vantagens e desvantagens de se utilizar métodos ágeis de desenvolvimento de software. Por fim, são levantadas as características básicas que uma equipe de desenvolvimento de software deve ter para que a utilização de métodos ágeis seja viável e garanta a qualidade do software gerado ao final do processo de desenvolvimento PALAVRAS-CHAVE: Desenvolvimento de Software, Métodos ágeis, Métodos Tradicionais, Scrum, XP, Cascata, Espiral. ix

10 Abstract This paper describes the basic principles of traditional methods and agile methods of software development, presenting their main characteristics and settings. Traditional methods of software design are discussed in this work because of their great use in the software industry and also because of its historical importance, they were the first methods of developing software created, especially the cascade method, which was the first method of developing software used by the software industry and in some places, is used today. Continuing the focus on the traditional methods, the method is described Spiral, which was the first method that used techniques recursive and incremental, and are also briefly mentioned the other traditional methods of development (Prototyping and RUP). Already in the methods of agile software development, is described the origin of such methods as well as the values agile, defined by the Manifesto agility, which comprises four categories of basic methods of agile software development. The methods Scrum and XP are presented and detailed, focusing on its main features. The two methods were chosen because they are currently the most widely used among supporters of agile methods of development. The paper concludes with a comparison between traditional methods and agile methods to analyze some of their common characteristics. It's also done the analysis on the advantages and disadvantages of using agile methods of software development. Finally, it raised the basic features that a team of software design must have for the use of agile methods to be viable and ensure the quality of software generated at the end of the development process. KEY WORDS: Software development, Agile methods, Traditional methods, Scrum, XP, Waterfall, Spiral x

11 1 INTRODUÇÃO 1.1 Contextualização Os avanços tecnológicos vistos no último século e no início do século atual fizeram com que o software tenha papel imprescindível em diversos segmentos de atividades da sociedade atual. Cada vez mais equipamentos eletrônicos, que utilizam softwares de vários tipos para controlarem seu funcionamento, têm feito parte do cotidiano das pessoas, tanto na indústria, como no comércio e em domicílios. Essa crescente demanda por novos produtos tecnológicos aumenta proporcionalmente a demanda por desenvolvimento de novos softwares e conseqüentemente implica na busca por novas maneiras mais apropriadas de desenvolvê-los. Visto isto, torna-se claro que o aumento do mercado de software seja um fato consumado na sociedade atual. O aumento desde mercado também o tornou mais competitivo, fazendo com que as necessidades para desenvolvimento de software evoluam cada vez mais rapidamente e exigindo cada vez mais a necessidade de se adaptar a essas mudanças. A falta de envolvimento e comprometimento das pessoas que retinham o conhecimento sobre o problema, aliado a coleta de requisitos muito instáveis, ocasionou na constatação de que vários métodos de desenvolvimento de software se demonstrassem impróprios. No CHAOS Report de 1994 [Chaos], 365 empresas colaboraram com a avaliação de 3682 projetos, demonstrando que 83,2% foram cancelados ou entregues excedendo o orçamento ou o prazo estimado. Dentre esses projetos, o custo foi em média 89% acima do previsto e o atraso médio foi de 122% além do planejado. Os participantes também declararam as principais razões para esses resultados e apenas seis fatores representaram juntos a 60,35% das possíveis causas. Esses fatores são: requisitos incompletos, falta de envolvimento de usuários, mudanças de requisitos e especificações, falta de apoio da equipe de negócios, falta de recursos e expectativas não-realistas [Filho2008]. A Engenharia de Software tem como intuito principal buscar melhores formas de se projetar e desenvolver software para que problemas com relação a cumprimento de prazos e controle de custos de projetos de software sejam cada vez mais otimizados. 1

12 Uma grande quantidade de pessoas tem trabalhado em pesquisas de metodologias que auxiliam a equipe de projeto de um determinado software a gerenciar todos os aspectos que envolvem a sua produção. É inegável que grandes evoluções têm surgido nessa área, mas com as constantes mudanças do mercado de software mundial a necessidade de se desenvolver software com alta qualidade, baixo custo e em prazos cada vez mais curtos exigem que novas metodologias de desenvolvimento sejam projetadas, estudadas e implementadas para atender essas mudanças. Várias comunidades de desenvolvimento de software espalhadas pelo mundo, com a consciência de que a qualidade dos softwares desenvolvidos estava muito aquém do necessário, fizeram várias tentativas de melhorar o desenvolvimento de softwares, resultando em modelos tais como: Unified Process (UP), Cleanroom Software Engineering e Rapid Application Development (RAD) que apostaram em alternativas que se baseiam em processos pré-definidos. Também foram criados modelos de certificação para validar a aplicação dos processos. Nesse quesito se destacam o Capability Maturity Model Integration (CMMI), ISO e o modelo de Melhoria de Processos de Software Brasileiro (MPS.BR). Mas apesar das boas intenções dessas iniciativas, todas abordam o desenvolvimento de software como um processo que pode ser repetido mecanicamente, tentando enquadrá-lo em uma linha de produção. [Filho2008] Um dos grandes problemas das metodologias desenvolvidas no início da história da Engenharia de Software é o grande formalismo nos modelos de processos propostos, que vão à contramão do desenvolvimento de software exigido atualmente software de qualidade, com desenvolvimento rápido e de baixo custo. Apesar de hoje em dia ser facilmente possível adquirir um software em lojas de shopping center, supermercados e até mesmo em bancas de jornal, o desenvolvimento de um software segue padrões muito diferentes do desenvolvimento da maioria dos bens de consumo, como um avião, por exemplo. No caso de um avião, as maiores necessidades são em relação à matéria prima necessária e quais ferramentas utilizar. Após construir a primeira unidade de um avião é possível determinar quais ferramentas serão utilizadas e a quantidade de matéria prima necessária para se construir um novo avião. Além disso, a replicação de um avião pode seguir uma linha de montagem completamente automatizada, sem necessidade de intervenção humana. Já no caso de software, o problema não está relacionado com a replicação do mesmo, já que depois de pronto, um software 2

13 pode ser facilmente replicado a custo praticamente zero. O grande problema do software está em seu desenvolvimento, já que não há matéria prima palpável para tal. Na década de 90 começaram a surgir pesquisas em relação a metodologias de desenvolvimento de software que resultou no surgimento do que hoje são chamados métodos ágeis de desenvolvimento de software. As metodologias desenvolvidas anteriormente ao surgimento dos métodos ágeis tinham como fundamento básico a documentação e a previsibilidade dos processos. Elas buscavam levantar todas as necessidades e requisitos do software e entender todo o domínio do problema antes de iniciar o desenvolvimento. Depois que todas as necessidades e requisitos do sistema são levantados e analisados, é feito um planejamento para gerenciar todas as mudanças que podem ocorrer durante o processo de desenvolvimento do software. Já os métodos ágeis de desenvolvimento de software optam pela adaptabilidade. Métodos ágeis partem do pressuposto de que é praticamente impossível levantar todas as necessidades e requisitos de um software antes do início do seu desenvolvimento. Nos métodos ágeis os requisitos são levantados no decorrer do andamento do projeto e o planejamento é sempre contínuo, de modo que as adaptações as alterações dos requisitos possam ocorrer. Os métodos ágeis compreendem vários processos para desenvolvimento de software, levando em conta técnicas iterativas e incrementais baseadas em equipes auto organizadas, auto gerenciáveis e multifuncionais. A interação social entre os indivíduos que desenvolvem o software, o pleno funcionamento do software acima de uma documentação compreensível e a rápida resposta as mudanças ao invés de se seguir um plano previamente determinado são premissas básicas dos métodos ágeis de desenvolvimento de software. Levando-se em conta que os métodos ágeis têm como foco principal pequenas equipes e que 85% das empresas de software dos EUA maior produtor mundial de software são consideradas pequenas [Filho2008], a pesquisa e o aprimoramento desses métodos tem se tornado cada vez mais constante e importante. 3

14 1.2 Objetivo O principal objetivo deste trabalho é comparar métodos tradicionais e métodos ágeis de desenvolvimento de software e demonstrar quais as vantagens e desvantagens que os métodos ágeis têm em relação aos métodos tradicionais. Também é objetivo deste trabalho apresentar quais características uma equipe de desenvolvimento de software deve ter para que a utilização de métodos ágeis seja viável e garanta que o software entregue tenha a qualidade esperada pelo cliente A comparação entre os métodos apresentados será realizada analisando uma série de características comuns que os dois métodos têm para o desenvolvimento de um projeto de software. Essas características comuns compreendem o ciclo completo de desenvolvimento de um software, passando pelas fases de análise, projeto, desenvolvimento, testes e manutenção de um software. As características comuns que serão comparadas neste trabalho são: levantamento de requisitos e necessidades, necessidade de interação com o cliente, número de indivíduos que compõe a equipe de desenvolvimento, grau de maturidade desses indivíduos, prazos e custos da construção de um software, testes e entrega do software para o cliente e, por fim, a manutenção do software já completamente disponibilizado e em produção. No capítulo que contém os resultados e a conclusão do trabalho serão apresentadas e detalhadas as vantagens e as desvantagens que os métodos ágeis têm em relação aos métodos tradicionais de desenvolvimento de software através da análise realizada de cada característica comum apresentada. Também serão apresentadas quais são as características necessárias que uma equipe de desenvolvimento de software deve ter para que a utilização de métodos ágeis seja viável e garanta a qualidade do software gerado ao final do processo de desenvolvimento. No final do trabalho serão apresentados dois temas que poderão ser desenvolvidos em estudos futuros, utilizando-se como base os resultados deste trabalho. 4

15 1.3 Estrutura do Texto Para ajudar o leitor na leitura do texto, o mesmo está dividido da seguinte maneira: O capítulo 2 faz uma abordagem geral sobre métodos de desenvolvimento de software. O item 2.1 define os métodos tradicionais de desenvolvimento de software, dando ênfase para os métodos Cascata no item e o método Espiral no item 2.1.2, enquanto no item são brevemente descritos outros métodos tradicionais Já no item 2.2 são definidos os métodos ágeis de desenvolvimento de software. No item é descrita a origem dos métodos ágeis. Os valores ágeis definidos no Manifesto Ágil são descritos no item e no item são definidas as características comuns entre os métodos ágeis e os métodos tradicionais. Em relação à métodos ágeis, no item é detalhado o método Scrum, enquanto no item é detalhado o método XP, deixando para o item uma breve descrição de outros métodos ágeis. O capítulo 3 contém o desenvolvimento do projeto, com as explanações sobre os objetivos apresentados, utilizando os itens descritos no capitulo 2 para apresentar os argumentos que justificam as conclusões obtidas em relação aos objetivos definidos no início do trabalho. É feita a comparação entre os métodos tradicionais e os métodos ágeis de desenvolvimento, bem como as vantagens e desvantagens de se utilizas métodos ágeis de desenvolvimento de software e também quais as características necessárias uma equipe de desenvolvimento de software deve ter para utilizar métodos ágeis durante um projeto de software. O capítulo 4 contém a conclusão do trabalho, onde são mostrados os resultados obtidos pela comparação entre os métodos tradicionais e os métodos ágeis de desenvolvimento. Também são mostradas as vantagens e desvantagens de se utilizar métodos ágeis de desenvolvimento de software e, por fim, são concluídas quais são as características necessárias uma equipe de desenvolvimento de software deve ter. No item 4.1 são apresentadas as contribuições que este trabalho oferece para os seus leitores e no item 4.2 são apresentados trabalhos futuros que podem utilizar este trabalho como base para o seu desenvolvimento. 5

16 2 MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE Neste capítulo descreveremos algumas das principais metodologias de desenvolvimento de software utilizadas por empresas na construção de softwares. Será dada uma visão geral nessas principais metodologias, sem se aprofundar em detalhes específicos de cada metodologia. Caso o leitor se interesse em se aprofundar em alguma metodologia citada, poderá utilizar as referências citadas durante o texto para tal. Primeiramente faremos um breve relato sobre métodos tradicionais de desenvolvimento de software, já que as mesmas têm um papel importantíssimo na história da Engenharia de Software, por ainda serem amplamente utilizadas em empresas de desenvolvimento de software desde o início da utilização de técnicas metodológicas para desenvolvimento de software. Por fim, aprofundaremos com mais intensidade em métodos ágeis de desenvolvimento de software; que tem ganhado grande espaço em empresas de desenvolvimento de software nos últimos anos e que será o tema principal deste trabalho. A Figura 1 mostra cronologicamente a evolução dos métodos de desenvolvimento de software mais conhecidos pela indústria de software. Na Figura 1 podemos ver que a maioria dos métodos ágeis surgiu antes mesmo do Manifesto Ágil [ManifestoAgil2001]. Neste trabalho falaremos abordaremos dois métodos tradicionais de desenvolvimento de software: Cascata, que é o primeiro método de que se tem conhecimento e tem importância histórica significativa. Também será abordado o método Espiral, por sem amplamente utilizado atualmente. Já em relação aos métodos ágeis de desenvolvimento, serão abordados os métodos XP e Scrum, por serem atualmente os mais pesquisados no meio acadêmico e mais utilizados pela indústria. 6

17 Figura 1. Histórico de publicação de metodologias de desenvolvimento de software. [Filho2008] 7

18 2.1 Metodologias tradicionais de desenvolvimento de software No início dos anos 70 a indústria de software passou a utilizar métodos de engenharia durante o desenvolvimento de software com o intuito de descrever processos que pudessem posteriormente ser replicados. Os métodos de engenharia proporcionam detalhes de como fazer para construir um software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos de software e de sistema, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. Os métodos da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada à linguagem especial e introduzem um conjunto de critérios para a qualidade de software. [Pressman2004] Como visto na definição acima, métodos de engenharia têm como principal função descrever detalhes de como fazer um software. Para tal, o uso de ferramentas e modelos que pudessem representar graficamente esse como fazer foram sendo desenvolvidos com o tempo. Diagramas UML, especificações, cenários de uso, planos de trabalho, definições de teste, relatórios, análises, entre outros, são algumas das formas de definir artefatos utilizados em cada fase do desenvolvimento de um software. Para cada fase do desenvolvimento de software uma série de artefatos é definida para detalhar como aquela fase será executada, de modo que a fase seguinte do desenvolvimento possa utilizá-los na continuação do desenvolvimento. Assim que a fase é concluída, a fase seguinte obtém os artefatos desenvolvidos anteriormente, os atualiza e produz novos artefatos que serão utilizados pela fase seguinte. Esses passos se repetem até que o produto final tenha sido finalizado. A documentação gerada é fortemente utilizada na comunicação e na interação entre as pessoas alocadas no projeto a ser desenvolvido. É também utilizada na comunicação com pessoas que estão fora do processo de desenvolvimento, tais como clientes e usuários. O uso da documentação detalhada serve para demonstrar para o cliente aquilo que será desenvolvido. O uso da documentação pressupõe que um grupo vasto de pessoas possa desenvolver o mesmo projeto sem que se dividam o mesmo ambiente de trabalho, sem se relacionarem verbalmente ou, até mesmo, sem ao menos se conhecerem. Mas o que vemos na prática é que apenas o uso de uma documentação detalhada não substitui a interação entre as pessoas envolvidas no processo de desenvolvimento de um software. 8

19 Mudanças constantes durante o processo de desenvolvimento de software, seja por alterações de requisitos ou falhas no planejamento inicial do projeto, podem resultar em uma documentação extremamente complexa e de difícil compreensão, mesmo para as pessoas envolvidas no processo de desenvolvimento desde o seu início. A interação entre os envolvidos no processo de desenvolvimento, nestes casos, é uma forma mais eficaz de se estabelecer como e quais tarefas serão realizadas para atender as constantes mudanças que o processo de desenvolvimento pode sofrer. 9

20 2.1.1 Método cascata O método cascata foi o primeiro método amplamente utilizado pela engenharia de software com o intuito de descrever todos os passos de todos os processos de desenvolvimento de software. O paradigma do ciclo de vida clássico da engenharia de software, às vezes chamado modelo cascata, requer uma abordagem sistemática, seqüencial ao desenvolvimento do software, que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação, teste e manutenção. [Pressman2004] Cada nível citado na definição acima pode ser caracterizado como uma fase do processo de desenvolvimento e deve prover uma série de artefatos que documentam cada fase. Todos esses artefatos são criados e posteriormente utilizados na fase seguinte. Abaixo estão descritas e detalhadas as seis fases que fazem parte do escopo de um projeto que utiliza o método cascata: Análise e engenharia de sistemas: Coleta de todos os requisitos para todos os elementos do sistema. A coleta desses requisitos é feita em nível de sistema e é feita a análise de alto nível nesses requisitos. Também é realizada uma análise de alto nível de requisitos tecnológicos, a fim de prever possíveis limitações de uso. Análise de requisitos de software: Nesta fase, a coleta dos requisitos de software é intensificada especificamente no software a ser desenvolvido, a fim de adquirir o conhecimento detalhado do negócio para o qual o software se propõe a tratar. As necessidades de desempenho, de interface e todos os outros métodos que os usuários terão para se relacionar com o software devem ser especificados, documentados e revistos com o cliente. Projeto: Esta fase define quatro atributos distintos do software: Modelagem, arquitetura, estrutura de dados e interfaces entre elementos e usuários do sistema. Todos os requisitos coletados na fase anterior devem ser cobertos nesta fase, a fim de atender todas as restrições e os níveis mínimos de desempenho e qualidade preestabelecidos. Como na fase anterior, o projeto é documentado e passa a fazer parte da especificação completa do sistema. 10

21 Codificação: A especificação completa do software deve ser traduzida de forma que a máquina consiga executar todas as tarefas definidas. O código gerado deve seguir exatamente o que foi especificado nas fases anteriores. Testes: Cada funcionalidade do software é testada e validada a fim de verificar se todos os requisitos e restrições definidas foram codificados de forma coerente com o que foi definido na especificação. Os testes podem ser do tipo caixa preta, que verifica apenas as interfaces que são disponibilizadas pelo sistema, ou podem ser do tipo caixa branca, que verifica o código gerado durante a fase de codificação. Manutenção: Erros ou mudanças de requisitos podem ser identificados pelo cliente durante a utilização. Assim, ajustes devem ser realizados no software para que estes erros sejam corrigidos e que os novos requisitos sejam implementados. Uma nova versão do software é construída e disponibilizada para o cliente, incluindo os ajustes e correções necessárias. Figura 2 Método cascata Mesmo sendo o mais antigo método utilizado para desenvolvimento de software, o método cascata possui alguns problemas em relação a sua aplicabilidade: 11

22 1. Os projetos reais dificilmente seguem um fluxo seqüencial. Interações podem ocorrer durante o desenvolvimento, o que traz problemas na utilização do método; 2. É praticamente impossível definir todos os requisitos do sistema no início do projeto. O método cascata exige que todos os requisitos sejam definidos no início do projeto; 3. O cliente só terá uma versão de software no final de todo o processo de desenvolvimento. Assim, verificações de usabilidade e erros na concepção do problema só serão descobertos depois do software estar pronto, o que causará alto custo de manutenção. Cada um desses problemas citados é real e embora o método cascata tenha essa fragilidade, ele é extremamente mais eficaz do que não utilizar método nenhum para desenvolvimento de software. 12

23 2.1.2 Método espiral O método espiral, também conhecido como método iterativo-incremental, apresenta duas inovações se comparado com o método cascata. Introdução do modelo iterativo; Inclusão de análise de riscos. No modelo iterativo as fases de desenvolvimento são realizadas várias vezes, definindo ciclos de desenvolvimento. Já a análise de riscos propõe momentos em que as pessoas envolvidas no projeto podem identificar e avaliar possíveis dificuldades encontradas durante o desenvolvimento. O método espiral utiliza a abordagem do método cascata como uma das etapas do ciclo de desenvolvimento. A cada iteração o software evolui e fica mais próximo da versão final que será entregue para o cliente. Quatro etapas são definidas a cada iteração. [Pressman2004] Essas quatro etapas são: Planejamento: Inicialmente são coletados os principais requisitos do sistema para realizar um planejamento de alto nível, determinar objetivos, alternativas e restrições do projeto. Depois do primeiro ciclo, a avaliação do cliente também será utilizada nessa iteração. Análise de riscos: São avaliados os riscos futuros do projeto, com base nos requisitos coletados. A partir dessa identificação, procura-se encontrar soluções para minimizar o impacto que estes riscos possam oferecer. Com essas soluções definidas, toma-se a decisão de seguir o desenvolvimento do projeto ou de cancelá-lo. Engenharia: O produto planejado durante a fase de planejamento é efetivamente implementado. Porém, não é desenvolvido todo o sistema de uma única vez. Apenas o que foi planejado para uma única iteração é desenvolvido. A cada nova iteração, um novo módulo do sistema é desenvolvido e integrado com os módulos desenvolvidos anteriormente. Para cada iteração da fase de engenharia, utiliza-se o modelo cascata ou outro modelo de desenvolvimento de software. Avaliação do cliente: O cliente avalia o que foi desenvolvido na fase de engenharia e acrescenta comentários, sugestões e alteração a serem realizadas. Essas avaliações do cliente serão utilizadas na nova iteração, como entrada para a etapa de planejamento. 13

24 A Figura 3 demonstra graficamente o modelo espiral e a interação entre os ciclos de desenvolvimento. Figura 3 Método Espiral (Adaptado de A análise de riscos possibilita a todos os envolvidos no projeto a possibilidade de periodicamente avaliar o andamento do projeto e priorizar a atenção em pontos específicos que podem se tornar impeditivos da continuidade futura do mesmo. Com isso, todos os envolvidos no projeto têm a obrigação de avaliar e modificar constantemente seus objetivos e a viabilidade do projeto, durante a sua execução. Muitas vezes o software produzido não atende as necessidades definidas pelo cliente, devido a falta de conhecimento de técnicas e de domínio completo do projeto como um todo. O caráter evolutivo desse método tem como foco principal o conhecimento gradativo do problema, adquirido a cada nova iteração, e com isso, mais tempo para análise e compreensão das necessidades do cliente. Contudo, a grande desvantagem do espiral é definir a quantidade de iterações que o projeto terá. Assim, torne-se extremamente complexo e difícil determinar quanto será o custo e quando será o prazo final para encerramento do projeto. 14

25 2.1.3 Outros métodos tradicionais de desenvolvimento de software Os métodos cascata e espiral foram abordados com mais detalhes neste trabalho devido a sua importância histórica e a sua relevância e utilização na indústria de software atual. Já o método espiral surgiu na metade da década de 80 e obteve grande sucesso, passando a ser muito utilizado até hoje em várias empresas de desenvolvimento de software. Além desses dois métodos tradicionais de desenvolvimento de software, podemos citar outros como Prototipação [Pressman2004] e o RUP (Rational Unified Process) [RUP1999] Prototipação O método de prototipação tem como base principal a criação de um pequeno protótipo do software que será desenvolvido com o intuito de, a partir desse protótipo, novos requisitos e necessidade do software sejam identificados e propiciar para o cliente a possibilidade de sugerir mudanças e identificar falhas na análise e no desenvolvimento do software. Um protótipo pode ser desenvolvido para que o cliente possa avaliar o design das telas e a facilidade de uso. Mas um protótipo também pode ser desenvolvido para que analisar a viabilidade da utilização de novas tecnologias ou para testar o desempenho do software, por exemplo, simulando a sua utilização em um ambiente com as mesmas características que terá o ambiente onde o software será instalado no cliente RUP Apesar de o RUP ser tratado por alguns autores como sendo um método ágil de desenvolvimento de software por se tratar de um método com várias características adaptativas, a maioria dos autores o descrevem como sendo um método tradicional de desenvolvimento. O método RUP surgiu em 1999, dentro da Rational Corporation, uma empresa americana que tinham como proprietários três especialistas em desenvolvimento de software: Ivar Jacobson, Grady Booch, e J. Rumbaugh. Em 2003 a Rational Corporation foi vendida para a IBM que, no entanto, preservou o nome do método já disseminado por todo o mundo naquele momento. O RUP define quatro fases principais no ciclo de desenvolvimento de um software. Iniciação, Elaboração, Construção e Transição. 15

26 Na Iniciação são definidos, em poucos dias, quais os objetivos, requisitos básicos e as prioridades principais do projeto. Na Elaboração são listados e detalhados todos os requisitos do sistema, além de se iniciar o desenho da arquitetura dos módulos prioritários do sistema. Já na Construção é realizada a implementação do software tendo como base os artefatos gerados nas fases anteriores. Por fim, na Transição o software final é entregue e são realizados ajustes e correções de possíveis bugs que o sistema venha a apresentar. Figura 4 Fases e volume de atividades para cada atividade do RUP [RUP2008] 16

27 2.2 Métodos ágeis de desenvolvimento de software Neste capítulo vamos descrever a origem e as os princípios básicos dos métodos ágeis e descreveremos dois dos métodos ágeis (Scrum, XP) mais discutidos e utilizados atualmente, tanto no meio acadêmico quanto na indústria de software. Scrum e XP foram escolhidos para serem detalhados neste trabalho por serem métodos ágeis que podem ser utilizados em conjunto, já que Scrum tem como foco principal o gerenciamento de um projeto de desenvolvimento de software enquanto XP tem como foco principal definir as técnicas que serão utilizadas na fase de programação de um projeto de desenvolvimento de software. Também serão brevemente citados outros métodos ágeis de desenvolvimento de software e, caso haja interesse no aprofundamento dessas metodologias, mais detalhes poderão ser obtidos utilizando as referências citadas no texto. 17

28 2.2.1 Origem dos métodos ágeis de desenvolvimento de software Como visto anteriormente, os métodos tradicionais se baseavam fortemente em atividades predefinidas, com extensa documentação e processos prescritivos. Assim, utilizando as metodologias tradicionais de desenvolvimento de software o trabalho dos analistas de desenvolvimento se inicia com a coleta de todos os requisitos do software, com a elaboração de um projeto completo de alto nível, seguida da implementação e de testes, finalizando com a manutenção do software já pronto. Na década de 90 começaram a surgir novos métodos de desenvolvimento baseados em dois pontos principais: melhor comunicação entre a equipe e em processos que melhor se adaptam às mudanças dos requisitos. O primeiro ponto, que trata da melhor comunicação entre a equipe, foi abordado devido a constatação que grande parte da documentação gerada durante o processo inicial do desenvolvimento de software torna o processo de implementação muito burocrático, tirando a capacidade criativa dos desenvolvedores. Além disso, a manutenção dos documentos gerados durante o processo de análise dos requisitos se torna uma tarefa complexa caso haja mudanças de requisitos durante o processo de desenvolvimento, além de causar impacto em todos os processos que foram desenvolvidos baseados na documentação que foi alterada. A comunicação contínua entre os membros da equipe, gerando documentos menos complexos, mas com maior qualidade de informação, diminui o impacto das mudanças de requisitos durante o processo de desenvolvimento e aumenta o grau de entendimento do problema a ser resolvido, já que todos os membros da equipe estão em constante comunicação, trocando experiências e expondo lições aprendidas durante o desenvolvimento do software. Já o segundo ponto, que trata de processos que melhor se adaptam às mudanças dos requisitos, foi abordado devido a percepção da maioria dos especialistas em desenvolvimento de software de que, o melhor e mais eficaz método de coleta de requisitos de um sistema se dá de forma gradual, de acordo com o andamento do projeto e com o aprimoramento do entendimento do negócio o qual o software a ser desenvolvido se propõe a tratar por parte da equipe envolvida no projeto, além da grande quantidade de requisitos que se alteram durante o andamento do projeto. 18

29 A coleta total de requisitos no início do projeto é praticamente impossível, devido a falta de entendimento completo do negócio, além de ser custosa alteração dos requisitos durante o processo de desenvolvimento. Visto isso, pode-se dizer que os métodos ágeis de desenvolvimento de software utilizam métodos incrementais e iterativos e são aplicados a equipes auto gerenciáveis e auto organizáveis, onde todos os membros da equipe têm participação e voz ativa em todas as etapas do desenvolvimento, tendo como alicerce principal a troca de conhecimento entre todos os membros da equipe, aliado a uma documentação enxuta, mas de alto valor para o entendimento, manutenção e futura replicação do software a ser desenvolvido. Depois de muitos anos de experiência, dezessete especialistas em desenvolvimento de software, que não utilizavam os métodos tradicionais e sim métodos de desenvolvimento seguindo os dois pontos abordados anteriormente, verificaram que seus métodos de trabalho, além de serem mais eficazes e produzirem software com melhor qualidade, possuíam vários pontos em comum. Assim, em 2001, estes dezessete especialistas se reuniram durante um final de semana em uma estação de ski no estado de Utah, EUA, para discutir seus métodos de trabalho e proporem uma nova metodologia de desenvolvimento de software para substituir os métodos tradicionais. Durante a reunião, os dezessete especialistas não conseguiram definir uma metodologia de desenvolvimento, já que chegaram a conclusão que desenvolver software é uma tarefa extremamente complexa e é impossível defini-la em um único processo. De acordo com o que foi debatido, desenvolver software é uma tarefa que depende praticamente de pessoas em todas as suas etapas, além de ser composta de um número grande de variáveis que podem se alterar durante as etapas de desenvolvimento. Contudo, o grupo chegou a conclusão que uma série de princípios básicos deviam ser seguidos para garantir a qualidade do software a ser desenvolvidos. Ao final da reunião foram definidos doze princípios básicos para a obtenção de bons resultados no desenvolvimento de software. Estes doze princípios são: 1. A prioridade é satisfazer o cliente através de entregas contínuas e freqüentes; 2. Receber bem as mudanças de requisitos, mesmo em uma fase avançada do projeto; 3. Entregas com freqüência, sempre na menor escala de tempo; 19

30 4. As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente; 5. Manter uma equipe motivada fornecendo ambiente, apoio e confiança necessários; 6. A maneira mais eficiente da informação circular é através de uma conversa face-a-face; 7. Ter o sistema funcionando é a melhor medida de progresso; 8. Processos ágeis promovem o desenvolvimento sustentável; 9. Atenção contínua à excelência técnica e a um bom projeto aumentam a agilidade; 10. Simplicidade é essencial; 11. As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas; 12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz. [ManifestoAgil2001] A partir desses doze princípios básicos, foi publicado o Manifesto Ágil, que os representa em quatro premissas: 1. Indivíduos e iterações são mais importantes do que processos e ferramentas 2. Software funcionando é mais importante do que documentação completa 3. Colaboração com o cliente é mais importante do que negociação de contratos 4. Adaptação a mudanças é mais importante do que seguir o plano inicial [ManifestoAgil2001] 20

31 2.2.2 Valores ágeis Neste capítulo serão recapituladas as quatro premissas básicas definidas no Manifesto Ágil. Para cada uma delas será dada a abordagem completa da sua essência e o porquê de serem definidas como pontos chave para melhor desenvolvimento de um software. Essas quatro premissas básicas também são conhecidas como valores ágeis de desenvolvimento de software. Primeiro valor ágil: Indivíduos e iterações são mais importantes do que processos e ferramentas. [ManifestoAgil2001] Este valor ágil vem de encontro com o primeiro ponto abordado no item : Quanto melhor for a comunicação e a troca de experiências e lições aprendidas entre os membros da equipe de desenvolvimento, mais rápido e melhor será o desenvolvimento do software. A mudança de foco do processo e das ferramentas de desenvolvimento para os indivíduos e suas interações causa uma grande desconfiança por parte dos analistas e desenvolvedores mais conservadores, pois se trata de uma mudança radical em relação aos métodos tradicionais de desenvolvimento, já que estes têm seu foco justamente em processos extremamente rígidos e predefinidos, que devem ser seguidos do início ao fim do projeto. Mas como já foi dito anteriormente, a burocracia causada pela grande quantidade de documentos gerados e a rigidez dos processos que devem ser seguidos ao se utilizar metodologias tradicionais não são o foco principal do desenvolvimento do software, segundo os formuladores do Manifesto Ágil. Pelo contrário, eles definem como essencial para o desenvolvimento a comunicação e a troca de experiências e lições aprendidas entre os integrantes da equipe de desenvolvimento. Segundo valor ágil: Software funcionando é mais importante do que documentação completa. [ManifestoAgil2001] Outro ponto que pode causar desconfiança por parte de analistas e desenvolvedores acostumados a desenvolver software utilizando métodos tradicionais é entregar constantemente para o cliente, mesmo que pequenos, módulos do software em funcionamento ao invés de gastar um longo período de tempo e esforço para preparar a documentação completa do software a ser desenvolvido. Entregando pequenos módulos do software funcionando em um curto intervalo de tempo mostra-se mais eficaz do que entregar a documentação completa do software de uma única vez e, após um longo período de tempo, entregar o software completo. Isto se deve ao fato de que software 21

32 funcionando gera para o cliente a sensação de que o projeto realmente está em pleno funcionamento, que suas necessidades estão sendo atendidas e que o problema a ser tratado pelo software está sendo resolvido. A cada nova entrega de um módulo de software funcionando, ele é integrada com os módulos que já havia sido entregues e integrados anteriormente. Assim, o cliente tem condição de sugerir melhorias do software durante a etapa de desenvolvimento e não apenas ao final de todo o seu ciclo, o que diminui o custo de manutenção e faz com que o cliente tenha, ao final do projeto, um software que atenda o mais próximo possível todas as suas necessidades iniciais. A Figura 5 mostra a diferença entre o custo de manutenção utilizando a metodologia tradicional Cascata [item ] e a metodologia ágil XP [item ]. Figura 5 Comparação de custo de mudança entre cascata e XP. [Filho2002] O que se pode verificar na Figura 5 é que na fase inicial do projeto, a metodologia XP tem maior custo de mudança em relação à metodologia Cascata. Isso se deve ao fato das constantes mudanças de requisitos e melhorias sugeridas pelo cliente durante a fase de desenvolvimento. Já na metodologia cascata, a mudanças de requisitos e as melhorias sugeridas pelo cliente só serão atendidas após a entrega do software pronto. Neste caso, qualquer alteração no software pode causar impacto em vários módulos do mesmo, aumentando a complexidade e o custo de qualquer modificação que tenha que ser realizada. Na pior das hipóteses, o cliente pode chegar à conclusão que o software desenvolvido não atende às suas necessidades, gerando o trabalho de se desenvolver praticamente todo o sistema novamente. Terceiro valor ágil: Colaboração com o cliente é mais importante do que negociação de contratos. [ManifestoAgil2001] Este terceiro valor ágil está fortemente ligado com o segundo valor ágil. Ele destaca o fato de que a colaboração e a interação constante com o cliente e muito mais importante e eficaz do que a negociação de contratos. 22

33 Para a equipe de desenvolvimento a constante colaboração do cliente faz com que a equipe tenha maiores e melhores condições de desenvolver o software que o cliente espera, já que o entendimento do negócio a ser tratado pode ser ampliado e melhor esclarecido a cada interação, além das constantes sugestões de melhorias que o cliente pode sugerir durante o desenvolvimento, o que faz com que o software esteja cada vez mais próximo do que o cliente espera receber. Para o cliente o constante contato com a equipe de desenvolvimento garante que o entendimento do problema a ser tratado pelo software a ser produzido esteja sempre em evolução, fazendo com que a equipe esteja alinhada com a linha de pensamento do cliente, não deixando para depois da entrega do software a percepção de que o que foi desenvolvido não atende as necessidades do cliente. Outro fator positivo para o cliente desse constante contato com a equipe de desenvolvimento é o fato do acompanhamento do projeto ser mais freqüente, fazendo com que possíveis mudanças no cronograma do projeto sejam melhor gerenciadas e discutidas em conjunto, minimizando assim possíveis desvios de custos e prazos de entrega de entrega do software. Quarto valor ágil: Adaptação a mudanças é mais importante do que seguir o plano inicial. [ManifestoAgil2001] O último valor ágil definido pelo método ágil é muito baseado em técnicas iterativas e incrementais, uma vez que sugere que, mais importante do que seguir a qualquer custo o plano inicial é estar sempre apto a se adaptar as mudanças surgem durante o ciclo de desenvolvimento. Coletar todos os requisitos de um software no início do projeto e garantir que estes requisitos não se alterem é praticamente uma utopia do desenvolvimento de software. A experiência de vários especialistas em desenvolvimento desde o início da computação garante que a identificação completa de todos os requisitos do sistema durante a fase inicial do projeto é praticamente impossível devido à dificuldade de entendimento de todo o problema a ser tratado pelo software a ser desenvolvido e também as constantes alterações dos requisitos do software devido a mudanças estratégicas da empresa durante o ciclo de desenvolvimento ou devido a evoluções tecnológicas que podem surgir durante este período. Estar em constante contato com o cliente, verificando possíveis alterações estratégicas que podem surgir; definir ciclos de desenvolvimento mais curtos, diminuindo e priorizando o escopo das iterações, garantindo que as possíveis alterações de um requisito não aconteçam durante a iteração em que se esteja desenvolvendo o módulo do sistema que trata especificamente do requisito alterado 23

34 e, após a alteração do requisito, identificar rapidamente quais módulos do software sofrem impacto com a alteração do requisito e devem ser alterado, são formas de diminuir o custo de manutenção do software e garantir que qualquer mudança que ocorra durante o ciclo de desenvolvimento venha a ser rapidamente adaptada ao software que está sendo construído. 24

35 2.2.3 Características comuns entre métodos tradicionais e métodos ágeis Algumas características são comuns entre os métodos tradicionais e os métodos ágeis de desenvolvimento de software. Neste item abordaremos algumas dessas características comuns entre os métodos, que podem ser utilizadas durante o projeto de desenvolvimento de um software independentemente do tipo do método definido para o projeto. Segundo [Filho2008], essas características comuns entre os métodos são: testes, desenvolvimento iterativo, desenvolvimento incremental, colaboração, estimativas, negociação e priorização. Neste trabalho serão abordados somente as seguintes características: testes, desenvolvimento iterativo e desenvolvimento incremental. Testes: Nos métodos tradicionais de desenvolvimento de software, a fase de testes e a fase de implementação são duas fases completamente distintas. Já nos métodos ágeis de desenvolvimento de software as duas fases são realizadas simultaneamente, já que a mesma pessoa que desenvolve o código do software também escreve os casos de teste e testa o software desenvolvido. A criação e a execução dos casos de teste já na fase inicial do desenvolvimento do software facilitam e identificam falhas no desenvolvimento em um estágio inicial do desenvolvimento, facilitando a sua correção e impedindo que o erro se propagasse ou afetasse outros módulos do software. O uso de testes automatizados desde o início do projeto também é outra característica dos métodos ágeis de desenvolvimento de software, facilitando a execução dos testes e garantindo que todos os requisitos são atendidos, mesmo após a implementação e integração com um novo módulo do software. Desenvolvimento iterativo: É uma característica utilizada em todos os métodos ágeis de desenvolvimento de software, mas não em todos os métodos tradicionais. Como visto neste trabalho, desenvolvimento iterativo é uma característica do método Espiral, mas não do método Cascata. Essa característica define que o desenvolvimento de software será realizado de forma iterativa, isto é, o desenvolvimento de software será realizado em partes e, ao final de cada parte, o novo módulo do software produzido é integrado com os módulos já finalizados. Desta forma é mais fácil a adaptação da equipe de desenvolvimento e menos 25