Palestrante: Antonio Miguel Batista Dourado

antoniodourado@gmail.com
@antoniodourado

Representao simplificada do processo.

Conjunto de prticas recomendadas para o
desenvolvimento de software.

Auxiliar no desenvolvimento de software.

Metodologias Tradicionais e Metodologias
geis.


Tambm conhecidas como orientadas
documentao.
Dividem o processo em etapas bem
definidas e fechadas.
Muito utilizada no passado para
desenvolvimento em mainframes devido
ao alto custo de alteraes, resultantes do
limitado acesso aos computadores e da
falta de tecnologia para depurao e
analise de cdigo. (SOARES, 2004)
Um exemplo de metodologia tradicional o
modelo em Cascata:

Problemas:
Diviso distinta de fases no projeto gera inflexibilidade uma
vez que raramente os projetos seguem um fluxo sequencial.

Requisitos totalmente especificados e congelados na
primeira fase do projeto dificultam futuras mudanas.

Arquitetura especificada e congelada na segunda fase do
projeto torna a arquitetura pouco confivel diante de
possveis mudanas de requisitos.

Grande dificuldade de alteraes no projeto depois de
decises j tomadas.
Metodologias Tradicionais so
aconselhveis quando h uma
previsibilidade dos requisitos do sistema
fazendo com que o projeto seja totalmente
planejado e sua gerncia seja facilitada.
Porm estas metodologias so repletas de
burocracias e tem sua eficincia em
projetos grandes que no sofram muitas
alteraes sobre seus requisitos
(FAGUNDES, 2005).

Surgiram na dcada de 90 propondo nova
abordagem de desenvolvimento com
adaptao mudanas e apoio equipe de
desenvolvimento.

Reao s metodologias tradicionais com o
intuito de criao de alternativa ao modelo
Cascata.
Em 2001, 17 especialistas criaram a
Aliana gil e atravs do Manifesto gil,
popularizou-se o termo Metodologia
gil.

O Manifesto gil busca constantemente
melhorias no desenvolvimento gil e
valorizam quatro principais principios.


Indivduos e interaes acima de procedimentos e
ferramentas

Software funcionando acima de documentao
abrangente

Colaborao dos clientes acima de negociao de
contratos

Responder mudanas acima de um plano pr-
estabelecido
O Manifesto gil no contra os modelos
utilizados pela metodologia tradicional
porm no segue os padres propostos
pela mesma.
No rejeita ferramentas, processos,
documentao, contratos ou
planejamentos mas prioriza indivduos e
iteraes, a executabilidade do software,
colaborao e feedbacks.
Em resumo, metodologias geis so
comumente aplicados a pequenos projetos
e/ou projetos com baixa complexidade
utilizando ciclos iterativos, tolerncia
mudana, proximidade da equipe, entre
outros.
Exemplos de metodologias geis:
-XP
-Scrum
-OpenUP/Basic

Pequenas equipes (entre trs e dez
pessoas) no comportam a utilizao de
processos pesados como o RUP e/ou no
utilizam todos os recursos oferecidos por
processos de desenvolvimento como o XP.

Um mesmo individuo pode ter vrios
papis diferentes (RUP).


Processo Unificado Aberto (Open Unified
Process).

Originalmente chamado de BUP (Basic
Unified Process) pela IBM que em 2005 foi
liberado para a Fundao Eclipse e
renomeado para OpenUP em 2006.

parte do EPF (Eclipse Process
Framework).
Aplica uma abordagem iterativa e
incremental em um ciclo de vida
estruturado, focando na natureza
colaborativa do processo de
desenvolvimento de software.

Conjunto compacto de atores, tarefas e
artefatos em relao ao RUP.
O OpenUP pode ser definido como:

Compacto Utiliza apenas contedos
fundamentais e definidos.

Completo Abrange todas as fases do ciclo de
vida do desenvolvimento de um software.

Extensvel Pode-se utiliz-lo da forma que foi
definido mas tambm possvel adicionar novos
contedos para atender novas caractersticas do
projeto.
O OpenUP regido por quatro princpios:

Equilibrar as prioridades concorrentes para maximizar o
benefcio aos Stakeholders

Colaborar para alinhar os interesses e compartilhar o
entendimento

Focar na arquitetura, o mais cedo possvel, para reduzir o
risco e organizar o desenvolvimento

Evoluir para continuamente obter feedback e promover
melhorias

