CURSO SUPERIOR DE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS ROSANGELA CATHIA SILVA COSTA ANTONIO DE PADUA LINO DANTAS EDUARDOSERGIO

DA SILVA ATHAN GIL RAMISON SANTOS EVANGELISTA DE CASTRO JONATHAS MARCELLO GUIMARAES DE SOUZA WALLACE DIAS BEZERRA

ATIVIDADE DE PORTFÓLIO
ATIVIDADE DE PRODUÇÃO TEXTUAL

Juazeiro-BA 2010

ROSANGELA CATHIA SILVA COSTA

ANTONIO DE PADUA LINO DANTAS EDUARDOSERGIO DA SILVA ATHAN GIL RAMISON SANTOS EVANGELISTA DE CASTRO JONATHAS MARCELLO GUIMARAES DE SOUZA WALLACE DIAS BEZERRA

ATIVIDADE DE PORTFÓLIO
ATIVIDADE DE PRODUÇÃO TEXTUAL

Trabalho apresentado ao Curso (Tecnlogia em Analise e Desenvolvimento de Sistemas) da UNOPAR Universidade Norte do Paraná, para a disciplina [ENGENHARIA DE SOFTAWARE] Orientador: Prof. Luis Flavio Perini

Juazeiro-BA 20-10-2010 SUMARIO

1 – INTRODUÇÃO 2- CONCEITO 3- DESENVOLVIMENTO SOFTWARE 3.1 Processo de Desenvolvimento de Software Sistematizado 3.1.1 Fases do Desenvolvimento de Software 3.1.1.1 Fase de Definição 3.1.1.2 Fase de Desenvolvimento 3.1.1.3 Fase de Manutenção 3.2 MODELOS DE PROCESSO DE SOFTWARE 3.2.1Modelo Sequencial Linear 3.2.2Modelo de Prototipagem 3.2.3Modelo RAD – Rapid Application Development 3.3 MODELOS DE PROCESSOS EVOLUCIONÁRIOS 3.3.1 Modelo Incremental 3.3.2 Modelo Espiral 3.4 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAIS OU “PESADAS 3.4.1 RUP – Rational Unified Process 3.5 METODOLOGIAS DE DESENVOLVIMENTO ÁGEIS OU LEVES 3.5.1 Extreme Programming – XP 3.5.2 Feature driven development – FDD 3.5.2.1 SCRUM 4 – CONCLUSÃO 5- REFERENCIAS

INTRODUÇÃO

Este trabalho propõe uma análise comparativa de duas frentes destas metodologias, as tradicionais, que têm como característica a grande quantidade de documentos gerados, “atrasando” o desenvolvimento do projeto, e as metodologias ágeis, que se opõem às tradicionais evitando, sempre que possível, a documentação e focando a codificação do projeto. Para isso linguagens para modelagem do sistema, como a UML, foram criadas. Além das linguagens, principalmente, foram desenvolvidas metodologias de desenvolvimento de software, onde passos eram detalhados para que o processo de desenvolvimento seguisse um padrão e assim atingisse a qualidade necessária. Com o tempo, as metodologias se tornaram mais complexas e distintas melhorando a qualidade do produto, independente do foco do sistema sempre haveria uma metodologia para manter a qualidade. Este trabalho propõe uma análise comparativa de duas frentes destas metodologias, as tradicionais, que têm como característica a grande quantidade de documentos gerados, “atrasando” o desenvolvimento do projeto, e as metodologias ágeis, que se opõem às tradicionais evitando, sempre que possível, a documentação e focando a codificação do projeto.

2 - Conceito

Desde a Crise do Software, que forçou com que as Software Houses realizadas sem projetos de desenvolvimento de Software de uma maneira mais profissional e organizada, gerando uma documentação para acompanhar o produto, muitas metodologias para esse desenvolvimento surgiram. Linguagens foram criadas para modelar e facilitar o entendimento do produto pelo cliente e pela própria empresa desenvolvedora. Essa documentação gerada a partir na análise da especificação dos projetos, era acompanhada de um método de desenvolvimento para especificar ao cliente o que seria desenvolvido e como isso seria feito. Foi então que surgiram Métodos para visualizar o processo de desenvolvimento, dividindo-o em etapas, sempre com foco na qualidade final do produto. Os processos sempre começavam com uma primeira etapa de Análise, onde os requisitos eram estabelecidos de acordo com a necessidade do cliente. Depois da Análise, tem-se a Modelagem que gera os documentos necessários e por último o Desenvolvimento e a fase de Testes. Levando-se em consideração que o processo de desenvolvimento é bastante mutável, pois o surgimento de novos requisitos (tanto funcionais como não funcionais) por parte do cliente é normal, assim como a não conformidade de algumas solicitações, era necessário alterar constantemente a documentação e o produto em si. Isso demandava muito tempo. Para circular esse problema de constantes alterações, assumindo que essas mudanças fazem parte do processo de desenvolvimento surgiram os Métodos Ágeis, aqueles com foco no código e otimizados para alterações de requisitos, como a Extreme Programming, esses métodos também prezam pela qualidade do Software, mas a sua filosofia de desenvolvimento é diferente, dando ênfase principalmente no código, sendo que as alterações necessárias não devem acarretar em tanto tempo gasto. Com o surgimento recente de novas Metodologias de Desenvolvimento de Software – MDS, que dividiram o processo de desenvolvimento de Software, para organizá-lo, planejá-lo e facilitar o entendimento do mesmo,

existem agora duas principais áreas de atuação, o Desenvolvimento chamado Tradicional, com embasamento na Análise e Projeto, mantendo tudo em documentos, porém se tornando lento para mudanças, e o Desenvolvimento Ágil, baseado em código, totalmente adaptável a mudanças nos requisitos, entretanto fraco na parte contratual e de documentos. O trabalho faz um comparativo entre as Metodologias de Desenvolvimento Tradicional e o Ágil, analisando pontos fortes e fracos de cada uma e os pontos em comum.

