Processos de software RUP
Revisão Conceitos Básicos - Processo Um conjunto de tarefas ordenadas constitui um processo, uma séria de etapas que envolvem atividades, restrições e recursos para alcançar a saída desejada. Um processo é um conjunto de procedimentos, organizados de modo que nos permita construir produtos que satisfaçam a uma série de objetivos e padrões.
Revisão Caracterização de um processo Um processo envolve um conjunto de ferramentas e técnicas, entre elas: a) o processo deve descrever todas as suas atividades b) o processo utiliza recursos e esta sujeito a restrições dos mesmos c) o processo pode ser composto de sub-processos d) cada atividade do processo tem critérios de entrada e saída e) as atividades são organizadas em sequência, com uma ordem de execução f) todo processo tem um conjunto de diretrizes que explicam os objetivos de cada atividade g) restrições e controles podem ser aplicadas a cada atividade.
Estágios básicos Revisão Basicamente o desenvolvimento de software tem os seguintes estágios: 1. Análise e definição de requisitos 2. Projeto do sistema 3. Programação 4. Testes de integração e de sistemas 5. Entrega do sistema e treinamento de usuários 6. Manutenção 7. Descarte
RUP Rational Unified Process
Rational Software Foi uma empresa fundada em 1981 para prover ferramentas para o desenvolvimento da engenharia de software (principalmente o desenvolvimento modular e interativo). Lançado em 1985 o ambiente Rational era uma IDE para ADA. Posteriormente a empresa mudou de nome de Rational Machines para Rational Software Corporation e fundiu-se com a Verdix Corporation. Na época ela fornecia geradores de código de compiladores e debuggers para várias arquiteturas. Em 1990 a Rational lançou o ambiente Rational para ADA para rodam em estações Unix da Sun e IBM e uma ferramenta de modelagem chamada Rose desenvolvida por Grady Booch. A Rose versão 1.0 foi lançada em 1992, mas devido a baixa performance foi retirada do mercado. A Rose 2.0 foi combinada com a notação Booch e lançada para a plataforma Windows, incluindo a geração de código.
Rational Software Após a fusão da Rational com a Verdix o que formalizou o nome da empresa em Rational Software. Em 1995, James Rumbaugh entrou na empresa e Ivar Jacobson com sua empresa Objectory AB, na época Grady Booch já estava na empresa, desta forma os 3 maiores metodologias da engenharia de software orientado a objetos estavam na Rational. A principal missão deles foi eliminar a fragmentação dos métodos, então os três desenvolveram a Linguagem de Modelagem Unificada UML. Este esforço os denominou de os três amigos na indústria de software. Philippe Kruchten teve a tarefa de explicitar um framework para suportar a engenharia de software com a utilização de UML, o que resultou no Rational Unified Process completando gerando um tripé estratégico: A) um processo que guia o desenvolvimento B) ferramentas que automatiza o processo C) serviços que aceleram a adoção de ambos: processos e ferramentas
Rational Software Em 6 de dezembro de 2002 a IBM adquiriu a Rational. Algumas ferramentas da Rational: 1. Rational Application Developer para desenvolvimento de software com Java 2. Rational ClearCase ferramenta para suportar o gerenciamento de configuração, controle de versão e gerenciamento de código fonte. 3. Rational Rose Modelagem UML 4. Rational Quality Manager Gerenciamento colaborativo do ciclo de vida da aplicação e ambiente de teste
Iterativo x interativo Iteração é um ciclo ou uma etapa de uma repetição maior. Interação é uma comunicação bidirecional mútua entre as partes. Fonte: https://www.ime.usp.br/~pf/algoritmos/aulas/footnotes/interativo.html
Iterativo Iterativo é um termo que anda sempre com o termo incremental, isto pode ser visto em vários processos de desenvolvimento de software. As iterações e incrementos são executadas no ciclo de desenvolvimento em mais de uma etapa e podem ser executadas ao mesmo tempo durante o ciclo. A combinação de iteração e incrementes tornam os processos evolucionários e fornecem construções incrementais. O relacionamento entre iterações e incrementas estão entre todos as metodologias de desenvolvimento de software ou processos de software.
Requisitos Modelo Iterativo Planejamento Análise e projeto Evolução Implementação Testes Deploy (implantação/entrega)
RUP Significa Rational Unified Process (processo unificado Rational), criado pela Rational Software Corporation. E desde fevereiro de 2003 pertence a IBM. O produto da IBM fornece uma base de conhecimento com artefatos de modelo e descrições detalhadas para muitos tipos diferentes de atividades. Os pilares da RUP: Um processo flexível que guie o desenvolvimento. Ferramentas que automatizem esse processo. Serviços que acelerem a adoção destes processos e ferramentas. Blocos de construção são também chamados de elementos de conteúdo. Linhas mestras: Gestão de requisitos Uso de arquitetura baseada em componentes Uso de software de modelos visuais Verificação da qualidade do software Gestão e Controle de Mudanças do Software Foco nos 4 P: Pessoas, Projeto, Produto, Processos
RUP O método RUP popularizou 6 melhores práticas para a engenharia de software moderna: 1. Desenvolvimento iterativo 2. Gerenciamento de requisitos 3. Uso de uma arquitetura de componentes 4. Modelagem de software de forma visual 5. Verificar a qualidade continuamente 6. Controlar mudanças Blocos de construção: O RUP tem blocos de construção e elementos de conteúdo os quais descrevem o que é produzido: 1. Papeis (who quem): define habilidades e responsabilidades 2. Produtos de trabalho (O que - what): O produto de um trabalho é o resultado de uma tarefa, incluindo documentação, modelos, códigos, pacotes de software, etc. 3. Tasks (como - how): Descreve uma unidade de trabalho que atribuída a um papel provê um resultado significativo.
RUP Seis disciplinas de engenharia: 1. modelagem de negócios 2. Requisitos 3. Análise de projeto 4. Implementação 5. Testes 6. Deploy/entrega Disciplinas de suporte: 1. Gerenciamento da configuração e mudança 2. Gerenciamento de projetos 3. Gerenciamento de ambiente
Gráfico resumo do RUP mostrando fases e disciplinas Fases Disciplinas
Gráfico resumo do RUP mostrando fases e disciplinas O objetivo primário desta fase é traduzir o escopo do sistema como uma sustentação para a avaliação e validação de custos e orçamentos do projeto. Aqui o contexto do negócio, fatores de sucesso (entre eles expectativa de receita, reconhecimento do mercado, etc), previsão financeira entre outros é levantado. São criados casos de uso para representar o entendimento do negócio, o plano de projeto, avaliação de risco e descrição do projeto (os requisitos principais, restrições e características chave) Depois destas etapas o projeto é confrontado contra os seguintes critérios: 1. Concordância entre o patrocinadores do projeto quando ao escopo e estimativa de custo e cronograma 2. Compreensão dos requisitos e se são fidedignos os casos de uso primários 3. Veracidade do orçamento e custo 4. Revisão da avaliação de risco 5. Criar uma forma de comparação entre o orçamento real e orçamento planejado Se o projeto não passar por esta fase é cancelado ou repetido.
Gráfico resumo do RUP mostrando fases e disciplinas 1. Migrar principais itens de risco identificado na fase anterior e leva-lo até final da presente fase. 2. Criar o projeto técnico. Aqui são criados: 1. Modelo de casos de uso no qual os atores são identificados, a maioria dos casos de uso são descritos. Os casos de uso deve ser completados em 80%. 2. Descreve-se a arquitetura do software em um processo de software. 3. Todas listas de casos de negócio são listados. 4. É criado um plano de desenvolvimento global para o projeto. 5. É criado um protótipo para que cada caso de risco seja mitigado. 6. É opcional o desenvolvimento de manuais. Nesta fase devem ser respondidas as seguintes perguntas: O produto é viável? A arquitetura é estável? A demonstração executável demonstra que os riscos são abordados e resolvidos? O plano de construção é detalhado? Todos os stakeholders concordam com a visão do que será entregue? É aceitável a despesa x recursos alocados?
Gráfico resumo do RUP mostrando fases e disciplinas 1. Construção do software. 2. Desenvolvimento de componentes. 3. Dividir casos de uso em segmentos que produzem protótipos comprováveis.
Gráfico resumo do RUP mostrando fases e disciplinas É a fase que colocar o produto do ambiente de homologação e teste para o ambiente real de produção do usuário. Treinar usuários, administradores do sistema. Validar testes beta com os clientes e usuários. Verificações de qualidades são realizadas durante todo o processo.
Gráfico resumo do RUP mostrando fases e disciplinas Uma corcova é um esforço maior ao longo do tempo em uma determinada disciplina do processo RUP. Neste diagrama existem várias corcovas ou corcundas que mostrar os locais nas disciplinas onde OCORRE MAIOR ESFORÇO. Este diagrama foi desenvolvido em 1993 e finalmente publicado em 1998 na sua versão final. Ao longo dos anos este diagrama foi tão largamente utilizado que é algumas vezes tido como logo do RUP.
+ conceitos sobre Processos de software AUP OUP
ASD - Desenvolvimento de software ágil São princípios de desenvolvimento nos quais os requisitos e a solução evoluem através esforço colaborativo de equipes multi funcionais. Estes processo incentivam o uso de planejamento evolucionário, desenvolvimento evolucionário e entrega o mais cedo possível bem como a resposta rápida a mudanças além da contínua evolução. O termo Agile foi cunhado pela primeira vez em 2001 no Manifesto for Agile Software Development
Nomenclatura que unificou todos RAD 1991 Processo Unificado 1994 SCRUM 1995 Cristal Clear e XP 1996 Feature-Driven 1997 Entre outros o manifesto Agile de 2001 colocou todos sob o mesmo guarda chuva!
4 pilares do manifesto: 1. Indivíduos e interações Auto-organização e motivação são importantes, assim como iterações e programação de pares. 2. Software funcionando Software funcionando (rodando) é mais útil e bem-vindo do que apenas apresentar documentos aos clientes em reuniões. 3. Colaboração com o cliente Os requisitos não podem ser totalmente coletados no início do ciclo de desenvolvimento de software, portanto, o envolvimento contínuo com os clientes ou partes interessadas é muito importante. 4. Respondendo à mudança Métodos ágeis são focados em respostas rápidas à mudança e desenvolvimento contínuo.
12 princípios: 1. Satisfação do cliente pela entrega precoce e contínua de software 2. Bons requisitos, mesmo em desenvolvimento tardio 3. Software em funcionamento (pronto para rodar) é entregue com freqüência (semanas, em vez de meses) 4. Cooperação estreita e diária entre empresários e desenvolvedores 5. Os projetos são construídos em torno de indivíduos motivados, que devem ser confiáveis 6. A conversa cara-a-cara é a melhor forma de comunicação 7. O software funcionando é a principal medida do progresso 8. Desenvolvimento sustentável, capaz de manter um ritmo constante 9. Atenção contínua à excelência técnica e ao bom design/projeto 10. Simplicidade é essencial 11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas 12. Regularmente, a equipe reflete sobre como tornar-se mais eficaz, e se ajusta conforme a necessidade
Exemplos de processos ágeis Adaptive software development (ASD) Agile modeling Agile Unified Process (AUP) Crystal Clear methods Disciplined agile delivery Dynamic systems development method (DSDM) Extreme programming (XP) Feature-driven development (FDD) Lean software development Kanban Scrum Scrumban Rapid application development
Agile Unified Process É uma simplificação do RUP desenvolvida por Scott Ambler. Ela descreve de forma simples de fácil de entender a abordagem de desenvolver sistemas de negócios usando técnicas ágeis e conceitos da RUP. A AUP aplica técnicas ágeis como: TDD e modelagem ágil, gerenciamento de mudanças e refatoração do banco de dados para aumentar a produtividade. Possui 11 disciplinas: 1. Modelo 2. Implementação 3. Teste 4. Deploy 5. Gerenciamento da configuração 6. Gerenciamento de projeto 7. Ambiente (ferramentas, hardware, etc é fornecido corretamente a equipe)
Agile Unified Process Filosofias AUP: 1. Sua equipe sabe o que eles estão fazendo 2. Simplicidade 3. Agilidade 4. Foco nas atividades de alto valor 5. independência de ferramentas 6. Você pode alterar a AUP para suas necessidades
OpenUP É parte do Eclipse Process Framework, um processo aberto desenvolvido pela Eclipse Foundation. Seu objetivo é facilitar a adoção de básico e principal do RUP. Tudo o que é opcional no RUP foi removido do processo, como objetivo de simplificar o processo, incluindo equipes de pessoas o qual é recomendado de 3 a 6 por equipes.