preciso ter um conhecimento como um todo
sobre as necessidades dos stakeholders e dessa
forma, alinhar as prioridades que devem ser de
total acordo entre as partes. Alm disso, projetar
os cenrios, casos de uso e escopo do projeto so
itens importantes para a definio das prioridades.

Em uma equipe cada membro tem seus prprios
conhecimentos, habilidades e maneiras de fazer as
coisas. Este principio tem a finalidade de alinhar
essas diferenas de forma que o projeto seja
beneficiado bem como fazer com que todos os
membros da equipe tenham um entendimento
sobre o projeto. O continuo aprendizado tambm
estimulado por este principio fazendo com que
cada membro da equipe desenvolva mais
habilidades e incremente seus conhecimentos.

Uma arquitetura mal planejada muitas vezes
responsvel por grande parte dos problemas de um
sistema e at menos por complicaes tanto de
manuteno quanto do entendimento do mesmo
que podem at levar ao fracasso do sistema e
consequentemente do projeto.

O foco na arquitetura tem sua importncia dada uma vez
que os membros do projeto podem visualiz-la de formas
diferentes. Modelos de abstrao devem ser usados para
evitar este problema.
Alm disso, flexibilidade e reuso de recursos so pontos
importantes deste principio. O ideal projetar uma
arquitetura onde o acoplamento entre componentes seja
baixo, facilitando o reuso dos recursos fornecidos pelos
componentes.

O objetivo deste principio fazer com que atravs de
feedbacks, obtenha-se modos de melhorar o produto e
tambm o processo da equipe envolvida. Atravs de
feedbacks, pode-se identificar potenciais riscos e trat-
los mais cedo durante o projeto.
importante ter o objetivo do projeto de maneira clara
ao prprio entendimento para que seja possvel fazer
uma medio do progresso e identificar possveis
melhorias no processo.
Em um projeto de software diferentes pessoas so
envolvidas no processo e cada pessoa tem um
papel definido no projeto de acordo com seus
interesses e habilidades.
Os papis no tem significado de individualidade
sobre alguma tarefa ou artefato, mas sim uma
identificao de cada envolvido no projeto quando
existe o trabalho em conjunto. Alm disso, um
papel no limita uma tarefa a apenas um indivduo
quando na verdade uma tarefa pode conter vrios
indivduos adicionais e inclusive com outros
papis.

Os Stakeholders so os interessados no
resultado do projeto, ou seja, sero suas
necessidades que devero ser satisfeitas.

Geralmente os Stakeholders so pessoas
designadas pelo cliente para interagir com
a equipe do projeto.


O Gerente de Projeto (Project Manager) o
lder da equipe do projeto. este papel
que tem a responsabilidade de instruir a
equipe para conduz-la a um resultado
esperado.

O Architect (Arquiteto) o responsvel
pela definio da arquitetura de software
do projeto tomando decises que orientam
tanto equipe de design quanto equipe de
implementao.


O Analista (Analyst) o responsvel por
colher informaes dos stakeholders e
usurios finais e compreender o problema
proposto capturando os requisitos e
definindo prioridades para o mesmo.

O Desenvolvedor (Developer) o
responsvel por desenvolver o projeto com
base na sua adaptao arquitetura
proposta. Alm disso, o desenvolvedor
tambm responsvel pelos testes de
desenvolvedor.

O Tester (Testador) responsvel por toda
e qualquer atividade que envolvam testes
de software. O Tester deve criar casos de
testes, implement-los e execut-los.
Algum conhecimento de codificao
tambm pode ser detido por este papel.


O papel Any Role (Qualquer Papel)
representa qualquer membro da equipe
que possa realizar tarefas gerais como por
exemplo criar um caso de teste,
implementar cdigos no software, etc.
O OpenUP possui duas camadas internas
aos papis chamadas Camadas de
Contedo que tem a finalidade de indicar
quais papis devem interagir entre si a fim
de realizar algo.

Management (Gerncia)
Intent (Inteo)
Solution (Soluo)
Communication & Collaboration (Comunicao e
Colaborao)

A camada de Gesto trata do
gerenciamento do projeto, incluindo o
planejamento do projeto, planejamento da
iterao, gerenciamento dirio do trabalho
durante a iterao e a avaliao da
iterao.

Papis envolvidos: Stakeholder, Gerentes
de Projeto e Arquiteto.

