Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
Ana Marta Borgonovo
Roberta Santos da Silva
APLICAÇÃO DE METODOLOGIA
ÁGIL EM GRANDES EMPRESAS
COM PEQUENOS GRUPOS DE TI
Trabalho de Conclusão de Curso
Prof. João Candido Dovicchi, Dr.
Orientador
Florianópolis, 2007
Sumário
1Introdução........................................................................................................................7
1.1 Justificativa.............................................................................................................7 1.2 Objetivos.................................................................................................................8
1.2.1 Objetivo Geral................................................................................................ 8 1.2.2 Objetivos Específicos..................................................................................... 8
1.3 Metas...................................................................................................................... 8 1.4 Fundamentação Teórica..........................................................................................9 1.5 Problematização e Metodologia........................................................................... 10 1.6 Estrutura do Trabalho........................................................................................... 10
2Cenário.......................................................................................................................... 11
3Open Unified Process (OpenUP)...................................................................................12
3.1 Visão Geral........................................................................................................... 13 3.2 Princípios.............................................................................................................. 13
3.2.1 Colaboração.................................................................................................. 14 3.2.2 Equilíbrio...................................................................................................... 14 3.2.3 Foco.............................................................................................................. 15 3.2.4 Evolução....................................................................................................... 15
3.3 Sub-Processos.......................................................................................................16 3.3.1 Colaboração e Comunicação........................................................................ 17 3.3.2 Propósito.......................................................................................................17 3.3.3 Gerenciamento..............................................................................................17 3.3.4 Solução......................................................................................................... 18
3.4 Atores....................................................................................................................18 3.4.1 Analista.........................................................................................................18 3.4.2 Any Role.......................................................................................................19 3.4.3 Arquitetos..................................................................................................... 19 3.4.4 Desenvolvedor.............................................................................................. 20 3.4.5 Gerente de Projetos.......................................................................................21 3.4.6 Tester............................................................................................................ 21 3.4.7 Stakeholder................................................................................................... 22
3.5 As disciplinas do OpenUp/Basic.......................................................................... 22 3.5.1 Requisitos..................................................................................................... 22 3.5.2 Análise e Design...........................................................................................23 3.5.3 Implementação..............................................................................................23 3.5.4 Testes............................................................................................................ 24 3.5.5 Gestão de Projeto..........................................................................................24 3.5.6 Gestão de Configuração e Mudança.............................................................25
3.6 Ciclo de Vida do OpenUp/Basic.......................................................................... 25 3.6.1 Inception Phase Iteration.............................................................................. 26 3.6.2 Elaboration Phase Iteration...........................................................................28 3.6.3 Construcion Phase Iteration..........................................................................31 3.6.4 Transiction Phase Iteration........................................................................... 33
4Eclipse Process Framework...........................................................................................35
5EPF e OpenUP/Basic – Customização e Aplicação...................................................... 37
6Conclusão...................................................................................................................... 38
6.1 Sugestões para trabalhos futuros.............................................................................. 38
Referências Bibliográficas...............................................................................................39
Índice de Figuras
Ilustração 1: Sub-Processos do OpenUP/Basic............................................................... 16
Ilustração 2: Tarefas e Artefatos relacionados ao Analista............................................. 19
Ilustração 3: Tarefas e Artefatos relacionados ao Any Role........................................... 19
Ilustração 4: Tarefas e Artefatos relacionados ao Arquiteto........................................... 20
Ilustração 5: Tarefas e Artefatos relacionados ao Desenvolvedor.................................. 21
Ilustração 6: Tarefas e Artefatos relacionados ao Gerente de Projeto.............................21
Ilustração 7: Tarefas e Artefatos relacionados ao Tester.................................................22
Ilustração 8: Ciclo de Vida OpenUp/Basic.................................................................... 25
Ilustração 9: Inception Phase Iteration............................................................................ 26
Ilustração 10: Elaboration Phase Iteration.......................................................................28
Ilustração 11: Construcion Phase Iteration......................................................................31
Ilustração 12: Transiction Phase Iteration....................................................................... 33
Ilustração 13: Representação bi-dimensional da separação entre conteúdos do método e
o processo do Unified Process.........................................................................................36
Índice de Tabelas
Lista de Siglas
Resumo
Abstract
Capítulo 1
1 Introdução
Tendo em vista a evolução das grandes empresas e seus negócios nos últimos
anos, podemos perceber o quanto as pequenas e médias empresas estão estacionadas em
relação ao gerenciamento dos seus processos.
A grande dificuldade das empresas que já estão há mais tempo no mercado é a
de que provavelmente seus processos são/estão “engessados”.
A mudança é um risco que poucas estão dispostas a correr. Gerando então uma
insatisfação dentro da própria organização. Com isso, surgindo dois segmentos: um que
quer modernizar ou até criar processos e outro que prefere a “comodidade” e a
“segurança” da empresa, que já caminha dessa forma por toda a sua história.
Visando essas empresas, procuramos encontrar, nas metodologias existentes, a
melhor maneira de implantar gerenciamento de processos sem causar grandes abalos
nas convicções da organização.
1.1 Justificativa
Mostrar à empresa que mudanças são saudáveis, fazendo com que ela
mantenha-se no mercado de forma mais competitiva.
Em particular, as organizações pequenas e médias, não possuem recursos
suficientes para adotar o uso de processos pesados, ou mesmo não necessitam de tanto
formalismo. Por esta razão, muitas organizações não utilizam nenhum processo. O
resultado desta falta de sistematização na produção de software é a baixa qualidade do
produto final. Esse cenário pode ainda prejudicar prazos e custos predefinidos,
inviabilizando a futura evolução do software.
Existem vários processos de software definidos na literatura da Engenharia de
Software. É comum algumas organizações criarem seus próprios processos ou
adaptarem algum à sua realidade. Dentre as várias conhecidas, existem as metodologias
tradicionais e as ágeis: a primeira, orientada à documentação e a segunda, que procura
desenvolver software com o mínimo de formalismos.
1.2 Objetivos
1.2.1 Objetivo Geral
Apresentar uma metodologia, por meio do projeto Eclipse Process Framework
(EPF) e o processo de desenvolvimento Open Unified Process Basic (OpenUP/Basic).
Inserindo nesse contexto empresas novas, onde não há metodologias de
desenvolvimento, e empresas antigas, onde não se criou uma cultura de planejamento e
desenvolvimento organizado.
1.2.2 Objetivos Específicos
− Justificar a escolha do framework EPF e processo OpenUP/Basic.
− Demonstrar a importância do uso de uma metodologia, mesmo sendo um
processo de desenvolvimento enxuto.
− Mostrar às empresas que uma metodologia pode ajudá-las a crescer e a
colocar seus produtos em uma melhor posição no mercado.
− Criar uma cultura dentro da empresa, de que os métodos são para melhorar
os processos e qualificar seus produtos e/ou serviços.
1.3 Metas
Utilizar o projeto EPF e a ferramenta EPF Composer para demonstrar como a
modelagem de processos pode ser flexível. Para isso, serão apresentadas possibilidades
de customização do processo OpenUP/Basic às necessidades específicas de cada
empresa.
1.4 Fundamentação Teórica
O projeto EPF é um projeto open-source amparado pela fundação Eclipse,
sendo sua doação inicial feita pela IBM Rational no início do ano de 2006. Esse projeto
tem a intenção de tornar a engenharia de software mais acessível e promover um
desenvolvimento ágil e prático.
OpenUp/Basic é uma parte do processo Open Unified Process (OpenUP). É um
processo iterativo de desenvolvimento de software mínimo, completo e extensível [BAL
07]. Os princípios centrais do OpenUp/Basic são: colaboração, equilíbrio, evolução e
foco. Colaboração para alinhar os interesses dos envolvidos no processo e compartilhar
entendimentos. Equilíbrio para atender as prioridades dos stakeholders1 sem interferir
no bom andamento do projeto. Evolução para obter feedback e realizar melhorias. Foco
na importância de uma arquitetura de sistema bem definida.
Segundo Filev, os métodos pesados e lentos não mostraram muita utilidade no
atual mercado dinâmico dos negócios. Orçamentos apertados exigem mais resultados; a
burocracia nunca foi a melhor escolha em termos de retorno sobre investimento (ROI).
O poder dos métodos ágeis reside na colaboração, na flexibilidade e na dedicação ao
valor comercial do software, como refletido nos princípios fundamentais do Manifesto
Ágil: indivíduos e interações em processos e ferramentas, software funcional em
documentação abrangente, colaboração de clientes em negociação de contratos e
resposta a alterações no acompanhamento de um plano. Os métodos ágeis são
extremamente adequados à nova onda de empresas emergentes baseadas na Internet
(com freqüência chamadas de Web 2.0). O desenvolvimento de software ágil permite
que algumas dessas empresas emergentes obtenham mais por menos e iniciem projetos
significativos com pequenas equipes e orçamentos curtos. [FIL 07].
1 Parte interessada ou interveniente, refere-se a todos os envolvidos em um processo (clientes, colaboradores, investidores, fornecedores, entre outros).
1.5 Problematização e Metodologia
Buscamos uma metodologia que permita a constante evolução da empresa e
processos, sem deixar de lado a qualidade do produto.
As metodologias ágeis aplicam uma gama de boas práticas, guiadas por
princípios e valores que podem ser aplicados no dia a dia. Tiveram como principal
motivação criar alternativas para o modelo de desenvolvimento em cascata.
Devemos deixar claro que metodologia ágil é um suplemento de metodologias
existentes, é uma forma efetiva de se trabalhar em conjunto para atingir as necessidades
dos stakeholders no projeto. Não se trata de uma teoria acadêmica ou mesmo um ataque
à documentação. Ao contrário, aconselha a criação de documentos que realmente
tenham valor, torna o cliente parte da equipe de desenvolvimento e utiliza o modelo
incremental.
1.6 Estrutura do Trabalho
Este trabalho está organizado em seis capítulos, organizados da seguinte forma:
− Capítulo 2: apresenta um cenário onde o estudo proposto poderá ser
aplicado.
− Capítulo 3: apresenta uma visão geral do processo OpenUp/Basic. Serão
abordados os seus princípios, processos e subprocessos, atores, disciplinas
e atividades. O foco principal desse capítulo estará na disciplina de
Gerencia de Projetos.
− Capítulo 4: será apresentada a ferramenta EPF Composer, seus princípios
fundamentais e terminologia.
− Capítulo 5: com auxílio da ferramenta EPF Composer, serão apresentadas
possibilidades de customização do processo OpenUP/Basic ao cenário
apresentado.
− Capítulo 6: serão apresentadas as conclusões deste trabalho, considerações
finais e propostas de trabalhos futuros.
Capítulo 2
2 Cenário
Com o aumento no número de aplicações, se faz necessário a criação ou
adaptação de processos, que estejam aptos a enfrentar os problemas oriundos da
velocidade de mudanças, que ocorrem durante o desenvolvimento de um projeto e isso
envolve toda a estrutura da organização.
(...)
Desenvolvedores precisam entender os métodos e adquirir boas práticas de
trabalho. É necessário tornar bem difundidas práticas básicas: clareza na definição dos
requisitos, análise e design, implementação de casos de testes, gerenciamento e
modificação do escopo do projeto, entre outras [HAU 06].
Com essas boas práticas bem definidas, é necessário ainda, definir como elas
serão aplicadas durante o ciclo de vida do projeto. Com isso, começamos a entender o
que é um processo de desenvolvimento. Adquirir boas práticas de desenvolvimento,
saber onde aplicá-las durante o ciclo de vida do projeto, definir claramente os papéis e
tarefas de cada um, alcançar os objetivos dos stakeholders, entre outros aspectos [HAU
06].
Definindo um processo de desenvolvimento adequado é possível trazer à
equipe organização e objetivos claros a serem alcançados.
Capítulo 3
3 Open Unified Process (OpenUP)
O OpenUp foi desenvolvido pela IBM com base nos processos RUP e XP, tendo
como principal objetivo reunir as melhores características de cada uma dessas
metodologias. A estrutura do OpenUp é extremamente adaptável a cada projeto e
permite o desenvolvimento de extensões.
A duração média de um projeto é de três a seis meses e as equipes variam de três
a dez pessoas, com isso vemos que esse tipo de projeto não suporta uma metodologia
robusta como é o caso do RUP [JAC 99] e também utilizam todos os recursos
oferecidos pelo XP [BEC 99].
As equipes de pequeno porte devem manter o foco nas atividades do
desenvolvimento visando à entrega do produto no prazo requisitado pelos stakeholders.
“For companies and organizations evolving into on demand
businesses to compete in a world increasingly enabled by
multiple technologies and the disappearance of geopolitical
boundaries -- "flatteners," as Thomas Friedman terms these
enablers -- the creation, integration, modernization, extension,
and deployment of systems and software applications has
become critical. Today, information technology not only
supports the business but, in many organizations, actually
defines the business. We are witnessing the emergence of a new
computing paradigm, which IBM calls "business-driven
development"; BDD organizations fully integrate and align
flexible development processes with business process
development for different lines of businesses as well as IT
operations to improve business performance” 2.
3.1 Visão Geral
OpenUP é um projeto open-source que define um framework de processo de
desenvolvimento de software. O OpenUP/Basic é uma parte do OpenUP que apresenta
conceitos ágeis de desenvolvimento de software, definindo um conjunto fundamental e
simplificado de atores, tarefas e artefatos. Atores que irão executar tarefas e consumir
ou produzir artefatos.
Este processo de desenvolvimento de software é iterativo e pode ser definido
como:
− mínimo, apenas conteúdos fundamentais do processo são definidos;
− completo, o processo abrange todas as fases do ciclo de vida de
desenvolvimento;
− e extensível, o processo pode ser utilizado na forma como foi definido, mas
permite que novos conteúdos de processos sejam acrescentados para
atender de forma mais completa as características de um determinado
projeto [BAL 07].
3.2 Princípios
O OpenUp/Basic é caracterizado por quatro princípios fundamentais:
Colaboração, Equilíbrio, Foco e Evolução.
Esses princípios determinam as intenções gerais do OpenUP e criam os 2 Para as organizações envolvidas em negócios sob demanda, competir em um mundo repleto de
diferentes tecnologias e frente ao desaparecimento de fronteiras geopolíticas - “flatteners” segundo Thomas Friedman - a criação, integração, modernização, extensão e desenvolvimento de sistemas e aplicações de software, começam a ficar críticos. Hoje, a tecnologia da informação não somente provê suporte aos negócios como também, em muitas organizações, o define. Nós acreditamos na urgência de um novo paradigma de computação, que a IBM chama de “bissiness-driven-development”; organizações BDD interagem completamente e alinham processos de desenvolvimento flexíveis com processos de desenvolvimento de negócios, para diferentes linhas de negócios, bem como operações de TI, para melhorar o desempenho da organização. (HAUMER, 2005, tradução nossa).
fundamentos para a interpretação das regras, produtos e tarefas a serem cumpridas
pelos atores envolvidos no processo.
As próximas subseções detalham mais sobre cada um desses princípios.
3.2.1 Colaboração
Os envolvidos no projeto devem trabalhar em conjunto para que o produto final
esteja de acordo com as especificações iniciais. Os participantes devem manter o senso
comum em relação ao projeto, devem ter boa comunicação e serem encorajados à pró-
atividade.
O ambiente deve ser confiável e agradável, onde os colaboradores são incitados
a terem novas idéias e a compartilhá-las com a equipe. A manutenção desse ambiente é
de responsabilidade de todos.
As responsabilidades devem ser distribuídas a cada colaborador, mas todos
possuem responsabilidade sobre o andamento do projeto. Todos devem estar dispostos a
ajudar e serem ajudados nas suas atividades.
As pessoas têm habilidades diferentes e estas devem estar em constante
aprimoramento. É necessária trocas de experiências, pois isso influencia de maneira
positiva nas resoluções de problemas que possam surgir.
3.2.2 Equilíbrio
O equilíbrio no processo de desenvolvimento é atingido com o passar do
tempo. A equipe e os stakeholders irão aprender mais sobre o sistema que estão
desenvolvendo, e dessa forma, melhor balancear as prioridades.
As prioridades do projeto podem ser alteradas durante o processo de
desenvolvimento por vários motivos, entre eles, novas oportunidades, funcionalidades,
riscos.
Stakeholders e participantes do projeto devem convergir a um claro
entendimento e acordo do problema a ser resolvido. Pontos críticos do desenvolvimento
(custos, cronograma, etc.) e da solução devem ser bem definidos.
As equipes têm por desafio desenvolver soluções que maximizem as
experiências dos usuários. O equilíbrio está em escolher o melhor custo-benefício entre
os requisitos e as decisões de design na construção de arquitetura.
Algumas práticas podem ser usadas para atingir o melhor equilíbrio: conhecer
os stakeholders, separar o problema da solução, usar cenários e casos de uso para obter
requisitos, estabelecer e manter prioridades, gerenciar o escopo, etc.
3.2.3 Foco
Esse princípio tem como característica a importância de uma sólida definição
de arquitetura.
A arquitetura mal definida pode evoluir de forma ineficiente e autodestrutiva,
dificultando a evolução, reuso e integração com outros sistemas.
Uma arquitetura bem definida auxilia na comunicação dentro da equipe e
permite aos desenvolvedores elaborarem melhores decisões técnicas, garantindo assim
uma evolução eficiente do sistema.
As práticas associadas a esse princípio são: criar uma arquitetura baseada nos
conhecimentos da equipe; aumentar a abstração; adotar soluções baseado nos problemas
e não em tecnologias; aumentar a coesão; diminuir o acoplamento; incentivar o reuso,
etc.
3.2.4 Evolução
A equipe também evolui juntamente com o projeto. Encontrando melhores
maneiras de realizar as tarefas e buscando em conjunto, soluções para o dia-a-dia do
desenvolvimento.
Dentro desse princípio, a prática de desenvolvimento em iterações é uma
estratégia que permite retorno constante às necessidades do projeto e disponibiliza
funcionalidades aos stakeholders, aumentando a qualidade do produto.
Outra prática importante é o gerenciamento de riscos. Essa prática procura
evitar a descoberta tardia dos mesmos, dessa forma, problemas como: design de
arquitetura ruim, escolha errônea da tecnologia e implementação equivocada dos
requisitos, poderão ser contornados.
A gerência de alterações é também uma prática muito útil, pois são inevitáveis
mudanças durante o ciclo de vida do projeto. Alterações tardias afetam a qualidade do
produto e o esforço necessário para produzi-lo. Nesse ponto, a documentação é
essencial, para se verificar os possíveis impactos dentro do projeto.
3.3 Sub-Processos
OpenUP/Basic é organizado em quatro áreas de conteúdos ou sub-processos:
Ilustração 1: Sub-Processos do OpenUP/BasicFonte: OpenUp/Basic [OPE 07]
3.3.1 Colaboração e Comunicação
O sub-processo Colaboração e Comunicação é a fundação para o
OpenUp/Basic, refletindo a natureza colaborativa do processo. O processo contém todos
os papéis necessários ao projeto: Cliente, Analista, Colaborador, Arquiteto, Verificador,
Gerente de Projeto, entre outros[OPE 07]. Os membros da equipe fazem uma avaliação
da necessidade de cada papel e definem conjuntamente, as intenções dos stakeholders, o
desenvolvimento de soluções e o controle do projeto.
Os diferentes estilos e habilidades dos membros da equipe, fazem com que o
produto final esteja de acordo com as especificações iniciais. A criação de atividades
que mantenham o ambiente saudável se faz necessário, possibilitando assim o
entendimento do projeto, e o alinhamento das expectativas e interesses de todos os
participantes.
3.3.2 Propósito
Esse sub-processo trata da canalização dos propósitos dos stakeholders para a
equipe de desenvolvimento, assegurando-se que builds desenvolvidos sejam entregues
em conformidade com as expectativas dos mesmos. Isso é conseguido através da
comunicação do documento visão e de sua tradução por meio de casos de testes e
requisitos.
A maioria das tarefas e produtos de trabalho deste subprocesso, estão nas
disciplinas e domínios dos Requisitos e Testes
O Propósito tem como base a Colaboração e Comunicação. É escrito de forma
a possibilitar a organização modificá-lo de acordo com suas necessidades, sem impactar
em outros sub-processos
3.3.3 Gerenciamento
Está fundamentado na Colaboração e Comunicação, refletindo a natureza
colaborativa da gerência de projetos do OpenUp.
O Gerente não deve planejar sozinho uma iteração. Deve envolver toda a
equipe, garantindo que:
− o conhecimento de todos seja refletido dentro do planejamento;
− estimativas sejam realizadas por quem irá realizar o trabalho;
− a escolha das tarefas deve ser feita pelos próprios integrantes da equipe
conforme suas habilidades.
As tarefas e produtos de trabalho do Gerenciamento serão encontradas da
disciplina e domínio Gerenciamento de Projetos.
3.3.4 Solução
Fundamentada na camada de Colaboração e Comunicação, esse sub-processo
constitui a espinha dorsal do OpenUp, que afirma que todos os papéis são envolvidos no
desenvolvimento da solução, as configurações validadas são de responsabilidade de
toda a equipe e as melhores práticas para o desenvolvimento colaborativo auxiliam no
desenvolvimento de soluções [OPE 07].
3.4 Atores
3.4.1 Analista
O objetivo do Analista é capturar e definir prioridades nos requisitos recolhidos
dentro do problema apresentado pelos stakeholders.
As principais habilidades que o Analista deve apresentar são: experiência em
entender os problemas e oportunidades; habilidade para articular necessidades
associadas e oportunidades a serem resolvidas; boa comunicação; conhecimento do
negócio e da tecnologia, ou aprendizado rápido desses tipos de informações.
As principais tarefas são: Define Vision, Detail Requirements e Find and
Outline Requirements. Com base nessas tarefas, o Analista é responsável pelo
desenvolvimento dos seguintes artefatos: Actor, Glossary, Supporting Requirements,
Use Case, Use case Model e Vision.
Ilustração 2: Tarefas e Artefatos relacionados ao AnalistaFonte: OpenUp/Basic [OPE 07]
3.4.2 Any Role
A definição desse ator foi concebida com a finalidade de que, qualquer
membro da equipe possa realizar tarefas gerais: acessar a efetuar manutenção de
artefatos já presentes no sistema; enviar pedido de alteração do projeto; participar de
revisões e definições de prioridades e ser voluntário de uma iteração em particular.
Ilustração 3: Tarefas e Artefatos relacionados ao Any RoleFonte: OpenUp/Basic [OPE 07]
3.4.3 Arquitetos
A principal função do Arquiteto é coordenar a criação do design técnico do
sistema, e ser responsável pelo gerenciamento de decisões técnicas relacionadas ao
projeto, ou seja, o Arquiteto deve identificar e documentar todas as visões da arquitetura
do sistema, incluindo os requisitos, design, implementação e liberação do deploy.
O membro da equipe que desempenha essa função deve trabalhar juntamente
com o Gerente de Projeto no momento de recrutamento de pessoal e do planejamento
do projeto, ele também é responsável por reduzir riscos técnicos, gerenciar os anseios
dos stakeholders e garantir a comunicação entre os membros da equipe que devem ser
validadas e seguidas por todo grupo.
O Arquiteto deve ser uma pessoa com maturidade e agilidade para julgar
mesmo não tendo todas as informações à sua disposição, suas habilidades devem ser:
domínio de engenharia de software e solução de problemas; liderança; comunicação;
pró-ativo e deve seguir os objetivos. Esse membro deve estar pronto para realizar as
seguintes tarefas: Analyze Architectural Requirements, Demonstrate the Architecture e
Develop the Architecture. Deverá também ser responsável pela criação dos seguintes
artefatos: Architectural Proof-of-Concept e Architecture.
Ilustração 4: Tarefas e Artefatos relacionados ao ArquitetoFonte: OpenUp/Basic [OPE 07]
3.4.4 Desenvolvedor
Esse ator é responsável pelo desenvolvimento de parte do sistema e caso seja
necessário adaptá-lo à arquitetura, possibilitando a prototipação de user-interface e
efetuando a implementação, realizando os testes e fazendo a integração das partes da
solução.
Suas principais habilidades são definir e desenvolver solução técnica fazendo
uso das tecnologias adotadas no projeto; identificar e construir casos de testes para
efetuar a validação de comportamentos do sistema e descrever designs de forma clara
que facilite o entendimento dos demais membros da equipe. O Desenvolvedor deve ser
capaz de executar as seguintes tarefas: Design the Solution, Implements Developer
Tests, Implements the Solution e Run Developer Tests. Ele também criará e dará
manutenção nos seguintes artefatos: Build. Design, Developer Tests e Implementation.
Ilustração 5: Tarefas e Artefatos relacionados ao DesenvolvedorFonte: OpenUp/Basic [OPE 07]
3.4.5 Gerente de Projetos
O membro da equipe que desempenhar esse papel será responsável pelo
planejamento e avaliação de riscos do projeto, coordenação de iterações com os
stakeholders e manter a equipe focada no desenvolvimento para que sejam alcançados
os objetivos do projeto.
Suas principais habilidades são boa apresentação, comunicação e negociação;
forte liderança; ser capaz de ensinar, guiar e prestar suporte à equipe devido à sua
experiência com ciclos de vida; ser muito hábil em resolução de conflitos e técnicas
para solucionar problemas. O Gerente de Projetos deve estar apto para executar as
seguintes tarefas: Assess Results, Manage Iteration, Plan Iteration, e Plan Project. Ele
também será responsável pela criação e manutenção dos seguintes artefatos: Iteration
Plan, Project Plan, Risk List, Status Assessmentes e Work List.
Ilustração 6: Tarefas e Artefatos relacionados ao Gerente de ProjetoFonte: OpenUp/Basic [OPE 07]
3.4.6 Tester
Este é o ator responsável pelas atividades na área de teses, tem como função
identificar os testes e o modo como eles serão realizados, configurar, executar,
documentar e analisar os testes realizados, comunicar os resultados a toda equipe.
O tester deverá ter habilidade para diagnosticar e solucionar problemas;
conhecimento do sistema e sobre a arquitetura do sistema; se forem usados testes
automatizados, o tester deverá ter mais algumas habilidades, tais como, habilidade em
diagnóstico e debbugging; programação; conhecimento de ferramentas de automação de
testes e deverá ter treinamento apropriado para fazer uso da ferramenta de automação.
Ilustração 7: Tarefas e Artefatos relacionados ao TesterFonte: OpenUp/Basic [OPE 07]
3.4.7 Stakeholder
Esse ator representa grupos interessados cujas necessidades precisam ser
satisfeitas durante e ao término do projeto. Pode ser atribuído a qualquer pessoa que
será afetada (financeiramente) pelo resultado do projeto.
3.5 As disciplinas do OpenUp/Basic
3.5.1 Requisitos
Esta disciplina é responsável por obter, analisar, especificar, validar e gerenciar
os requisitos do sistema a ser produzido. Os principais objetivos são entender o
problema e as necessidades dos stakeholders; definir os requisitos, o escopo e as
interfaces do sistema; identificar as limitações técnicas da solução; prover a base para
planejamento da solução e a base inicial para estimar os custos e o cronograma. O
gerenciamento de requisitos acontece durante todo o ciclo de vida.
A disciplina de requisitos está relacionada com análise e design, que recebem
os requisitos como seu artefato de entrada; testes, que validam o sistema de acordo com
os requisitos; gerenciamento de configuração e mudança, que lhe dá os mecanismos
para o gerenciamento nas alterações e mudanças; gerenciamento de projeto, que planeja
o projeto relacionando requisitos e iterações de acordo com as prioridades estabelecidas.
3.5.2 Análise e Design
Esta disciplina agrupa tarefas que auxiliarão na criação do design que será
implementado pelos Desenvolvedores a partir dos requisitos do sistema, tendo as
seguintes tarefas, Analyze Architectural Requirements, Demonstrate the Architeture,
Design the Solution e Develop the Architecture.
Os principais objetivos estão entre transformar requisitos em design do
sistema, desenvolver uma arquitetura robusta para a solução e adaptar o design às
características do ambiente de desenvolvimento, essa disciplina está relacionada com
outras da seguinte forma: requisitos produzem artefatos primários para execução das
tarefas de Análise e Design; implementação, receberá os designs do sistema; testes
realizam validações do design do sistema; e gerenciamento de projeto, planeja o projeto
e cada iteração.
3.5.3 Implementação
Essa disciplina está associada ao desenvolvimento das iterações do sistema que
tem por objetivo verificar se as unidades técnicas utilizadas na construção do sistema
funcionam como especificadas e desenvolver o produto final. Possui as seguintes
atividades: Implement Developer Tests, Implement the Solution e Run Developer Tests.
A cada iteração as tarefas realizadas serão capazes de produzir builds mais
estáveis, assim, os Desenvolvedores estarão cada vez mais interados a arquitetura
planejada.
A implementação possui os seguintes relacionamentos: requisitos, definem o
que será implementado; análise e design, organizam a implementação; testes, validam a
implementação dos requisitos; gerenciamento de configurações e alterações, gerencia as
alterações realizadas nos builds do sistema; e gerenciamento de projeto, planeja qual a
funcionalidade será implementada em cada iteração.
3.5.4 Testes
A disciplina de testes é um conjunto de atividades necessárias para o
planejamento, implementação, execução e avaliação de testes do sistema. As atividades
relacionadas a essa disciplinas são Create Tests Cases, Implement tests e Run Tests,
seus objetivos principais são encontrar e documentar defeitos e garantir que o produto
funciona conforme o design, validar o design e as especificações de requisitos e garantir
que a implementação está de acordo com definição dos requisitos.
Esta disciplina está relacionada com as demais da seguinte forma, requisitos,
que relaciona quais requisitos serão testados; análise design, que ajuda na definição dos
tipos de testes a serem realizados; implementação, que disponibiliza os builds para
serem testados; gerenciamento de projetos, que descreve os planos de iterações e define
a missão correta para avaliação da iteração; gerenciamento de configuração e mudança,
os testes verificam se as alterações foram concluídas corretamente, as propriedades dos
testes são gerenciadas pelo gerenciamento de configurações.
3.5.5 Gestão de Projeto
O gerenciamento de projeto pode ser definido como a ligação stakeholders e a
equipe de desenvolvimento. É primordial que esse gerenciamento desenvolva ambientes
de alta produtividade onde stakeholders tenham confiança na habilidade do time de
desenvolvimento no momento da entrega do produto condizente a suas expectativas e
que a equipe do projeto entenda essas necessidades, produzindo, assim, softwares de
qualidade.
Esse gerenciamento é formado por quatro tarefas: Assess Results, Manage
Iteration, Plan Iteration e Plan Project, que tem por objetivos principais manter o foco
da equipe no desenvolvimento e entrega do produto para avaliação do stakeholder, criar
ambiente produtivo, manter a equipe e os stakeholders informados sobre o andamento
do projeto, acompanhar os riscos e adaptação do projeto e priorizar a seqüência de
trabalhos.
3.5.6 Gestão de Configuração e Mudança
O Gerenciamento de Configurações é a habilidade de manter versões dos
artefatos e suas configurações consistentes com os objetivos citados. Gerenciamento de
Alterações refere-se ao gerenciamento de modificações relacionadas ás configurações
dos artefatos apresentados.
Esse processo possui como objetivo manter um conjunto consistente dos
produtos dos trabalhos realizados através de sua evolução, manter builds consistentes do
software, prover formas eficientes de adaptar-se as mudanças e problemas e replanejar o
trabalho e prover dados para avaliação de progresso.
3.6 Ciclo de Vida do OpenUp/Basic
Ilustração 8: Ciclo de Vida OpenUp/BasicFonte: OpenUp/Basic [OPE 07]
O ciclo de vida apresentado é um processo de desenvolvimento de software,
baseado no OpenUp/Basic, definido para suportar equipe de pequeno porte e que
trabalham em um projeto durante três a seis meses. As finalidades desse processo são:
oferecer guias para projetos de pequena escala; permitir aos Gerentes de Projeto a
criação dos planos de projeto baseados nas estruturas de trabalho propostas; permitir
que os Gerentes de Projeto tracem metas baseados nos objetivos; permitir que os
membros da equipe compreendam como executar seu trabalho para alcançar os
objetivos do projeto; fornecer um processo completo da entrega que sirva de exemplo
para definir processos alternativos [OPE 07].
3.6.1 Inception Phase Iteration
Ilustração 9: Inception Phase IterationFonte: OpenUp/Basic [OPE 07]
Este molde da iteração define as atividades (e papéis associados e produtos do
trabalho) executadas em uma iteração típica na fase do Inception. Cada atividade e
objetivos relacionados são descritos a seguir. O projeto começa com a suposição de que
o case do negócio já esteja criado, o Gerente de Projeto foi identificado, a equipe (pelo
menos para a primeira iteração) foi definida, o ambiente do desenvolvimento está
pronto para receber a equipe, e no processo a ser seguido é o processo da entrega
sugerido por OpenUP/Basic. O número e a duração de cada iteração do Inception irão
variar dependendo das necessidades do projeto.
− Initiate Project: esta atividade ocorre no começo da primeira iteração,
quando o projeto começa. O objetivo desta atividade é estabelecer a visão
para o projeto e o plano do projeto em uma elevação – em nível de
granularidade. Tendo como principais objetivos, estabelecer a visão e o
planejamento do projeto em um mais alto grau de abstração. É realizado no
começo da fase de Inception na primeira iteração.
− Manage Iteration: tarefa desempenhada unicamente pelo Gerente de
Projeto, seu objetivo é gerenciar todas as atividades dentro de cada
iteração, acompanhando e comunicando aos stakeholders o status do
projeto, identificando riscos e “repriorizando” o trabalho. Esta atividade
está presente em todas as fases do ciclo de vida.
− Manage Requirements: atividade que tem como foco o mapeamento das
necessidades dos stakeholders e têm por resultado os requisitos do sistema,
lista de riscos e planejamento o cronograma do projeto. Ocorrendo durante
todo o ciclo de vida de desenvolvimento por meio da colaboração de todos
os membros da equipe juntamente com os stakeholders com o objetivo de
estabelecer um conjunto consistente, correto e passível de validação de
requisitos do sistema. Os objetivos dessa tarefa são obter, especificar,
analisar e validar o conjunto esses requisitos.
− Determine Architectural Feasibility: essa atividade é realizada pelo
Arquiteto. Aqui são criados os protótipos de algumas possíveis arquiteturas
para o sistema baseados nos requisitos do projeto, o Arquiteto deverá
propor uma arquitetura de alto nível que esteja de acordo com as
funcionalidades e restrições do sistema, maximizando os benefícios aos
stakeholders.
3.6.2 Elaboration Phase Iteration
Ilustração 10: Elaboration Phase IterationFonte: OpenUp/Basic [OPE 07]
Este molde da iteração define as atividades (e papéis associados e produtos do
trabalho) executadas em uma iteração típica na fase do Elaboration. Cada atividade e
objetivos relacionados são descritos a seguir.
O objetivo dessa fase é estabelecer um baseline da arquitetura do sistema que
seja o suporte de todas as atividades seguintes do desenvolvimento, está focada nos ris-
cos relacionados à arquitetura do sistema. Esta fase acompanha o gerenciamento de ris-
cos juntamente com os requisitos, o cronograma, os custos e a arquitetura do projeto,
tendo como metas o entendimento mais detalhado dos requisitos; o design, implementa-
ção, validação e estabelecimento de baseline da arquitetura; tratamento de prioridades e
produção de cronogramas e construção de estimativas de custos mais precisos.
− Manage iteration: atividade desempenhada somente pelo Gerente de
Projeto. Seu objetivo é o de gerenciar todas as atividades que compõem
cada iteração, fazendo a monitoração e a comunicação do status do projeto
aos stakeholders, essa verificação, em alguns projetos, pode ser feita em
reuniões diárias, que permitem uma compreensão mais precisa de como o
trabalho em uma iteração está progredindo, caso seja necessário a equipe
efetua as devidas correções para alcançar o objetivo planejado. Essa
atividade está presente em todas as fases do ciclo de vida.
− Manage requirements: essa atividade ocorre durante todo o ciclo de vida
de desenvolvimento, é necessária a colaboração de todos os membros da
equipe e dos stakeholders para juntos estabelecerem o conjunto consistente,
correto e passível de validação de requisitos do sistema. Os objetivos gerais
dessa atividade são obter, especificar, analisar e validar esse conjunto de
requisitos. Durante a fase Elaboration, as exigências podem ainda ser
capturadas e esboçadas enquanto as necessidades do cliente são levantadas,
as exigências de alto risco ou de arquitetura são mais detalhadas e suas
informações são usadas como entrada para a iteração atual e são
importantes para o planejamento da iteração seguinte.
− Define the architecture: o principal propósito dessa atividade é a definição
da arquitetura que possibilita a implementação dos requisitos de alta
prioridade, dando uma base sólida e resistente onde são desenvolvidas as
funcionalidades. Essa atividade está presentes em todas as iterações da fase
de Elaboration. Durante todas as iterações o Arquiteto deve identificar os
pontos em comum entre os diferentes requisitos, definir estratégias para
obter as exigências relacionadas à qualidade e observar e comunicar as
decisões arquiteturais.
− Develop solution for requirement within context: os objetivos dessa
atividade são design, implementar, testar e integrar em um determinado
contexto, a solução para um requisito. O contexto é especificado quando o
Desenvolvedor recebe o requisito, seu foco pode ser em uma camada, em
um componente, entre outros. Essa atividade é instanciada em diferentes
épocas, para cada tarefa do desenvolvimento dessa iteração. O objetivo
principal é um sistema executável que forneça a qualidade e a
funcionalidade incrementais para as exigências específicas dentro do
contexto especificado.
− Validate build: essa atividade é repetida durante todo o ciclo de vida do
projeto. O objetivo principal desta atividade é validar o incremento atual do
sistema de encontro às exigências alocadas a ele, criando e executando
testes que validem as funcionalidades desenvolvidas de acordo com os
requisitos do sistema.
− Ongoing tasks: esta atividade inclui as tarefas que acontecem durante toda
a iteração, mas não é necessariamente parte de um plano. Criada com a
finalidade de “acomodar” outras tarefas, essa tarefa é executada por
qualquer membro da equipe em qualquer fase do ciclo de desenvolvimento.
3.6.3 Construcion Phase Iteration
Ilustração 11: Construcion Phase IterationFonte: OpenUp/Basic [OPE 07]
Este molde da iteração define as atividades (e papéis associados e produtos do
trabalho) executadas em uma iteração típica na fase do Transiction. Cada atividade e os
objetivos relacionados são descritos a seguir. Sua estrutura de trabalhos é semelhante à
Elaboration Phase, pois suas atividades são executadas em paralelo. Nesse nomento a
arquitetura deverá estar consolidada, devendo ter somente requisitos de baixo impacto
para serem implementadas, as funcionalidades serão testadas e validadas tendo como re-
sultado builds mais completos.
O Gerente de Projeto terá seu foco direcionado para a redução dos custos e ge-
renciamento e análise da eficiência da equipe. Devem ser contemplados dois objetivos
principais, desenvolvimento de produtos completos e minimização de custos de desen-
volvimento e atingir o paralelismo no desenvolvimento.
− Manage iteration: esta atividade é executada durante todo o ciclo de vida
do projeto. O objetivo desta atividade é identificar riscos cedo o bastante
para contorná-los, para estabelecer os objetivos para a iteração, e para dar
suporte à equipe do desenvolvimento para alcançar estes objetivos. Um dos
objetivos dessa atividade é a liberação de uma versão beta do sistema aos
stakeholders.
− Manage requirements: esta atividade é repetida durante todo o ciclo de
vida. Seu objetivo é compreender e dar prioridade as necessidades da parte
interessada e a exigências associadas para o sistema. Os requisitos
prioridade mais baixa são detalhados e repassados à equipe de
desenvolvimento.
− Develop solution: tendo como objetivo principal um sistema executável
que forneça qualidade e funcionalidade especificadas dentro do contexto do
projeto, essa atividade tem como foco a implementação de requisitos de
níveis média a baixa prioridade.
− Validate build: atividade que tem por meta a liberação de versão beta do
sistema ao final da iteração. Ela é repetida em todo o ciclo de vida do
projeto, validando a atividade do incremento da iteração.
3.6.4 Transiction Phase Iteration
Ilustração 12: Transiction Phase IterationFonte: OpenUp/Basic [OPE 07]
O propósito dessa fase é a de assegurar que todas as funcionalidades estarão
contempladas na entrega do produto. Tem como principais objetivos avaliar, por meio
de testes, se o produto atende as expectativas o cliente; os stackhoders validam o
deploy, aprender com as lições desse projeto para aplicar nos projetos futuros. Nessa
fase as maiorias das atividades acontecem de forma paralela, é avaliado o desempenho a
qualidade e a funcionalidade do produto.
− Manage iteration: tendo como objetivo a identificação de riscos e
possíveis alterações cedo o bastante para poderem ser solucionadas. É uma
atividade que se repete ao longo de todo o ciclo de vida do projeto, deve
estabelecer metas e dar suporte á equipe de desenvolvimento. Essa
atividade tem como foco a liberação de uma versão estável do produto,
permitindo a aprovação por parte dos stakeholders.
− Ongoing tasks: submissões de pedidos da mudança durante a fase da
Transition são trabalhadas diferentemente do que em outras fases. As
exigências novas serão raramente identificadas nesse estágio do ciclo de
vida do desenvolvimento, caso haja novos pedidos para o release, os
mesmos podem ser listados e alocados para uma liberação futura, quando
um novo ciclo de vida do desenvolvimento do software começar. Nesse
caso, as exigências serão esboçadas e detalhadas de acordo com os
requisitos da nova iteração.
− Develop solution for requirement within context: esta atividade é repetida
durante o ciclo de vida do projeto, em paralelo com as demais atividades,
para cada atividade do desenvolvimento dessa iteração. Um sistema
executável que forneça qualidade e funcionalidade incrementais é o
principal objetivo dessa atividade, cumprindo as exigências especificadas
dentro do contexto do projeto. Os erros que possam ter sido apresentados
em outras iterações deverão ser corrigidos e validados antes de ser efetuado
o deploy.
− Validate build: o objetivo principal dessa atividade é validar o incremento
atual do sistema tendo em vista as exigências alocadas a ele. Essa atividade
é repetida durante todo o ciclo de vida do projeto e é executada em paralelo
com as demais atividades. É feito a verificação da implementação dos
requisitos e atestado a estabilidade da versão.
Capítulo 4
4 Eclipse Process Framework
O EPF Composer é uma ferramenta de gerenciamento de processos que
possibilita um fácil aprendizado e métodos simples de autoria, customização e criação
de processos de desenvolvimento [HAU 06].
A IBM oferece uma versão comercial do EPF Composer chamada IBM Rational
Method Composer (RMC), que trabalha com o IBM Rational Unified Process (RUP)
[HAU 06].
Eclipse Process Framework é uma plataforma que se destina a engenheiros de
processos, líderes e gerentes de projeto ou qualquer responsável por manter e
implementar processos de desenvolvimento em organizações ou projetos individuais.
O EPF possui dois propósitos principais que buscam solucionar as seguintes
necessidades:
1. Prover aos profissionais de desenvolvimento uma base de conhecimento
intelectual onde seja possível criar, alterar, gerenciar e divulgar
conteúdos. Esse conteúdo inclui princípios, boas práticas, definições de
métodos, templates, procedimentos e regulamentações internas, material
de treinamento, entre outras descrições que auxiliem no desenvolvimento
do projeto. A vantagem da divulgação por essa ferramenta está no fácil
acesso pelos interessados no projeto: todo conteúdo gerenciado no EPF
Composer pode ser publicado em html e disponibilizado em um browser.
2. Prover aos responsáveis pelo processo de desenvolvimento uma
ferramenta de fácil customização de processos de acordo com as
necessidades de cada organização. EPF Composer disponibiliza
catálogos de processos pré-definidos que podem ser utilizados da
maneira como foram determinados, ou adaptados de acordo com as
características individuas de cada projeto.
A principal característica do Eclipse Process Framework é a separação dos
conteúdos de métodos3 de suas aplicações ao longo dos processos.
Conteúdos de métodos descrevem o que deve ser produzido, e são
independentes do ciclo de vida de desenvolvimento. Processos são os responsáveis por
inserir os conteúdos nesse ciclo, através de sequências semi-ordenadas, de forma
flexível.
A figura abaixo demonstra essa separação de forma mais clara. A
representação é a mesma já adotada pelo Unified Process (UP).
Ilustração 13: Representação bi-dimensional da separação entre conteúdos do método e o processo do Unified Process.Fonte: [HAU 06]
O conteúdo do método descreve como o trabalho de desenvolvimento é
realizado. Na figura, pode ser visualizado através de disciplinas ao longo do eixo y.
Esse trabalho então, é referenciado de forma sequencial, em processos, ao longo do eixo
x, representando uma linha de tempo. Esse é o ciclo de vida de um projeto, e expressa
quando uma determinada tarefa será realizada. Os gráficos no centro, representam uma
estimativa de esforço para cada disciplina [HAU 06].
3 Nomenclaturas, atores, tarefas, produtos de trabalho [HAU 07]
Capítulo 5
5 EPF e OpenUP/Basic – Customização e Aplicação
(...)
Capítulo 6
6 Conclusão
O trabalho proposto não tem intenção de tirar a importância das metodologias
tradicionais, apenas visa apresentar uma alternativa a empresas que desejam aumentar a
produtividade e qualidade, sem deixar de lado a definição e documentação dos
processos.
O propósito do projeto é justamente, a partir de uma metodologia com menos
formalismo, abrir portas para práticas sólidas de gerência e engenharia de software.
Dessa forma, a medida que a empresa cresce no mercado, seu processo de
desenvolvimento poderá acompanhar sua evolução.
6.1 Sugestões para trabalhos futuros
. Referências Bibliográficas
[BAL 07] BALDUINO, R., LYONS, B. OpenUP/Basic – A Process for Small and
Agile Projects. Disponível em <http://www.eclipse.org/epf/general/
getting_started.php>. Acesso em: 06/2007.
[BEC 99]BECK. K. Extreme Programing Explained: Embrace Change. Pearson
Education Canada, 1999. 224 p.
[BEE 07] BEEDLE, M. et al. Manifesto for Agile Software Development. Disponível
em <http://agilemanifesto.org>. Acesso em: 02/2007.
[CUN 07] CUNHA, C. E. A.. D. Utilizando OpenUp/Basic para Desenvolvimento de
Aplicações Web. 2007. 73 f. Trabalho de Conclusão de Curso (Graduação em
Ciência da Computação) – Universidade Federal de Pernambuco, Recife,
2007.
[ECL 07] ECLIPSE. Eclipse Process Framework project. Disponível em
<http://www.eclipse.com/epf>. Acesso em: 02/2007.
[ERU 07] ERUDIO. Erudio. Disponível em <http://www.erudio.com.br/component/
option,com_docman/task,cat_view/gid,20/dir,DESC/order,date/
limit,5/limitstart,0/>. Acesso em: 02/2007.
[FIL 07] FILEV, A. Adotando e se beneficiando de processos ágeis no
desenvolvimento de software no exterior. Disponível em: <http://
www.microsoft.com/brasil/msdn/Tecnologias/arquitetura/Proc_Ageis.mspx>.
Acesso em: 02/2007.
[HAU 06] HAUMER, P. Eclipse Process Framework Composer Part 1: Key
Concepts. Eclipse, [S. l.], 15 dezembro 2005. Disponível em
<http://www.eclipse.org/epf/general/ getting_started.php>. Acesso em:
12/2006.
[HAU 07] HAUMER, P. IBM Rational Method Composer Part 1: Key concepts.
Eclipse, [S. l.], abril 2007. Disponível em <http://www.ibm.com/
developerworks/rational/library/dec05/haumer/>. Acesso em: 01/2007.
[IBM 07]IBM. IBM. Disponível em <http://www.ibm.com>. Acesso em: 02/2007.
[INF 07] INFOCOMP. Infocomp. Disponível em < http://www.dcc.ufla.br/infocomp/
artigos/v3.2/art02.pdf>. Acesso em: 02/2007.
[JAC 99] JACOBSON, I., BOOCH, G., RUMBAUGH, J., The Unified Software
Development Process. Addisson-Wesley, 1999. 512 p.
[NER 07] NERI, H. S. Notas de aula da disciplina Engenharia de Software
Utilizando Orientação a Objetos. Disponível em <http://dns.redes.unb.br/
material/ESOO/ Metodologias%20%C1geis.pdf>. Acesso em: 02/2007.
[OPE 07] OPENUP/BASIC. OpenUP/Basic published Web site. Disponível em
<http://www.eclipse.org/epf/downloads/openup/ openup_downloads.php>.
Acesso em: 06/2007.
