UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Ana Marta Borgonovo Roberta Santos da Silva

Transcrição

1 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

2 Sumário 1Introdução Justificativa Objetivos Objetivo Geral Objetivos Específicos Metas Fundamentação Teórica Problematização e Metodologia Estrutura do Trabalho Cenário Open Unified Process (OpenUP) Visão Geral Princípios Colaboração Equilíbrio Foco Evolução Sub-Processos Colaboração e Comunicação Propósito Gerenciamento Solução Atores Analista Any Role Arquitetos Desenvolvedor Gerente de Projetos Tester Stakeholder As disciplinas do OpenUp/Basic Requisitos Análise e Design Implementação Testes Gestão de Projeto Gestão de Configuração e Mudança Ciclo de Vida do OpenUp/Basic Inception Phase Iteration Elaboration Phase Iteration Construcion Phase Iteration Transiction Phase Iteration Eclipse Process Framework EPF e OpenUP/Basic Customização e Aplicação Conclusão... 38

3 6.1 Sugestões para trabalhos futuros Referências Bibliográficas...39

4 Índice de Figuras Ilustração 1: Sub-Processos do OpenUP/Basic Ilustração 2: Tarefas e Artefatos relacionados ao Analista Ilustração 3: Tarefas e Artefatos relacionados ao Any Role Ilustração 4: Tarefas e Artefatos relacionados ao Arquiteto Ilustração 5: Tarefas e Artefatos relacionados ao Desenvolvedor 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 Ilustração 9: Inception Phase Iteration Ilustração 10: Elaboration Phase Iteration...28 Ilustração 11: Construcion Phase Iteration...31 Ilustração 12: Transiction Phase Iteration 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

5 Resumo

6 Abstract

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

8 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 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 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

9 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 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 stakeholders 1 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).

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

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

12 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

13 development for different lines of businesses as well as IT operations to improve business performance 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. como: Este processo de desenvolvimento de software é iterativo e pode ser definido 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).

14 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 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 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

15 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 Foco de arquitetura. Esse princípio tem como característica a importância de uma sólida definição 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 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

16 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/Basic Fonte: OpenUp/Basic [OPE 07]

17 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 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 Gerenciamento Está fundamentado na Colaboração e Comunicação, refletindo a natureza colaborativa da gerência de projetos do OpenUp.

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

19 Use Case, Use case Model e Vision. Ilustração 2: Tarefas e Artefatos relacionados ao Analista Fonte: OpenUp/Basic [OPE 07] 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 Role Fonte: OpenUp/Basic [OPE 07] 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.

20 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 Arquiteto Fonte: OpenUp/Basic [OPE 07] 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.

21 Ilustração 5: Tarefas e Artefatos relacionados ao Desenvolvedor Fonte: OpenUp/Basic [OPE 07] 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 Projeto Fonte: OpenUp/Basic [OPE 07] 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.

22 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 Tester Fonte: OpenUp/Basic [OPE 07] 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 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

23 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 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 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

24 funcionalidade será implementada em cada iteração 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 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.

25 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/Basic Fonte: 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].

26 3.6.1 Inception Phase Iteration Ilustração 9: Inception Phase Iteration Fonte: 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.

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

28 3.6.2 Elaboration Phase Iteration Ilustração 10: Elaboration Phase Iteration Fonte: 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 riscos relacionados à arquitetura do sistema. Esta fase acompanha o gerenciamento de riscos 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

29 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

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

31 3.6.3 Construcion Phase Iteration Ilustração 11: Construcion Phase Iteration Fonte: 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 resultado builds mais completos. O Gerente de Projeto terá seu foco direcionado para a redução dos custos e gerenciamento e análise da eficiência da equipe. Devem ser contemplados dois objetivos principais, desenvolvimento de produtos completos e minimização de custos de desenvolvimento 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

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

33 3.6.4 Transiction Phase Iteration Ilustração 12: Transiction Phase Iteration Fonte: 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

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

35 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. necessidades: O EPF possui dois propósitos principais que buscam solucionar as seguintes 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.

36 A principal característica do Eclipse Process Framework é a separação dos conteúdos de métodos 3 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]

37 Capítulo 5 5 EPF e OpenUP/Basic Customização e Aplicação (...)

38 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

39 . Referências Bibliográficas [BAL 07] BALDUINO, R., LYONS, B. OpenUP/Basic A Process for Small and Agile Projects. Disponível em < getting_started.php>. Acesso em: 06/2007. [BEC 99]BECK. K. Extreme Programing Explained: Embrace Change. Pearson Education Canada, p. [BEE 07] BEEDLE, M. et al. Manifesto for Agile Software Development. Disponível em < Acesso em: 02/2007. [CUN 07] CUNHA, C. E. A.. D. Utilizando OpenUp/Basic para Desenvolvimento de Aplicações Web f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Universidade Federal de Pernambuco, Recife, [ECL 07] ECLIPSE. Eclipse Process Framework project. Disponível em < Acesso em: 02/2007. [ERU 07] ERUDIO. Erudio. Disponível em < 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: < Acesso em: 02/2007. [HAU 06] HAUMER, P. Eclipse Process Framework Composer Part 1: Key Concepts. Eclipse, [S. l.], 15 dezembro Disponível em < getting_started.php>. Acesso em: 12/2006. [HAU 07] HAUMER, P. IBM Rational Method Composer Part 1: Key concepts. Eclipse, [S. l.], abril Disponível em <

40 developerworks/rational/library/dec05/haumer/>. Acesso em: 01/2007. [IBM 07]IBM. IBM. Disponível em < Acesso em: 02/2007. [INF 07] INFOCOMP. Infocomp. Disponível em < artigos/v3.2/art02.pdf>. Acesso em: 02/2007. [JAC 99] JACOBSON, I., BOOCH, G., RUMBAUGH, J., The Unified Software Development Process. Addisson-Wesley, p. [NER 07] NERI, H. S. Notas de aula da disciplina Engenharia de Software Utilizando Orientação a Objetos. Disponível em < material/esoo/ Metodologias%20%C1geis.pdf>. Acesso em: 02/2007. [OPE 07] OPENUP/BASIC. OpenUP/Basic published Web site. Disponível em < openup_downloads.php>. Acesso em: 06/2007.