A camada de inteno trata como canalizar
a inteno dos Stakeholders para o resto
da equipe de desenvolvimento, para
garantir que construes vlidas com
capacidades incrementais reflitam as
intenes dos Stakeholders.

Papis envolvidos: Stakeholder, Analista e
Testador.


A camada de Soluo descreve todos os
aspectos sobre a criao da arquitetura, o
design, a implementao e o teste da aplicao.

Papis envolvidos: Arquiteto, Desenvolvedor e
Testador.

A camada de comunicao e colaborao a parte
fundamental do OpenUP, refletindo a natureza
colaborativa do processo. Ela contm todos os
papis do OpenUP: Stakeholder, analista,
desenvolvedor, arquiteto, testador, gerente de
projeto e qualquer papel. Os membros da equipe
que se prontificam para estes papis necessitam
colaborar para, em conjunto, capturar e definir a
inteno dos Stakeholders, desenvolver a soluo
e gerenciar o projeto.

Uma tarefa corresponde a qualquer
unidade de trabalho que um papel possa
ser solicitado executar.

Exemplos:
-Definir um caso de uso.
-Construir o escopo do projeto.


Artefatos so todos e quaisquer resultados
de uma tarefa executada por algum.

Exemplos:
-Documento de caso de uso.
-Documento de escopo.

Uma disciplina uma coleo de tarefas que se
relacionam a uma "rea de interesse" maior em todo o
projeto. O agrupamento de tarefas em disciplinas serve
principalmente para ajudar a compreender o projeto
dentro de uma viso tradicional em cascata. Embora
seja comum executar simultaneamente tarefas que
pertenam a vrias disciplinas (por exemplo,
determinadas tarefas de requisitos so executadas sob
a mesma coordenao de tarefas de anlise e design),
separar estas tarefas em disciplinas distintas uma
forma eficaz de organizar o contedo, tornando mais
fcil a compreenso.
O OpenUP contm seis disciplinas:

Requisitos
Gesto de Projetos
Arquitetura
Desenvolvimento
Teste
Gesto de Configurao e Mudana

A disciplina de requisitos explica como
elicitar, analisar, especificar, validar e
gerenciar os requisitos para o sistema a ser
desenvolvido.

Tarefas da disciplina:
Definir viso
Encontrar e Descrever os Requisitos
Detalhar os Requisitos
A disciplina de gesto de projetos explica
como instruir, ajudar e suportar a equipe,
ajudando-a a lidar com os riscos e obstculos
encontrados quando da construo de
software.

Tarefas da disciplina:
Planejar o projeto
Planejar a Iterao
Gerenciar a Iterao
Avaliar os resultados
A disciplina de arquitetura explica como criar
uma arquitetura, a partir dos requisitos
arquiteturalmente significantes. A arquitetura
construda na disciplina de
Desenvolvimento.

Tarefas da disciplina:
Descrever a arquitetura
Refinar a arquitetura
A disciplina de desenvolvimento explica como
projetar e implementar uma soluo tcnica
que seja aderente arquitetura e atenda aos
requisitos.

Tarefas da discplina:
Projetar a soluo
Implementar a soluo
Implementar os testes de desenvolvedor
Executar os testes de desenvolvedor
A disciplina de teste explica como fornecer
feedback sobre a maturidade do sistema
atravs do design, implementao, execuo e
avaliao dos testes.

Tarefas da disciplina:
Criar os casos de teste
Implementar os scripts de teste
Executar os testes
A disciplina de gesto de configurao e
mudana explica como controlar as mudanas
nos artefatos, assegurando uma evoluo
sincronizada do conjunto de Produtos de
Trabalho que compem um sistema de
software.

Tarefas da disciplina:
Solicitar mudana
Integrar e criar a construo


O OpenUP de modo geral conta com trs
camadas que interagem entre si: Micro-
Incrementos, Ciclo de Vida de Iterao e
Ciclo de Vida do Projeto.
Os micro-incrementos so considerados
pequenos trabalhos que consomem pouco
tempo (horas ou dias) e que contribuem
para o crescimento da aplicao como um
todo.

Exemplos:
Projetar um caso de uso
Planejar uma iterao

Lista de Itens de Trabalho

