Portifolio ENGSOFTWARE

44
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

Transcript of Portifolio ENGSOFTWARE

Page 1: Portifolio ENGSOFTWARE

CURSO SUPERIOR DE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

ROSANGELA CATHIA SILVA COSTAANTONIO DE PADUA LINO DANTASEDUARDOSERGIO DA SILVA ATHAN

GIL RAMISON SANTOS EVANGELISTA DE CASTROJONATHAS MARCELLO GUIMARAES DE SOUZA

WALLACE DIAS BEZERRA

ATIVIDADE DE PORTFÓLIOATIVIDADE DE PRODUÇÃO TEXTUAL

Juazeiro-BA2010

Page 2: Portifolio ENGSOFTWARE

ROSANGELA CATHIA SILVA COSTAANTONIO DE PADUA LINO DANTASEDUARDOSERGIO DA SILVA ATHAN

GIL RAMISON SANTOS EVANGELISTA DE CASTROJONATHAS MARCELLO GUIMARAES DE SOUZA

WALLACE DIAS BEZERRA

ATIVIDADE DE PORTFÓLIOATIVIDADE 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

Page 3: Portifolio ENGSOFTWARE

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

Page 4: Portifolio ENGSOFTWARE

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.

Page 5: Portifolio ENGSOFTWARE

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,

Page 6: Portifolio ENGSOFTWARE

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.

Page 7: Portifolio ENGSOFTWARE

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

Page 8: Portifolio ENGSOFTWARE

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

Page 9: Portifolio ENGSOFTWARE

É 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 requisitos-

chave 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

Page 10: Portifolio ENGSOFTWARE

É 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

Page 11: Portifolio ENGSOFTWARE

desenvolvimento utilizando as técnicas e métodos descritos acima.

[SOMMERVILLE]

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

Page 12: Portifolio ENGSOFTWARE

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.

Page 13: Portifolio ENGSOFTWARE

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, pois a reutilização de código permite que a equipe de

desenvolvimento possa desenvolver um sistema completamente funcional em pouco

tempo.

Igualmente aos outros modelos, o RAD é subdividido em fases, que

são:

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;

Page 14: Portifolio ENGSOFTWARE

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 é

Page 15: Portifolio ENGSOFTWARE

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].

Page 16: Portifolio ENGSOFTWARE

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

Page 17: Portifolio ENGSOFTWARE

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:

Page 18: Portifolio ENGSOFTWARE

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

Page 19: Portifolio ENGSOFTWARE

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.

Page 20: Portifolio ENGSOFTWARE

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.

Page 21: Portifolio ENGSOFTWARE

É 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.

Page 22: Portifolio ENGSOFTWARE

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

Page 23: Portifolio ENGSOFTWARE

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.

Comunicação

Canal aberto de comunicação entre a equipe de desenvolvimento e com os

usuários.

A comunicação é chave para o sucesso.

Feedback

Page 24: Portifolio ENGSOFTWARE

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

Page 25: Portifolio ENGSOFTWARE

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

Page 26: Portifolio ENGSOFTWARE

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

Page 27: Portifolio ENGSOFTWARE

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!

Page 28: Portifolio ENGSOFTWARE

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, analisando-

o 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

Page 29: Portifolio ENGSOFTWARE

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.

Page 30: Portifolio ENGSOFTWARE

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

Page 31: Portifolio ENGSOFTWARE

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:

Page 32: Portifolio ENGSOFTWARE

- 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