3 – Desenvolvimento do software Na década de 70, a atividade “desenvolvimento de software” era executada de forma desorganizada, desestruturada e sem planejamento, gerando um produto final de má qualidade, pois não existia documentação ou era entregue fora do prazo ou o levantamento de tempo e esforço não correspondia com a real necessidade. Muitas vezes, esta atividade não satisfazia as necessidades do cliente, desperdiçando recursos da empresa e aumentando gastos, que não viriam a ser compensa- dores para o cliente, demandando tempo, esforço e dinheiro, essa época ficou conhecida com Crise do Software [PRESSMAN 02]. A partir deste cenário, surgiu a necessidade de tornar o Desenvolvimento de Software como um processo estruturado, planejado e padronizado, para que as necessidades fossem atendidas e os gastos com informatização de processos de informações se tornassem compensadores. Para o atendimento desta padronização, surgiram Metodologias de Desenvolvimento, que dividem o processo de desenvolvimento em fases prédefinidas. Essas Metodologias se adequam às características organizacionais e ao ambiente de desenvolvimento implementado em uma organização, ao paradigma de desenvolvimento e ao tipo de plataforma que o Software deve ser desenvolvido, e às características dos projetos: o tempo que pode ser gasto e a real necessidade do cliente, a fim de estimar custos e prazos reais. Entretanto, a Crise do Software perdura até hoje, onde, mesmo com técnicas avançadas de desenvolvimento e padrões consolidados na área de criação de Softwares, ainda existem características da época da Crise, como Projetos atrasados, erros de estimativa de custos e de tempo, que tornam o Processo, ainda que sistematizado, passível de muitos erros. 3.1 - Processo de Desenvolvimento de Software Sistematizado

No início da padronização do Processo de Desenvolvimento, foram mantidos conceitos típicos de Engenharia, que ajudaram a sistematizar o processo, e mais tarde, criando a Engenharia de Software. Fritz Bauer [PRESSMAN 02] define a Engenharia de Software como: “A criação e utilização de sólidos princípios da Engenharia a fim de obter software de

maneira econômica, que seja confiável para trabalhar eficientemente em máquinas reais”. Engenharia é a análise, o projeto, a construção (desenvolvimento), a verificação e a gestão de elementos técnicos. O Processo de Desenvolvimento de Software, assim como qualquer outro, tem um compromisso com qualidade, sendo que esse enfoque na qualidade se desenvolveu com o passar do tempo, dando surgimento a métodos e abordagens de Engenharia de Software cada vez amadurecidos, para gerar produtos de qualidade melhor e a menores custos. A Engenharia de Software é dividida em camadas, que tem como foco principal a qualidade final do produto gerado, e como maneira de chegar até ela é o aperfeiçoamento do Processo de Desenvolvimento, que consiste na criação de documentos, artefatos e marcos capazes de representar o contexto do software, levando em consideração recursos, ferramentas, prazos, restrições, e outros aspectos que envolvem o desenvolvimento de um produto de software [PRESSMAN]. Para auxiliar nesse processo existem Métodos de Engenharia de Software que fornecem técnicas de construção, que abrangem a análise de requisitos, projetos, construção de programas, testes e manutenção. E ainda as Ferramentas, que servem apenas para fornecer apoio automatizado para processos e métodos. Numa visão geral do processo de desenvolvimento de um software pode-se subdividí-lo em três fases genéricas, ou seja, independem da área de aplicação, tamanho ou complexidade do projeto. 3.1.1 Fases do Desenvolvimento de Software Numa visão geral do processo de desenvolvimento de software, a literatura especializada costuma subdividi-lo em três fases genéricas, ou seja, independem da área de aplicação, tamanho ou complexidade do projeto. Estas três fases serão detalhadas a seguir [SOMMERVILLE ]. 3.1.1.1 Fase de Definição

É uma das fases principais do projeto, pois é onde se procura identificar funcionalidades, restrições, validações, interfaces e, principalmente, os requisitos-chave, que o projeto necessita. É uma fase de muita interação com o cliente para validar todas as informações por ele passadas e com ele coletadas, a fim de que todos os requisitoschave sejam atendidos de maneira correta no decorrer da implementação do produto de software. É composta de três sub-tarefas principais, que são executadas independente dos métodos utilizados nesta fase, que podem variar de acordo com o paradigma usado. As sub-tarefas são: a Engenharia de Sistemas, que visa entender e definir objetivos do sistema; o Planejamento do Projeto, que tenta determinar com o máximo de exatidão, custos, tempo, esforço e recursos que são necessários para conclusão do projeto; e a Análise de Requisitos, a fim de entender os requisitos (necessidades) específicos necessários para construir um software de qualidade. 3.1.1.2 Fase de Desenvolvimento Tenta definir como os dados serão estruturados, como a função deve ser implementada. Em outras palavras, é quando o projeto, que antes estava todo documentado em papel, passa a ser transformado em código para entrar em operação de fato. Linguagens de programação, técnicas e métodos, podem ser diferentes, dependendo da metodologia escolhida, porém tarefas básicas, comuns a todas as metodologias, devem ser realizadas, como o Projeto de Software, parte central do desenvolvimento, que mostra o que e como será desenvolvido, e a Geração de Código, que é traduzir em linguagem de programação o que foi especificado no projeto de software. Alguns autores colocam a fase de testes dentro da fase de Desenvolvimento, como parte das tarefas básicas dessa fase, porém o mais importante é que ela, não pode deixar de existir, pois é justamente nesta fase que se encontram não conformidades com aquilo que foi especificado na fase de Definição, que não atende as exigências do cliente, diminuindo assim a qualidade final do produto. 3.1.1.3 Fase de Manutenção

É a fase final, pois nela se analisa todo o produto. Tem como foco principal as modificações, sejam elas correções de erros, adaptações necessárias e novas funcionalidades (melhorias) para evoluir o software. Como alterações ocorrem, a fase de manutenção engloba algumas características das fases anteriores, porém seu enfoque passa a ser um software já existente. É nesta fase onde as empresas que desenvolvem softwares obtêm maior parte dos lucros, pois contratos de manutenção são assinados garantindo receita fixa.
Existem quatro tipos de modificações que podem ocorrer, durante a fase de manutenção. São elas:
• •

Manutenção Corretiva: visa corrigir defeitos que ocorreram durante a fase de desenvolvimento; Manutenção Adaptativa: modifica o software para adaptá-lo à alterações no ambiente externo, composto de variáveis que não do escopo do sistema, como uma mudança de sistema operacional;