Lista de todo trabalho agendado para ser feito dentro
do projeto, bem como o trabalho proposto que pode
afetar o produto neste ou em projetos futuros. Cada
Item de trabalho pode conter referncias a informaes
que sejam relevantes para realizar o trabalho descrito
no item. Cada item de trabalho corresponde um
micro-incremento.
Uma iterao um perodo de tempo
definido dentro de um projeto em que
voc produz uma verso estvel e
executvel do produto, junto com toda a
documentao de apoio, scripts de
instalao, artefatos e similares,
necessrios para usar a verso.
O ciclo comea em uma breve reunio de
planejamento de iterao, prazos e atividades.

As iteraes em sua maioria so compostas de
micro-incrementos mas tambm correes e
ajustes.

O ciclo termina em uma segunda reunio com
os stakeholders onde resultados e melhorias
so avaliados.

Plano de Iterao

Os principais objetivos do plano de iterao so
fornecer equipe um lugar central para informaes a
respeito dos objetivos da iterao, do plano detalhado
com as atribuies das tarefas e dos resultados das
avaliaes. Tambm ajuda a equipe a monitorar o
progresso da iterao e mantm os resultados da
avaliao da iterao, que podem ser teis para
melhorar a prxima iterao.

D uma viso geral do projeto a ser
desenvolvido bem como o que ser realizado,
como ser realizado e por quem ser
realizado.

Pode-se visualizar todas as partes do
desenvolvimento de um projeto atravs das
fases (Concepo, Elaborao, Construo e
Transio) do ciclo de vida de projeto.
Uma fase o tempo entre dois grandes marcos de
projeto, durante o qual um conjunto bem definido
de objetivos cumprido, e as decises so
tomadas para entrar ou no na prxima fase.

Cada fase tem um marco(milestone) ao seu final e
atravs deste, possvel entender o que foi
realizado na fase. Os marcos tem como finalidade
ser utilizado pelos stakeholders na forma de
superviso do projeto bem como tomadas de
decises sobre o mesmo.

Nesta fase, os stakeholders e os membros
da equipe colaboram para determinar o
escopo e os objetivos do projeto, e
determinar se o projeto deve continuar.

O marco da fase chamado Marco dos
Objetivos no Ciclo de Vida. analisado o
custo versus os benefcios, e decide-se
entre avanar ou cancelar o projeto.
Nesta fase, h o entendimento dos requisitos
atravs de um detalhamento, projetada e
implementada uma arquitetura executavel
(cenrios crticos, interfaces, etc.), riscos
essenciais so atenuados e produzido um
cronograma e uma estimativa de custo preciso.

Este marco chamado de Marco da Arquitetura
no Ciclo de Vida e alcanado uma vez que a
arquitetura for validada.

Esta fase foca o detalhamento dos
requisitos, no design, na implementao e
no teste da maior parte do software.

O marco desta fase chamado Marco da
Capacidade Operacional Inicial e
alcanado quando toda a funcionalidade foi
desenvolvida e testes alfa concluda.
Esta fase foca a transio do software para o
ambiente do cliente e na obteno da
concordncia dos Stakeholders de que o
desenvolvimento do produto est completo.

O marco desta fase chamado Marco de
Liberao do Produto e alcanado quando
os objetivos do projeto foram alcanados e
aceito pelos usurios/stakeholders

Plano de Projeto

Define os parmetros para o acompanhamento do
progresso do projeto e especifica os objetivos de alto
nvel das iteraes e seus marcos. Descreve tambm
como o projeto est organizado e quais papis so
executados por quem.
FAGUNDES, Priscila Bastos. Framework para Comparao e Anlise de Mtodos
geis. Dissertao de Mestrado. Universidade Federal de Santa Catarina.
Florianpolis: 2005.

SOARES, Michel dos Santos. Comparao entre Metodologias geis e Tradicionais
para o Desenvolvimento de Software. 2004. Disponvel em:
<http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf> . Acessado em: 09 out
2009.

FELIPPE, Ceclia Macha. Aplicao de Metodologia gil no Desenvolvimento de um
Componente de Software para Prefeituras. Trabalho de concluso de curso.
Universidade Federal de Santa Catarina. Florianpolis: 2007.

OPENUP. Apresenta a arquitetura do OpenUP. Disponvel em
<http://epf.eclipse.org/wikis/openup>. Acessado em: 09 out 2009.

EPF. Projeto EPF. Disponvel em <http://www.eclipse.org/epf/> . Acessado em 10
out 2009.






Antonio Miguel Batista Dourado
antoniodourado@gmail.com
@antoniodourado