FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

Transcrição

1 FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010

2 OpenUP Alguns anos atrás, vários funcionários da IBM começaram a pensar sobre como seria possível criar uma versão ágil do IBM Rational Unified Process, ou simplesmente RUP. Ao mesmo tempo em que esse novo processo deveria ser ágil, também teria que refletir as boas práticas já contidas no RUP e consolidadas no mercado de software. A partir desse momento, o time IBM formado por gerentes de metodologias, especialistas e analistas de processo começou a trabalhar em uma nova versão com a proposta de criar um novo processo enxuto, completo e ao mesmo tempo extensível. A longo do tempo esse mesmo time percebeu que seria necessária a contribuição através de conhecimentos e experiências de um conjunto muito mais amplo de pessoas. Daí então que a IBM através do projeto EPF (Eclipse Process Framework), liderado por Per Kroll (Gerente de Métodos IBM) forneceu para a comunidade Eclipse o conteúdo da versão inicial desse novo processo, até então considerada uma versão light e ágil do RUP. OpenUP é um processo para o desenvolvimento de produtos de software que agrega muitos conceitos do RUP e adiciona valor e práticas ágeis principalmente de metodologias como o XP e o Scrum. Atualmente o OpenUP encontra se na versão disponível no site Eclipse : O OpenUP é baseado em 4 princípios básicos que são: Colaborar para alinhar interesses e compartilhar conhecimento, Focar na articulação da arquitetura, Balancear prioridades concorrentes com o retorno de valor para o Stakeholder e Envolvimento continuo para obtenção de feedback e melhorias.

3 Como você pode perceber a figura a cima ilustra que através de diversos papéis as pessoas gerenciam e desenvolvem soluções mas como a Comunicação e Colaboração como meio para isso. O OpenUP é sub set do RUP muito enxuto e podemos perceber isso pelos papéis, são apenas 6 papéis. São os 6. Outra característica ágil é que ele se propõe a entregar software com o mínimo de formalismo e artefatos gerados. Isso funciona, mas não é uma bala de prata, dependendo do projeto será necessário adicionar mais atividades e artefatos aos roles. Descrição dos papéis... Stakeholder:. Os Stakeholders são todas as pessoas que estão interessadas no projeto, por que? Você irá atender alguma necessidade delas através de software. No Scrum o Stakeholder é o PO(Product Owner) mas pode ser qualquer outra pessoa, até mesmo uma pessoa da equipe técnica. Project Manager: Clássico gerente de projetos. Esse cara conduz os planejamentos do projeto em conjunto com a equipe e os stakeholders. Ele matem o foco da equipe para a realização dos objetivos do projeto. OBS: No OpenUP o que seria o Product Backlog é o Work Item List. Na prática é a mesma "coisa".

4 Outro valor interessantíssimo que processo tem é o fato de ser dirigido a Riscos. Então o Project Manager também é responsável pela Lista de Riscos. No OpenUP/Basic é considerado bom ter no máximo 20 riscos na lista. Por que devem estar na lista apenas riscos sérios. Analyst: Famoso Analista. A pessoa(s) por trás desse papel representa os interesses dos stakeholders e usuários do sistema. Ele é responsável por capturar os requisitos do sistema e bem como definir as prioridades dos mesmos. Architect: Como todos sabem ele é responsável por definir a arquitetura de software, tomando decisões que orientam a equipe tanto de design e implementação. Bom o arquiteto no processo gera o artefato que se chama "Architecture Notebook" que é + o mesmo documento que existia no RUP, mas lá é chamado de SAD(Software Architecture Document). Developer: O OpenUP/Basic força uma abordagem semelhante a do XP em relação ao TDD. Logo o desenvolvedor é responsável por efetuar testes também. NOTA: A melhor maneira de encarar os testadores ou a equipe de testes é como uma equipe de contenção. Sendo assim eles não são a primeira barreira para os erros mas na verdade a ultima barreira. O OpenUP/Basic fecha com esse principio e por conta disso o developer também se "mete" com testes. Tester : Bom esse cara muitas vezes é odiado pelos desenvolvedores. Na prática isso acontece por que muitos desenvolvedores não tem a cultura de testes ainda.. No processo ele cria os Casos e Testes e implementada os testes. Claro ele roda os testes também! Introdução ao OpenUP O OpenUP está em conformidade com os princípios do Manifesto do Desenvolvimento de Software Ágil, possue uma abordagem iterativa e incremental e é um processo de baixa cerimônia que não está associado a nenhuma ferramenta especifica. Como o OpenUP é um sub set do RUP ele possui as fases: Concepção, Elaboração, Construção e Transcrição e outras coisas boas do RUP. E o legal é que ele juntou o planejamento e controle de marcos do RUP com o gerenciamento de iteração e micro ambiente do Scrum. É isso que a figura a cima mostra. Então temos o gerenciamento de micro ambiente com o work item que são as tarefas que o desenvolvedor utiliza, nesse ponto podemos adicionar as Stand Up Meetings do XP ou Dally Scrum Meetings do Scrum e práticas das duas metodologias. No planejamento da iteração é que entra a maioria das práticas de Scrum, porem adicionadas a diciplina de riscos. Aqui podemos ter as iterações de 2 4 semanas. Aqui o foco é no time e o Gerente de Projetos resolver os impeditivos e planejar. No fim exitste um nível maior que é o planejamento do projeto, onde vai existir o plano do projeto e o controle sobre os meses vs as necessidades que os stakeholders precisão. A idéia do OpenUp é cada vez mais aumentar o valor agregado ao cliente e cada vez