Manutenção Perfectiva: adiciona novas funcionalidades ao software. Essas novas especificações estão fora do projeto original, e devem ser consideradas como melhorias de produto;

Manutenção Preventiva: assume que mudanças, tanto no ambiente externo, quanto de especificações, vão ocorrer, portanto já prepara o produto para que o impacto causado por essas alterações não afete o software. Também é conhecida como Reengenharia de Software, que nada mais é que a reconstrução de algo real que já foi desenvolvido, para melhorá-lo.

3.2

MODELOS DE PROCESSO DE SOFTWARE Para tornar o desenvolvimento de software uma atividade menos

caótica, surgiram os Modelos de Processo de Software, que visam organizar o

desenvolvimento [SOMMERVILLE]

utilizando

as

técnicas

e

métodos

descritos

acima.

Dependendo do tipo de projeto a ser desenvolvido modelos diferentes serão utilizados, porém todos seguem um determinado ciclo, onde existem quatro fases distintas, que vão caracterizar o modelo. A primeira fase é a Situação Atual, que define como está o ambiente. A Definição do Problema indica qual o problema específico que está se tentando resolver. O Desenvolvimento Técnico, que resolve o problema de maneira que satisfaça as necessidades, e, por último, a Integração da Solução, que entrega a solução ao cliente. Essas quatro fases, quando colocadas em seqüência, formam um ciclo, sendo que dentro de cada uma dessas fases desse ciclo, existe um outro ciclo mais interno com um problema em escala menor, e assim sucessivamente, deixando uma idéia de recursividade. Essa recursividade acaba em níveis racionais, quando uma solução resolver o problema definido [PRESSMAN]. As seções a seguir descrevem sucintamente cada um dos modelos encontrados nas literaturas especializadas [SOMMERVILLE], [PRESSMAN]. 3.2.1 Modelo Sequencial Linear Esse modelo, proposto em 1970, é também conhecido como Modelo em Cascata onde as fases definidas são sistematicamente seguidas de maneira linear [PRESSMAN 02]. É o modelo mais usado em todo o mercado, porém não é o mais eficaz, pois raros projetos seguem esse fluxo linear, além das mudanças de requisitos que ocorrem no decorrer do projeto não serem de fácil adaptação, porque alteram toda a documentação já desenvolvida, o que implica em retrabalho [PRESSMAN 02]. Mesmo com todos estes problemas, este modelo ainda é bem melhor e mais eficiente que um projeto que não segue nenhum padrão. O modelo é dividido em etapas pré-definidas, que são: Modelagem, uma vez que o software interage com o sistema, é importante saber como o mesmo funciona a fim de prover a compatibilidade com os demais módulos existentes do

sistema como um todo. Análise, onde os requisitos do software são levantados (elicitados) e definidos para entender como o software funcionará. Projeto, que é a representação dos requisitos, é subdividido em 4 atributos: Estrutura de Dados, que é a maneira que os dados vão ser tratados, Arquitetura de Software, que define a base estrutural de como o sistema deve ser desenvolvido, Caracterizações das Interfaces, repre- sentam o meio entre o usuário e o sistema, bem como entre os módulos do sistema, e Detalhes Procedimentais [PRESSMAN 02]. A Codificação, que traduz os requisitos especificados nas etapas anteriores em linguagem de máquina. Testes, os quais são responsáveis por identificar se todas as funcionalidades desenvolvidas estão funcionando perfeitamente, ou seja, garantir que esteja de acordo com o que foi especificado. Por último a Manutenção, que corrige erros encontrados após a liberação para o cliente, implementando melhorias ao produto, isso implica em um novo ciclo de desenvolvimento. 3.2.2 Modelo de Prototipagem Esse modelo é muito utilizado quando nem todos os requisitos de sistema são definidos de maneira clara pelo cliente. Apenas os objetivos de sistema são descri- tos, mas não a maneira com que os dados serão processados e como a saída será mostrada. A característica principal desse modelo é gerar protótipos do sistema com definições de requisitos dadas pelo cliente. Essas definições geram documentos que, por sua vez resultam no protótipo. Esse protótipo é então testado pelo cliente para validar suas funcionalidades [PRESSMAN 02]. Após o teste do protótipo o ciclo de desenvolvimento se repete. O engenheiro de software, que é aquele responsável por fazer a coleta das necessidades do cliente, juntamente com o cliente faz o levantamento de novas funcionalidades, que serão desenvolvidas e adicionadas ao protótipo já criado. Quando todas as funcionalidades que o sistema deveria prover estiverem desenvolvidas e validadas, o protótipo é descartado para que o sistema real seja desenvolvido com base no que foi especificado com o protótipo, agora dando ênfase, também, a características não-funcionais: segurança, manutenibilidade e qualidade do produto; procurando soluções ideais para os problemas.

O modelo de prototipagem tem a grande vantagem de gerar resultados visíveis para o cliente de uma maneira veloz, e ao final de cada ciclo, onde novas funcionalidades são adicionadas, pode mostrar a evolução do sistema. Por se tratar de protótipos, nem sempre a solução escolhida para resolver tal problema é a ideal, pois não leva em consideração as variáveis de ambiente, como o sistema operacional onde o software funcionará ou se a linguagem de programação é adequada. O desenvolvedor pode acabar se acostumando com a idéia de utilizar o protótipo que foi gerado como parte integral do sistema, deixando “brechas” e possíveis erros [PRESSMAN 02].
3.2.3 Modelo RAD – Rapid Application Development

O RAD é um modelo incremental, considerado uma adaptação para projetos curtos, usualmente com prazo máximo de 90 dias, do modelo sequencial linear. Sua principal característica é que o produto de software seja desenvolvido em componentes, tempo. Igualmente aos outros modelos, o RAD é subdividido em fases, que são:

pois

a

reutilização

de

código

permite

que

a

equipe

de

desenvolvimento possa desenvolver um sistema completamente funcional em pouco

Modelagem de Negócios: responsável por definir arquiteturas que

permitam ao negócio (sistema) utilizar informações colhidas de maneira efetiva;

Modelagem de Dados: responde a questões relacionadas a objetos de

dados utilizando diagramas como o modelo de entidade e relacionamento (MER);

Modelo de Processo: descreve os processos básicos para manipular

as informações contidas nos objetos de dados gerados pela fase anterior, montando assim um fluxo de informações;

Geração da Aplicação: utiliza ferramentas automatizadas para criar ou

reusar componentes já desenvolvidos;

Teste e Entrega: testa a integração entre componentes já criados em

outros projetos que foram reutilizados e os que foram desenvolvidos para o atual projeto. Testa-se também as interfaces criadas. RAD, assim como outros modelos, possui desvantagens. Visto que a principal característica do RAD é a modularização, e para isso os requisitos precisam estar bem definidos e com um certo grau de independência entre eles. Se uma das situações citadas não ocorrerem o modelo pode não ser adequado. Para que o RAD possa ser utilizado de maneira eficiente, é necessário que existam uma quantidade de recursos suficientes para montar as equipes RAD de desenvolvimento. Isto é considerado como um grande problema nos projetos grandes, pois são mais difíceis de gerenciar. 3.3 Modelos de Processos Evolucionários Assumindo que os sistemas tendem a evoluir durante o

desenvolvimento e essa evolução acrescenta novas funcionalidades ao projeto, que aumenta as especificações e, como uma “bola de neve”, crescem até que estouram o prazo definido na negociação, os modelos evolucionários têm como principal característica a interatividade, com isso é possível desenvolver versões do sistema que a cada novo lançamento (release) agrega novas funcionalidades. As seções a seguir descrevem alguns exemplos de Modelos Evolucionários [PRESSMAN 02], [SOMMERVILLE 00]. 3.3.1 Modelo Incremental Esse modelo é a “versão” evolucionária do Modelo Sequencial Linear. Apenas assume que o software desenvolvido pode sempre crescer e agregar novas funcionalidades, sendo que cada uma dessas funcionalidades, ou o conjunto delas, será desenvolvido por um incremento e esse incremento segue todas as etapas descritas no modelo linear [PRESSMAN 02]. O primeiro incremento deste modelo é chamado de Núcleo do Produto, pois nele estarão as principais funcionalidades do sistema, aquelas consideradas vitais. Os próximos incrementos desenvolvidos agregarão as funções do Núcleo do Produto e dos incrementos anteriores já desenvolvidos. Esse modelo é

análogo a uma “bola de neve” que cresce e atinge sua totalidade quando o produto está completamente desenvolvido [PRESSMAN 02]. O modelo incremental é muito utilizado em projetos longos e que tendem a crescer com o passar do tempo e o prazo de entrega é curto. Como, ao final de cada incremento, é gerada uma versão do produto final, é possível mostrar ao cliente como está o andamento do projeto e atingir as metas definidas no começo do projeto.
3.3.2 Modelo Espiral

O Modelo Espiral é um modelo iterativo, como o modelo de prototipagem, e sistemático como o Modelo Linear. Isso facilita com que sejam lançadas versões utilizáveis do projeto ao final de cada iteração do modelo, similar ao modelo incremental. É muito utilizado no desenvolvimento de softwares em conjunto com o paradigma da orientação a objetos, onde o desenvolvimento em módulos, somado ao processo de integração, se encaixa nos conceitos do paradigma [PRESSMAN 02]. Esse modelo se subdivide em Regiões de Tarefa. Essas regiões abrigam conjuntos de tarefas que crescem proporcionalmente ao risco e ao tamanho do projeto. Basicamente existem 6 regiões, sendo que todas podem ser usadas, ou não, em um projeto. São elas: Comunicação com o Cliente, a fim de manter contato com o cliente, adquirindo informações úteis ao sistema; Planejamento, que definirá custo e tempo de desenvolvimento; Análise de Risco, gerenciamento e recuperação de riscos; Engenharia, que á construção da representação da aplicação; Construção e Liberação, onde acontecem a implementação, testes, instalação e suporte da aplicação, e Avaliação pelo Cliente, quando se tem o feedback quanto ao incremento desenvolvi- do [PRESSMAN 02]. Uma forte característica desse modelo, que o difere de outros modelos e o torna bastante utilizado pelas empresas, é o fato de acompanhar toda a vida do software, mesmo depois da entrega ao cliente, pois é na manutenção que muitas empresas desenvolvedoras têm o principal foco de atuação. Este modelo é o considerado mais realístico possível, pois assume que usuários, analistas e desenvolvedores adquirem maior conhecimento sobre o projeto com o decorrer do tempo [SOMMERVILLE 00].

3.4 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAIS OU “PESADAS Metodologia de Desenvolvimento é um conjunto de práticas recomendadas para o Desenvolvimento de Softwares, sendo que essas práticas, geralmente, passam por fases ou passos, que são subdivisões do processo para ordená-lo e melhor gerenciá-lo [SOMMERVILLE 00]. As metodologias consideradas tradicionais, também chamadas de “pesadas”, têm como característica marcante serem divididas em etapas e/ou fases. Essas fases são muito bem definidas e englobam atividades como Análise, Modelagem, Desenvolvimento e Testes. Cada fase concluída gera um marco, que geralmente é algum documento, protótipo do software ou mesmo uma versão do sistema. Esses marcos, dependendo do final de que etapa foram criados, podem ser documentos, como Diagramas de UML (Unified Modeling Language – é a linguagem padronizada de modelagem de sistemas orientados a objetos para visualização, construção, especificação e documentação do sistema), ou algum protótipo do software. Muitas “metodologias” pesadas são desenvolvidas no modelo em cascata o que dificulta o controle do projeto, pois a cada alteração em determinado ponto do projeto, como os requisitos, será necessário uma volta ao início do mesmo para alteração de documentação ou outro marco [PRESSMAN 02]. O foco principal das metodologias tradicionais é a previsibilidade dos requisitos do sistema, que traz a grande vantagem de tornar os projetos completamente planejados, facilitando a gerência do mesmo, mantendo sempre uma linha, caracterizando o processo como bastante rigoroso [OLIVEIRA 04]. 3.4.1 RUP – Rational Unified Process Para melhor analisarmos as características das metodologias pesadas, veremos o principal framework utilizado comercialmente no mercado, o RUP. O maior expoente das metodologias “pesadas” é o RUP, um Processo de Engenharia de Software criado pela Rational Software Corporation e oriundo do Processo Unificado – UP – para descrever como desenvolver um software usando