5 mais diminuir os riscos. OpenUP and OpenUP/Basic OpenUP é uma família de plug ins do processo open source. O OpenUP/Basic é o processo fundamental do OpenUP e é adequado para equipe pequenas e não distribuídas geograficamente.. Minimo, Completo e Estensível OpenUP/Basic é minimal, completo e extensível. Contém um processo com o mínimo necessário para equipes pequenas, pode ser utilizado como está e pode ser estendido e personalizado para atender propósitos específicos.. O processo pode ser facilmente entendido através das 3 camadas abaixo descritas: 1º Ciclo de Vida do Projeto Fases com foco nas necessidades dos Stakeholders O OpenUP apresenta a mesma distribuição de fases já conhecidas no RUP, onde o critério de saída de cada fase é no mínimo atender as seguintes respostas: Iniciação: Todos os stakeholders concordam com o escopo e objetivos do projeto? Elaboração: Todos concordam com a arquitetura proposta e o valor entregue ao cliente considerando os riscos levantados? Construção: Existe uma aplicação que está quase pronta rodando bem próxima a ser finalizada? Transição: A aplicação está finalizada e o cliente satisfeito? 2º Ciclo de Vida da Iteração com foco no time: Além da divisão por fases já conhecida, o OpenUP divide o projeto em iterações (também conhecidas como Sprints segundo a metodologia SCRUM) planejadas que podem variar de alguns dias a algumas semanas (a media recomendada é de 4 semanas podendo ser reduzida ou aumentada em até aproximadamente 6 semanas). Ao final de cada iteração deve ser gerado um incremento ao Produto (Build executável ou demo). Ao final de cada iteração geralmente é realizada uma retrospectiva e avaliação onde são discutidas as lições aprendidas e a saúde do projeto. Vale mencionar que o principal objetivo da retrospectiva é aprender com erros e acertos e não apontar culpados. 3º Micro incrementos com foco individual: Um micro incremento é a execução de um pequeno passo que deve ser mensurável para alcançar os objetivos de uma iteração. Este pode representar o resultado de alguns dias ou horas de trabalho de uma pessoa ou um grupo determinado.

6 Figura 1: Camadas OpenUP: Micro incrementos, ciclo de vida da iteração e ciclo de vida do projeto. Elevar o Nível de Abstração: Como forma de diminuir a complexidade, devemos utilizar modelos de abstração sempre focando nos pontos mais complicados, como relacionamentos e padrões. Solução Dirigida ao Problema: Esse eu adoro! Devemos dirigir a solução arquitetural aos problemas, ou seja, montar a arquitetura com base nos problemas que existam. O que eu já vi acontecer várias vezes é a tecnologia dirigir a arquitetura, e isso é o principio do fim! Baixo acoplamento e Alta coesão: Bom que já viu uma palestra minha sobre algum tema relacionado ao desenvolvimento pode notar que eu sempre falo disso. É muito básico mas na práticas por incrível que pareça as pessoas não utilizam esse principio. Reutilização de recursos existentes: Essa é figurinha carimbada, mas também não acontece, se pensarmos mais à frente reutilização é tudo, é parte importantes na filosofia SOA e ABD(Asset Based Development).