técnicas comerciais com o objetivo de aumentar a qualidade dos softwares gerados pela empresa desenvolvedora. O RUP é aplicável em classes de projetos variadas, sendo considerado um framework genérico para os processos de desenvolvimento, a contar que este deve ser configurado de acordo com o tamanho e a necessidade de cada projeto e/ou empresa desenvolvedora. O RUP é uma metodologia iterativa, ou seja, trabalha em ciclos de desenvolvimento. Isso provê vários benefícios como [KRUCHTEN 00]:

Gerenciamento de Requisitos: após do começo do desenvolvimento, é comum que os requisitos mudem, fazendo com que haja alterações na documentação. Desenvolvendo iterativamente, essas alterações são facilmente gerenciáveis;

Integração dos Elementos: quando cada módulo é desenvolvido este é integrado ao sistema como um todo, evitando que este seja um problema no final do projeto;

Gerenciamento de Riscos: a cada iteração é possível analisar pontos críticos e planejar estratégias para não se perder tempo durante o desenvolvimento;

Testes: os testes são realizados ao final de cada módulo, permitindo que erros e não-conformidades possam ser tratados ainda dentro do mesmo ciclo.

3.5 METODOLOGIAS DE DESENVOLVIMENTO ÁGEIS OU LEVES No começo de 2001, motivados pela observação de times de desenvolvimentos, perdidos entre os processos que existiam na época, alguns experts da indústria do desenvolvimento de softwares se uniram para encontrar valores e princípios relacionados ao desenvolvimento, que seriam capazes de fazer com que os times, também chamados de equipes, de desenvolvimento pudessem responder mais rápidos às mudanças nas especificações e que o projeto fosse desenvolvido mais rapidamente. Depois de algum tempo de pesquisa, esses experts escreveram um manifesto, que ficou conhecido como Manifesto for Agile Software Development [FOWLER 01]. Esse manifesto destacava 4 (quatro) valores. São eles:

• • • •

Indivíduos e iterações ao invés de processos e ferramentas; Software funcional ao invés de documentação detalhada; Colaboração do Cliente ao invés de negociação de contratos; Responder às mudanças ao invés de seguir um plano. Analisando individualmente cada um desses 4 (quatro) valores; as

seções a seguir explicam sucintamente suas definições [BECK 99], [WELLS 04] e [XISPE 04].  Indivíduos e iterações ao invés de processos e ferramentas É certo que a qualidade dos profissionais envolvidos no desenvolvimento do projeto afeta diretamente a qualidade do produto e o bom desempenho da equipe no projeto. Ter excelentes profissionais, no entanto, não é certeza de sucesso, pois estes dependem diretamente do processo. Um mau processo pode fazer com que os melhores desenvolvedores não sejam capazes de usar de todo o seu talento. Além da mistura certa do processo adequado com bons profissionais, é preciso que todo o grupo possa interagir perfeitamente entre si. Comunicação é mais importante do que simples talento para programação. Um desenvolvedor médio com bom relacionamento é bem melhor, trabalhando em equipe, é mais produtivo que um excelente programador trabalhando sozinho. É importante levar em consideração que, as ferramentas utilizadas são importantes para o sucesso final do projeto, porém elas não podem ter mais importância que seus utilizadores. Mais importante que o meio onde se vai trabalhar é a qualidade e o grau de interação da equipe.  Software funcional ao invés de documentação detalhada A documentação de um projeto é extremamente necessária para o sucesso do projeto, já que o código não é o melhor meio de comunicação entre o racional e a estrutura do sistema. A documentação legível para descrever o sistema ainda se faz necessária na tomada de decisões do projeto. É preciso tomar muito cuidado com a documentação, pois em excesso é pior do que a falta dela. De nada adianta uma extensa gama de documentos que

demoram muito tempo para serem gerados, se eles não estão em sincronia com o que está sendo desenvolvido e o que foi especificado. Documentos sem essa

sincronia desvirtuam a realidade do projeto, fazendo com que decisões
erradas possam ser tomadas. O que é sugerido pelo Manifesto é que somente a documentação necessária seja gerada, e esta esteja sempre sincronizada com o sistema. Para evitar erros quais documentos devem ser gerados, é levada em conta a seguinte prerrogativa: “Nenhum documento é gerado a não ser que seja necessário e significante.” O fato de só existir a documentação necessária ajuda na integração da equipe, pois a transferência de conhecimento sobre o projeto é feita trabalhando lado a lado, utilizando-se do código, sendo que este não permite duplas interpretações da funcionalidade e do que o sistema faz, e de alguns dos membros da equipe ajudando quando necessário.
 Colaboração do Cliente ao invés de negociação de contratos

A venda de um software é muito diferente de um produto qualquer. Não se consegue um bom software escrevendo suas necessidades num papel e entregando à empresa que vai desenvolver, esperando que tudo esteja como foi solicitado no final do prazo estipulado. Projetos tratados desta maneira são falhos, gerando um produto final de pouca qualidade. As metodologias ágeis, assumem que para um projeto obter sucesso e aceitação, gerando um produto de boa qualidade, é preciso que exista sempre um feed back do cliente para garantir que o software esteja sendo desenvolvido de maneira que atenda as necessidades. Contratos que determinam requisitos, prazos e custo de um projeto são, fundamentalmente, falhos. Isso porque no decorrer do desenvolvimento alguns requisitos passam a se tornarem dispensáveis enquanto surge a necessidade de se adicionar outros não previstos em contrato ou especificação. Portanto, o melhor contrato é aquele que determinará como será a comunicação e o relacionamento do cliente com a equipe desenvolvedora.

 Responder às mudanças ao invés de seguir um plano Assumindo que mudanças de especificação sempre vão ocorrer em todos os projetos, é possível afirmar, que melhor será o projeto que mais se adaptar a estas mudanças. A flexibilidade é fator fundamental para o sucesso do projeto, ela determina o quão adaptável o projeto é. Planos devem, sim, ser traçados, porém, como não é possível prever o futuro, as visões desses planos não podem ir muito longe. Muito deve ser planejado para poucas semanas, pouco se planeja para o próximo mês e quase nada se planeja para próximos anos, pois com as alterações que invariavelmente irão aparecer, muito difícil será seguir a risca estes planos mais longos. Os valores citados como fundamentais dentro do Manifesto inspiraram 12 (doze) princípios básicos, que são características que diferenciam as Metodologias Ágeis de outras Metodologias chamadas tradicionais. Esses princípios serão discutidos a seguir [FOWLER 01], [BECK 99]: A maior prioridade é satisfazer o cliente, lançando versões em pouco tempo e continuamente. Como a principal prioridade é por um produto final de qualidade, foram feitas pesquisas para definir quais as características durante a fase de desenvolvimento, que foram comuns nos processos que obtiveram sucesso. O resultado desta pesquisa revelou que o quanto antes se entregasse uma versão, mesmo que com poucas funcionalidades, do sistema, melhor seria a qualidade final, pois o sistema começaria a evoluir mais cedo. Sendo que essas versões deveriam ser atualizadas e entregues num período curto de tempo. Um processo ágil é aquele que entrega cedo é constantemente. Tenta-se entregar o primeiro sistema já com algumas funcionalidades desenvolvidas e funcionais em algumas semanas do início do projeto, sendo que novos pacotes de funcionalidades continuam sendo desenvolvidos e integrados ao módulo anterior, no decorrer de algumas semanas. Isso deve ocorrer constantemente.

É de opção do cliente, escolher se vai implantar o sistema ainda não todo completo ou vai apenas testa-lo para definir novas funcionalidades ou encontrar não- conformidades com aquilo que é necessário. b) Mudanças dos requisitos são bem-vindas, mesmo tarde durante o desenvolvimento. Processos Ágeis mudam para a vantagem do cliente. Indica atitude. Os participantes dos Processos Ágeis não temem mudanças, pois assumem que as mudanças são indicadores de que o time está aprendendo sobre o sistema, possibilitando saber se vai satisfazer o mercado. c) Entregar software funcional frequentemente, de duas semanas a dois meses. Quanto mais rápido melhor. A idéia é entregar softwares funcionais regularmente em um curto período de tempo. Documentações e papéis não contam como entregas, pois não satisfazem à necessidade atual do cliente. d) Pessoas de Negócios e Desenvolvedores devem trabalhar em conjunto. Um processo ágil precisa ser guiado constantemente, portanto é necessária a interação freqüente de Clientes, Desenvolvedores e Partes Interessadas, pois todos fazem parte do time. e) A equipe deve estar motivada para o sucesso de um projeto. Os indivíduos são parte fundamental do processo, como citados nos 4 (quatro) valores das Metodologias Ágeis, portanto é fundamental para o sucesso do projeto que tos estejam motivados, seja com o apoio de outros membros da equipe ou material e equipamento. Indivíduos motivados trabalham melhor. f) A maneira mais rápida de se obter informações é conversando. Conversação e Comunicação são valores básicos dos Processos Ágeis. Documentos e papéis são supérfluos, apenas escritos quando extremamente necessitados e significantes. A maneira padrão de troca de informações é a conversação. g) O progresso do projeto é medido pela quantidade de software funcional que existe.

30% do projeto estão concluídos, quando 30% das funcionalidades necessárias estiverem funcionando. O volume de documentos e qual fase do processo se está não determinam o progresso atual do projeto. h) Processos Ágeis promovem o desenvolvimento sustentável. A velocidade do desenvolvimento nos Processos Ágeis deve ser sempre constante. De nada adianta começar um projeto desenvolvendo de maneira rápida e essa velocidade não ser mantida, pois isso irá iludir o cliente, causando a ele uma impressão de falsa velocidade. Desenvolver em velocidades diferentes cansa mais os

desenvolvedores, fazendo-os ficarem estressados isso diminui a qualidade final do produto, quebrando um dos principais valores dos Processos Ágeis. i) Atenção contínua a excelência técnica e boa modelagem aumentam a agilidade. Alta qualidade é a chave para a agilidade. Para manter rápido o desenvolvimento é necessário deixar o software o mais limpo e o mais robusto possível. Isso porque os times de Processos Ágeis estão compromissados em desenvolver códigos da melhor qualidade. j) Simplicidade é essencial. O caminho a ser escolhido para desenvolver e projetar é sempre o caminho mais simples e consistente que leve ao resultado final esperado. A escolha do caminho mais simples implica em dizer que caso alguma mudança ocorra – e elas vão ocorrer – será mais fácil alterar o que já foi feito. k) As melhores Arquiteturas, Requisitos e Projetos vêm de equipes organizadas. Decisões são tomadas por toda a equipe e não por apenas um indivíduo. Isso caracteriza uma equipe organizada, pois todos trabalham juntos para o sucesso do projeto. Responsabilidades são compartilhadas pro todos os membros da equipe, mostrando que todos estão envolvidos no processo de um projeto. l) Em intervalos regulares a equipe debate como ela pode ser melhorada e ajustada para melhores resultados. Para uma equipe ágil melhorar é uma constante máxima. Sempre são feitas reuniões com a equipe a fim de encontrar novos pontos onde o time pode

ser melhorado para satisfazer as necessidades atuais do meio, que está em constante mudança. O meio está sempre mudando e para e equipe continuar ágil é necessário que ela mude de acordo. A seguir serão analisadas algumas características das principais metodologias ágeis encontrada na literatura especializada. 3.5.1 Extreme Programming – XP
• •

XP é uma abordagem deliberada e disciplinada para desenvolvimento de software. Criada por kent baeck em 1996 durante o projeto daimler-chrysler. O sucesso de xp advém da intensa satisfação do cliente. Cliente

satisfeito é o melhor indicativo de sucesso de um projeto esta metodologia foi criada para produzir o software que o cliente precisa quando ele é necessário. XP encoraja os desenvolvedores a atender as requisições de mudanças dos requisitos do software, no momento em isto acontece. Em XP alguns princípios traduzem o espírito da metodologia e devem serem rigorosamente seguidos e planejados. • Simplicidade • comunicação • feedback • coragem Simplicidade • Tentar sempre desenvolver a solução mais simples possível.
• • • • •

Muitos projetos perdem muito tempo quando os desenvolvedores destinam muito tempo desenvolvendo uma solução genérica. A solução deve responder simplesmente um requisito do usuário. Algumas funcionalidades podem nunca vir a serem utilizadas. Canal aberto de comunicação entre a equipe de desenvolvimento e com os usuários. A comunicação é chave para o sucesso.

Comunicação

Feedback

• • •

Feedback possibilita que o software evolva “Pergunte ao software, não a um documento” Feedback precisa ser:

Cedo (pra gente descobrir logo se está fazendo a coisa correta) Concreto (feedback oriundo do código) Constante (o ciclo de desenvolvimento tem que ser curto) Coragem
• • • • • • •

Colocar o cliente a par do que ta acontecendo Acreditar na capacidade de responder a mudanças Aprender com os erros Acreditar no feedback (não na “teoria”) Jogar pra ganhar (não pra ter uma desculpa) Fazer o que precisa ser feito Jogar fora código ruim O projeto é inciado em xp com o levantamento das "estórias dos

usuários". Cada estória é escrita pelo usuário e consiste de um ou alguns parágrafos de um o propósito da estória não é definir toda a funcionalidade de um cenário, mas sim, estimar como será a complexidade de parte do sistema em quanto tempo isso será desenvolvido. Todos os demais detalhes da estória serão esclarecidos com o cliente, imediatamente ao início do desenvolvimento. O próximo passo é o planejamento do release, onde será definido quais estórias deverão ser desenvolvidas em quais releases. Cada release consiste de um número de iterações. Cada iteração terá um conjunto de estórias implementadas. Em cada iteração,: Planeje, para que você sempre faça a coisa mais importante ainda a fazer Codifique, senão o software não sai Teste, senão você não sabe se está funcionando Refatore, senão o código vai ficar tão ruim que será impossível dar manutenção Escute, para que você saiba qual é o problema a resolver o refatoramento e os testes automáticos são atividades fundamentais em xp. Refatoramento

• • •

Refatorar é melhorar o código sem alterar sua funcionalidade Antes de uma mudança, você refatora o código para que a mudança seja simples de fazer Refatoração continua possibilita manter um design legal, mesmo com mudanças freqüentes

Testes automáticos
• • • • • •      

Testes automáticos são parte do software Se você tem somente a funcionalidade, seu software está incompleto Testes permitem que você refatore sem medo de quebrar o código Testes representam uma “redundância lógica” que você adiciona ao código Escrevendo testes antes da funcionalidade, Você clareia dúvidas sobre o que o software deve fazer, algumas práticas importantes em XP: Projeto mais simples possível Programação em pares Propriedade coletiva do código Cliente sempre disponível Estórias do usuário Planejamento do release

Projeto mais simples possível Projetos flexíveis são uma defesa contra mudanças imprevistas no software porém, também têm custos, tempo para desenvolvimento e manutenção, o código fica mais complexo, muitas vezes a flexibilidade não é utilizada nunca. Como mudança é barata em XP, vamos manter o projeto mais simples possível, modificando-o quando for necessário, suportar mais funcionalidade, o melhor projeto é aquele que:
• Roda todos os testes • Não contém duplicação de funcionalidade • Deixa claro as decisões de design importantes • Ter o menor número possível de classes e métodos • O melhor projeto não é aquele: mais flexível (com mais “ganchos”), mais

abstrato, que resistirá ao tempo Programação em pares

Se a revisão de código é legal, vamos fazê-la o tempo todo

• • • •

Em XP, programação é feita em pares, pares mudam com relativa rapidez (em dias) Programação em pares favorece comunicação e aprendizado Mas, você precisa estabelecer um padrão de codificação Há casos de redução no tempo de desenvolvimento com programação em pares

Propriedade coletiva do código
• • • • •

Desenvolvimento com objetos leva a alterações por todo o código Coordenar alterações toma tempo e gera resistências no “dono” do código Em XP, "não se coordena", simplesmente faz-se o que precisa ser feito, mas integra-se freqüentemente, no máximo, uma vez por dia Todos são responsáveis por todo o código Qualquer um que vê uma oportunidade de adicionar valor ao código, devo fazê-lo mantendo em vista as prioridades do cliente, mantendo o design mais simples possível

Testes protegem a funcionalidade padrão de codificação evita a “guerra dos

parênteses” Cliente sempre disponível

Um cliente (usuário da aplicação) deve trabalhar com o time para esclarecer dúvidas e estabelecer pequenas prioridades, é muito caro colocar um cliente a disposição do desenvolvimento?

Talvez então não valha a pena fazer o sistema...

Estórias do usuário
• • •

Usuários escrevem estórias descrevendo a funcionalidade que querem desenvolvedores estimam o tempo necessário para implementar cada estória Um release é um conjunto de estórias que são disponibilizados simultaneamente As estórias mais importantes e/ou mais difíceis tem prioridade

Planejamento do release
• • • • •

XP preconiza releases pequenos e freqüentes (a cada 2-3 meses) As quatro dimensões do desenvolvimento de software são custo, tempo, qualidade e escopo XP tenta manter escopo como variável livre Releases são divididas em iterações de 2-3 semanas O cliente decide: os programadores decidem, escopo, prioridade, composição do release, data do release, estimativas, conseqüências, processo, planejamento intra release (o mais arriscado primeiro)

• • • • • • • • •

Uma iteração alcança algum objetivo (tipicamente a adição de nova funcionalidade) Nada é feito que não seja imediatamente útil e necessário para não impactar os prazos de desenvolvimento problemas em XP Considerar testes como parte normal do processo de desenvolvimento Sempre fazer a coisa mais simples Admitir que você não sabe Colaborar Vencer resistência nas pessoas Times grandes Situações em que você não pode mudar livremente o código

3.5.2 Feature driven development – FDD Feature driven development é uma metodologia ágil criada por Jeff de Luca e Peter Code. foi reconhecida em 1997. FDD possui requisitos mais formais e mais passos que XP, além de possuir um mecanismo mais preciso para acompanhamento do projeto. O desenvolvimento baseado em FDD consiste de dois estágios principais:
• •

Descobrir uma lista de "features" a serem Implementação baseada em "features". Descobrir a lista de "features" é sem dúvida o processo mais crítico.

é a chave para o sucesso do projeto!

A qualidade com a qual se identifica a lista de "features" define quão preciso o projeto será controlado, quão extensível e manutenibilidade o código terá. Requer participação integral do cliente junto à equipe de desenvolvimento. Como a identificação da lista de "features" deriva-se um diagrama de classes de análise. As responsabilidades das classes devem expressar um linguajar comum entre desenvolvedores e usuários. Por exemplo: imaginem um sistema de compras on-line onde o cliente loga no sistema para comprar algo. O diagrama de classes deve conter classes como: carrinho de compras, cliente e item. O resultado da lista de "features" deve incluir:
• • • •

Criar um novo carrinho de compras para o cliente; Adicionar um novo item no carrinho de compras; Listar todos itens do carrinho de compras; Calcular o preço total dos itens do carrinho de compras. A lista de "features" deve representar algo para o usuário, refletindo

diretamente a funcionalidade que será disponibilizada na aplicação, também deve conter unidades de trabalho para os desenvolvedores, onde toda "feature" é pequena o suficiente para que o seu desenvolvimento seja feito em pequenas iterações. A implementação começa através do agrupamento de um conjunto de "features" relacionadas em um pacote de trabalho. Um pacote de trabalho deve ser completamente desenvolvido em uma iteração, normalmente de 1 a 3 semanas, desenvolvido deve apresentar uma parte do software onde o usuário pode utilizá-lo. Cada iteração inclui: Kick-off meeting para um pacote detrabalho: detalhes das "features" incluídas devem ser esclarecidos. • Projeto: classes/métodos e documentação necessárias são criadas. • Revisão de projeto: um projetista experiente avalia o projeto feito, analisandoo ou rejeitando-o. • Desenvolvimento: implementação e testes de unidade são criados. • Revisão de código: é uma espécie de programação em pares. • Fechamento do release: as "features" desenvolvidas são liberadas em um build. O FDD possui 5 principais processos: 3.5.2.1 SCRUM

Scrum é um processo para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita freqüência. O objetivo do scrum é fornecer um processo conveniente para projetos e desenvolvimento orientado a objetos. A metodologia é baseada em princípios semelhantes aos de XP: equipes pequenas, requisitos pouco estáveis ou desconhecidos, e iterações curtas para promover visibilidade para o desenvolvimento. Scrum divide o desenvolvimento em sprints de 30 dias. equipes pequenas, de até 7 pessoas, são formadas por projetistas, programadores, engenheiros e gerentes de qualidade. As equipes trabalham em cima de funcionalidade (os requisitos, em outras palavras) definidas no início de cada sprint. A equipe toda é responsável pelo desenvolvimento desta funcionalidade.Todo dia, é feita uma reunião de 15 minutos onde o time expões à gerência o que será feito no próximo dia, e nestas reuniões os gerentes podem levantar os fatores de impedimento, e o progresso geral do desenvolvimento. Todos respondem às perguntas:
• • •

O que você realizou desde a última reunião? Quais problemas você enfrentou? Em que você trabalhará até a próxima reunião?

Algumas conclusões sobre xp, fdd e scrum As três são metodologias que utilizam o modelo iterativo para evitar os principais "gargalos" do modelo em cascata; as três são metodologias ágeis, mas o XP é considerado muito mais "leve" porque não produz muitos artefatos; XP é melhor para projetos que possuem mudanças frequentes ou "pobre" levantamento de requisitos. A escalabilidade do FDD é melhor. existe uma hierarquia de processos que permite iterações tanto com equipes pequenas quanto grandes, FDD oferece um melhor acompanhamento gerencial do projeto. As três necessitam de disciplina, o que não exclui a necessidade de um bom gerente de projetos.

Scrum fornece um mecanismo de informação de status que é atualizado continuamente. Scrum e XP são complementares, pois Scrum provê práticas ágeis de gerenciamento enquanto XP está mais preocupado com a produção de código. As três oferecem técnicas bastante úteis e que podem ser aplicadas em outras metodologias. Algumas outras metodologias ágeis:
• • •

Crystal/clear Dynamic systems development method (dsdm) Adaptive software development (asd)

Conclusão

O desafio futuro das metodologias ágeis é encontrar maneiras de eliminar alguns de seus pontos fracos, como a falta de análise de riscos, sem tornálas metodologias pesadas. Na XP não existe a preocupação formal em fazer a análise e o planejamento de riscos. Como riscos acontecem normalmente em projetos de desenvolvimento de software, este é um ponto negativo da XP. Deve-se, portanto, procurar implementar uma estratégia de gestão de riscos sem tornar a metodologia muito complexa. Outro desafio é como usar essas metodologias ágeis em grandes empresas e equipes, uma vez que normalmente essas metodologias são baseadas em equipes pequenas. Neste caso, pelo menos é necessário resolver os problemas de comunicação internos na equipe, uma vez que é comum em grandes empresas os funcionários estarem separados geograficamente. Apesar do interesse crescente no uso das metodologias ágeis, ainda faltam casos de sucesso de seu uso em projetos grandes e críticos. Quanto mais organizações usem as metodologias ágeis, melhores serão os resultados empíricos em termos de vantagens, desvantagens, riscos e procedimentos para sua adoção nas organizações. Mesmo assim, os resultados iniciais em termos de qualidade, confiança, datas de entrega e custo são promissores. Como a Web é um ambiente de desenvolvimento dinâmico e com mudanças constantes, as metodologias tradicionais orientadas a documentação são menos adequadas que as metodologias ágeis. Uma idéia a ser implantada futuramente neste projeto de pesquisa é a integração da XP com outras metodologias ágeis, como a Scrum. Neste caso, os aspectos de planejamento e gerenciamento de projeto da Scrum serão integrados com as práticas da XP.

REFERENCIAS:

- PRESSMAN, ROGER S., Engenharia de Software- (6 Edição), São Paulo, Ed.

McGrawhill, 2006. - pt.wikipedia.org/.../Desenvolvimento_ágil_de_software – Acesso em 18/10/2010 - SOMMERVILLE, IAN., - PERINI, LUIS CLAUDIO - HISATOMI, MARCO IKURO – BERTO, WAGNER LUIZ. Engenharia de Software - Livros didáticos - Unopar Virtual. - improveit.com.br/xp/manifesto_agil – Acesso em 15/10/2010
- www.cci.unama.br/margalho/portaltcc/.../oscar.PDF