7 Relacionamentos: Equilíbrar as prioridades concorrentes para maximizar o valor para os stakeholders Desenvolver uma solução que maximize os benefícios ao stakeholder e cumpra com as restrições impostas ao projeto. Para atingirmos o sucesso, stakeholders e participantes do projeto devem convergir para um claro entendimento e concordar com estes três fatores: Problema a ser resolvido Restrições impostas à equipe de desenvolvimento (custo, cronograma, recursos, regulamentos) Restrições impostas à solução Coletivamente, estes três itens representam os requisitos para o desenvolvimento do sistema. O desafio de todos os participantes do projeto é criar uma solução que maximize o seu valor para os stakeholders, mesmo que sujeitos a restrições. O equilíbrio está em fazer uma análise crítica do custo benefício entre características desejadas e as decisões de projeto subseqüentes que definem a arquitetura do sistema. Separe o problema da solução Com freqüência nos precipitamos ao apresentar uma solução sem a devida compreensão do problema. A final de contas, nós aprendemos a solucionar problemas e não a definir problemas, isso é fácil. No entanto, essa forma de pensar limita o nosso entendimento do problema, impõe restrições artificiais e dificulta a análise equilibrada, ou mesmo conhecimento de quais são as alternativas existentes. Assim, assegure se que você tenha entendido o problema antes de definir a solução. Ao separar claramente o problema (o que os clientes necessitam) da solução (o que o sistema deve fazer), nos ajuda a manter o foco apropriado e facilita acomodar as formas alternativas de resolver o problema. Crie um entendimento compartilhado do domínio Especialistas de domínio normalmente possuem limitações técnicas; desenvolvedores, arquitetos e testers normalmente possuem limitações de domínio; e revisores e outros stakeholders normalmente possuem limitações de tempo para finalizar o projeto e aprender sobre o domínio do problema. Conseqüentemente, as pessoas possuem, normalmente, um entendimento pobre ou inconsistente do domínio do problema, o que provoca problemas de comunicação e eleva as chances de liberar algo de pouquíssimo valor aos stakeholders. Assim, aumente e compartilhe o entendimento de todas as partes do domínio. Um entendimento conciso e compartilhado do domínio do problema eleva a comunicação e a efetividade do projeto. Comece definindo o problema no documento da Visão. Na medida em que você adquirir novos conhecimentos, capture os conceitos e terminologias chaves do domínio no Glossário para assegurar um uso compartilhado consistente da linguagem do domínio.

8 Use cenários e use cases para capturar os requisitos Muitas empresas ainda documentos requisitos como uma lista de declarações, que são algumas vezes chamadas de lista de desejos. Normalmente, os stakeholders têm dificuldades de entender essa lista, porque eles querem que os usuários finais leiam a lista e mentalmente a traduzam numa visualização de como os requisitos irão interagir com o sistema. Assim, use cenários e use cases para capturar os requisitos funcionais de forma que facilite a compreensão dos stakeholders. Os requisitos não funcionais, tais como desempenho, estabilidade e usabilidade são importantes e podem ser documentados nos Requisitos Suplementares, usando técnicas tradicionais. Estabeleça e mantenha um acordo sobre prior idades Tomar decisões sobre o que desenvolver depois, com poucas informações, pode resultar em desperdício de esforço, em liberação de capacidades que nunca serão usadas ou na identificação de problemas tardiamente o que resulta em atrasos e até falhas de projeto. Assim, priorize os requisitos que serão implementados trabalhando regulamente com os stakeholders durante a evolução do produto. Faça escolhas que agreguem valor e reduzam os riscos, enquanto se constrói um sistema que possa evoluir. Faça análises para maximizar o valor A análise do custo benefício não pode ser realizada independentemente da arquitetura. Os requisitos estabelecem os benefícios do sistema para o stakeholder, enquanto a arquitetura estabelece o custo. O custo de um benefício pode influenciar no valor percebido do benefício pelo stakeholder. Assim, trabalhe com os stakeholders e desenvolvedores para priorizar os requisitos e desenvolver arquiteturas candidatas para implementar as soluções. Use as arquiteturas candidatas para avaliar o custo dos benefícios. Soluções candidatas são consideradas num nível elevado durante a determinação da viabilidade arquitetural. Diferentes perspectivas arquiteturais podem resultar em diferentes estimativas de custo versus benefícios. A arquitetura candidata que forneça a maior cobertura no menor custo é selecionada para o desenvolvimento futuro. Gerenciamento do escopo Mudanças são inevitáveis. Embora as mudanças apresentem oportunidades para elevar o valor para o stakeholder, mudanças irrestritas resultarão num sistema inchado, deficiente e inadequado para atender às necessidades do stakeholder. Assim, gerencie as mudanças mantendo a concordância dos stakeholders. Os processos modernos sempre gerenciam mudanças, adaptando continuamente as mudanças ocorridas no ambiente e adequando as necessidades dos stakeholders, avaliando o impacto das mudanças, fazendo análise das alternativas, e repriorizando o trabalho. As expectativas dos stakeholders e desenvolvedores devem ser realísticas e alinhadas conforme o ciclo de desenvolvimento.

9 Saiba quando parar Excesso de engenharia para construir sistemas não só desperdiça recursos, mas também elevada complexidade do sistema. Assim, pare de desenvolver o sistema quando a qualidade desejada for atingida. Lembre se que A qualidade está na compatibilidade com os requisitos. É isto que nos dá um sentido de término para a prática. Separe o problema da solução, assegure que a solução realmente resolve o problema. Depois que os requisitos críticos forem implementados e validados, o sistema estará pronto para a aceitação do stakeholder.

10 Bibliografia: