Rational Unified Process (RUP)

1.923 visualizações

Publicada em

Rational Unified Process (RUP)

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.923
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
109
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Rational Unified Process (RUP)

  1. 1. Carlos Henrique M. da Silva carloshenrique.85@globo.com
  2. 2. 1. Histórico e Conceitos 2. Melhores práticas 3. Fases 4. Disciplinas
  3. 3. O RUP, Processo Unificado Racional é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento. O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.
  4. 4. O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites". Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiado por Funcionalidades) entre outros. Objetivo é assegurar a produção de software de alta qualidade dentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)
  5. 5. O RUP define perfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para que sejam alcançadas. Oferece uma abordagem organizada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.
  6. 6. Melhores Práticas  Desenvolver software iterativamente  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
  7. 7. Desenvolver Software Iterativamente Desenvolver iterativamente significa desenvolver em ciclos. Cada ciclo é contém um objetivo que deve ser alcançado (lançamento de um pré release ou beta, correção de um bug, etc.) Esta prática acaba dando ao RUP uma série de vantagens, como:  Possibilidade de identificar/modificar requerimentos com mais facilidade;  Integração progressiva (quase continua) de elementos ao software, ocasionando uma melhora no descobrimento e endereçamento de riscos;  Desenvolvimento iterativo provê aos gerentes maneiras de fazer mudanças táticas aos produtos; etc.
  8. 8. Gestão de Requisitos O gerenciamento de recursos acarreta um melhor controle sobre projetos complexos, além de maior qualidade e redução de custos. O RUP é uma metodologia dirigida-a-casos-de-uso (use- drivencase), de modo que é possível utilizar os mesmos casos de uso definidos no sistema como base para o resto do processo. Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.
  9. 9. Arquitetura Baseada em Componentes Um componente normalmente se relaciona com um objeto na programação orientada a objetos. O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala. Estes componentes são normalmente incluídos em infraestruturas existentes como o CORBA e o COM (Modelo de Componentes de Objetos).
  10. 10. Uso de Software de Modelos Visuais A modelagem visual permite melhor entender não só a concepção e a complexidade do sistema, mas também “dimensionar” (no sentido de qual a forma do sistema), além de facilitar a identificação e solução de problemas.
  11. 11. Verificação da qualidade do software Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa- se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento. O RUP não toma a qualidade como responsabilidade de apenas uma pessoa ou grupo, mas como uma responsabilidade de todos os integrantes do projeto. A qualidade é focada especialmente em duas áreas:  Qualidade de produto: Sendo desenvolvido (software ou sistema) e todos as partes envolvidas (componentes, subsistemas, arquitetura).  Qualidade de processo: Dentro do projeto de desenvolvimento.
  12. 12. Gestão e Controle de Mudanças do Software Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um projeto. O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.
  13. 13. Fases de Desenvolvimento Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projeto. As fases indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro fases diferentes: 1. Concepção: ênfase no escopo do sistema; 2. Elaboração: ênfase na arquitetura; 3. Construção: ênfase no desenvolvimento; 4. Transição: ênfase na implantação.
  14. 14. Fases de Desenvolvimento O RUP também se baseia nos 4 Ps: 1. Pessoas 2. Projeto 3. Produto 4. Processo As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido enquanto as fases são objetivas. Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de permitir melhor acompanhamento.
  15. 15. Fase de Concepção Esta fase do RUP abrange as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá- lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.
  16. 16. Fase de Elaboração Abrange a Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?” são esclarecidas nesta etapa.
  17. 17. Fase de Construção Desenvolve ou Adquire os componentes de Software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. É na fase de Construção que a maior parte de codificação ocorre.
  18. 18. Fase de Transição Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.
  19. 19. Disciplinas As disciplinas descrevem o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo. São divididas em:  Seis Disciplinas de Engenharia  Modelagem de Negócios  Requisitos  Análise e Projeto ("Design")  Implementação  Teste  Implantação  Três Disciplinas de Apoio/Suporte  Ambiente  Configuração e Gerência de Mudança  Gerência de Projeto
  20. 20. Engenharia - Disciplina de Modelagem de Negócios Modelagem de negócios, explica como descrever uma visão da organização na qual o sistema será implantado e como usar esta visão como uma base para descrever o processo, papéis e responsabilidades. O objetivo de modelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal de comunicação entre engenharia de negócios e engenharia de software. Compreender o negócio significa que os engenheiros de software devem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais problemas na organização e possíveis melhorias.
  21. 21. Engenharia - Disciplina de Requisitos Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitos detalhados para o que deve fazer o sistema.
  22. 22. Engenharia - Disciplina de Análise e Projeto (“Design”) O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é construir um sistema que:  Execute as tarefas e funções especificadas nas descrições;  Cumpra todas as suas necessidades;  Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais.
  23. 23. Engenharia - Disciplina de Implementação Os efeitos da implementação são:  Para definir a organização do código, em termos de subsistemas de implementação organizadas em camadas  Para implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)  Para testar os componentes desenvolvidos como unidades  Integrar os resultados produzidos por implementadores individuais (ou equipes), em um sistema executável
  24. 24. Engenharia - Disciplina de Teste As finalidades da disciplina de teste são:  Verificar a interação entre objetos  Verificar a integração adequada dos componentes do software  Verificar se todos os requisitos foram corretamente implementados  Identificar e garantir que os defeitos são abordados antes da implantação do software  Garantir que todos os defeitos são corrigidos, reanalisados e fechados O RUP propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Os testes são realizados ao longo de 4 dimensões da qualidade: Confiabilidade, Funcionalidade, Desempenho da aplicação, e o Desempenho do sistema.
  25. 25. Engenharia - Disciplina de Implantação O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de ajuda e assistência aos usuários. Embora as atividades de implantação estejam principalmente centradas em torno da fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação, no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menos detalhes do que outros workflows.
  26. 26. Apoio/Suporte - Disciplina de Ambiente O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele descreve as atividades necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente é prover à organização de desenvolvimento de software os processos e as ferramentas que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não entendem que o RUP é um framework de processo, eles podem percebê-lo como um processo pesado e caro.
  27. 27. Apoio/Suporte - Disciplina de Configuração e Gerência de Mudança A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos específicos: de configuração, de solicitações de mudança, e de status e medição. A Rational também tem um produto para manter as solicitações de mudança chamado ClearQuest.
  28. 28. Apoio/Suporte - Disciplina de Gerência de Projeto Esta disciplina concentra-se principalmente sobre os aspectos importantes de um processo de desenvolvimento iterativo: Gestão de riscos; Planejamento de um projeto iterativo através do ciclo de vida e para uma iteração particular; E o processo de acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de projetos. Por exemplo, não abrange questões como:  Gestão de Pessoas: contratação, treinamento, etc.  Orçamento Geral: definição, alocação, etc.  Gestão de Contratos: com fornecedores, clientes, etc.
  29. 29. Embora o RUP não seja um processo adequado a todos os tipos de desenvolvimento de software, ele representa uma nova geração de processos genéricos. A mais importante inovação é a separação de fases e workflows, e o reconhecimento de que a implantação de software no ambiente do usuário é parte do processo. As fases são dinâmicas e tem objetivos. Os workflows são estáticos e constituem atividades técnicas que não estão associadas a uma única fase, mas podem ser utilizados ao longo do desenvolvimento para atingir os objetivos de cada fase (Sommerville 2007, pág. 56). Conclusão
  30. 30. Rational Unified Process
  31. 31. DISCIPLINAS Vamos agorar conhecer um pouco mais sobre as 6 disciplinas de engenharia do RUP: Modelagem de Negócios Requisitos Análise e Projeto ("Design") Implementação Teste Implantação
  32. 32. DISCIPLINA DE MODELAGEM DE NEGÓCIOS
  33. 33. Modelagem de Negócios É uma das 9 disciplinas do RUP e a primeira das 6 consideradas “core disciplines”. Dentro do ciclo de desenvolvimento de software podemos dizer que essa é sem dúvida a disciplina menos praticada. RUP não define esta como uma disciplina obrigatória, mas recomenda fortemente que ela seja executada especialmente para empresas que estão iniciando um novo negócio e não possuam uma clara modelagem do negócio.
  34. 34. Modelagem de Negócios Finalidades:  Entender os problemas da organização identificando as possíveis melhorias;  Avaliar o impacto de mudanças na organização;  Assegurar que os clientes, usuários, desenvolvedores e outros parceiros tenham uma compreensão comum da organização;  Gerar conteúdo para a fase de requisitos do sistema que suportará a organização e seus processos;  Entender como o software se ajustará à organização.
  35. 35. Modelagem de Negócios Papéis e Artefatos A importância da definição de papéisnão é somente para melhorar divisão do trabalho, mas principalmente para que hajana equipe responsabilidades definidas para cada atividade realizada, fazendo, assim,com que os membros tenham que cumprir direitinho as suas tarefas e que respondam por elas.  Gerente de Projeto  Analista de Processos de Negócio (Dentro da disciplina de Modelagem de Negócios, esse é o papel mais importante)  Designer de Negócio
  36. 36. Gerente de Projeto Talvez seja um dos únicos papéis que estarão presentes em todos os projetos e em todas as suas fases, independente do tamanho, natureza ou metodologia de desenvolvimento adotada. Inicialmente, o gerente de projeto era o indivíduo que identificava as tarefas necessárias, as delegava aos membros da equipe e ficava pressionando cada um para cumprir os prazos. Hoje, essa realidade mudou. O gerente de projeto é um indivíduo extremamente participativo: realiza parcerias com os membros da equipe, estimula e valoriza as soluções encontradas e conduz o andamento do projeto, protegendo a equipe de distrações e organizando cronogramas, defende os interesses do time e realiza a comunicação com o cliente. Modelagem de Negócios
  37. 37. Analista de Processos de Negócio Modelagem de Negócios
  38. 38. Designer de Negócios Modelagem de Negócios
  39. 39. Modelagem de Negócios Relação com Outras Disciplinas A disciplina Requisitos utiliza modelos de negócios como um importante subsídio para entender os requisitos do sistema. A disciplina Análise e Design utiliza entidades de negócios como subsídio para identificar classes de entidade no modelo de design. A disciplina Ambiente desenvolve e mantém artefatos de suporte, como o Guia de Modelagem de Negócios.
  40. 40. DISCIPLINA DE REQUISITOS
  41. 41. O objetivo da disciplina Requisitos é descrever o que o sistema deve fazer e permite que desenvolvedores e clientes concordem com essa descrição. Para conseguir isso, obter, organizar e funcionalidade documento desejado e restrições; acompanhar e documentar compromissos e decisões. Uma visão do documento é criada, e necessidades das partes interessadas são extraídas. Atores e casos de uso são identificados. REQUISITOS
  42. 42. O QUE É UM REQUISITO?  Condição ou capacidade que um sistema deve desempenhar  Qualidade de software  Funcionalidade: requisitos funcionais  Requisitos não funcionais  Usabilidade  Confiabilidade  Performance  Suportabilidade – manutenabilidade
  43. 43. TIPOS DE REQUISITOS  Serviços (features)  Expressões de comportamento do sistema em alto nível (o quê)  Solicitações dos stakeholders  Requisitos do software  Requisitos de casos de usos
  44. 44. Processo de levantamento de requisitos proposto pelo RUP (José Martins, 2004) REQUISITOS
  45. 45. ATIVIDADES
  46. 46. ARTEFATOS
  47. 47. ENGENHARIA DE REQUISITOS É fundamental para o desenvolvimento de um software a compreensão dos requisitos. Se a análise e a especificação das funções não forem definidas adequadamente o software não atenderá as necessidades do usuário. A Engenharia de Requisito tem como objetivo a elaboração de um documento com as características do sistema. Este documento serve de referência para todas as pessoas envolvidas no processo de desenvolvimento inclusive os clientes. Com a chegada da engenharia de requisitos, se fez necessário à elaboração de um processo visando organizar as atividades. É o que analisaremos nos tópicos abaixo.
  48. 48. Processo de Engenharia de Requisitos O processo de Engenharia de Requisitos é um conjunto de atividades a serem seguidas para desenvolver um documento de requisitos. Sommerville sugere um modelo de atividades que pode descrever a maioria dos processos de Engenharia de Requisitos. As atividades nem sempre ocorrem sequencialmente, em geral realizam varias repetições ou são executadas paralelamente.  Elicitação  Análise e Negociação  Especificação  Validação
  49. 49. Processo de Engenharia de Requisitos
  50. 50. Elicitação dos Requisitos O objetivo é obter conhecimentos relevantes do problema a ser resolvido. Segundo Kotonya e Sommerville existem 4 dimensões na atividade de elicitação de requisitos:  Entendimento do domínio da aplicação – entendes-e a área na qual o sistema será aplicado;  Entendimento do problema – com auxilio do sistema a ser resolvido, entende-se os detalhes do problema especifico a ser resolvido;  Entendimento do negócio – entende-se qual a contribuição do sistema para que sejam atingidos os objetivos gerais da organização;  Entendimento das necessidades e das restrições dos stakeholders – entende-se detalhadamente: as necessidades de apoio a serem providas pelo sistema à realização do trabalho e aos interesses de cada um dos stakeholders; os trabalhos a serem apoiados pelo sistema e; o papel de eventuais sistemas existentes na execução e condução dos processos de trabalho.
  51. 51. Análise e Negociação dos Requisitos Depois da elicitação de requisitos todo esse conhecimento adquirido pelos stakeholders precisa ser representado através de notações diversas. Essas representações precisam estar sempre consistentes. Negociação de requisitos é uma atividade extremamente complexa, ter um entendimento global de todos os objetivos, soluções e interação entre eles é uma tarefa muito difícil de executar. Assim existem diferentes métodos e técnicas de negociação. Robinson estabelece uma infraestrutura para modelar o processo de negociação:  Perspectivas de negociação  Processos de negociação  Produtos da negociação
  52. 52. Especificação dos Requisitos Após serem identificados e analisados os requisitos devem ser documentados para que possam servir de base para o resto do processo. Administrar o volume de informações que são gerados pelo processo de engenharia de requisitos é um dos principais problemas que se enfrenta na documentação de requisitos. Para se tornar um pouco mais fácil a administração desse documento usa-se uma notação gráfica que diminui o tamanho do modelo. Cada engenheiro de requisitos usa um modelo para fazer sua documentação. A seguir são mostrados três modelos de documentos que são encontrados na literatura: Modelo 1 – Roger S. Pressman Modelo 2 – RUP (Rational Unified Process) Modelo 3 – Wilson de Pádua Filho
  53. 53. Validação dos Requisitos Esta atividade acontece no final da especificação de requisitos e seu objetivo é verificar se a documentação dos requisitos esta consistente e se contem todas as necessidades dos usuários. A revisão é uma das técnicas usadas para validar os requisitos. Uma das maneiras para essa tarefa é utilizar um relatório de revisão. Um grande desafio para a validação de requisitos é mostrar que a especificação de requisitos está correta, pois não existe uma forma para isso.
  54. 54. GERENCIAMENTO DE REQUISITOS Gerenciamento de requisitos trata-se de um modelo sistemático pra identificar, organizar e documentar os requisitos do sistema, estabelecer e manter acordo entre o cliente e a equipe do projeto nos requisitos variáveis do sistema. Para ter um gerenciamento eficiente de requisitos é preciso:  Manter uma declaração de requisitos clara;  Atributos aplicáveis a cada tipo de requisito e;  Rastreabilidade para outros requisitos e outros artefatos do projeto.
  55. 55. GERENCIAMENTO DE REQUISITOS Existem requisitos funcionais e não-funcionais. Exemplos:  Funcional: o usuário deve selecionar a opção de inclusão para cadastrar um novo aluno no banco de dados.  Não-funcional: o sistema deve ser compatível com as plataformas Windows e Linux.  Não-funcional: o sistema deverá ser desenvolvido em Java. É natural que alguns requisitos possam não ser definidos corretamente no início do projeto, para isso serão necessárias várias revisões periódicas, a fim de detectar erros o mais cedo possível e corrigi-los logo em seguida.
  56. 56. DISCIPLINA DE ANÁLISE E PROJETO ("DESIGN")
  57. 57.  Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso em mãos.  Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso.  Este é chamado de modelo de análise.
  58. 58. Requisitos Análise Projeto
  59. 59.  Vai proporcionar um método que permita que criemos um modelo de classes do sistema a partir dos casos de uso  Trará a resposta para a pergunta: ◦ Quais classes preciso para implementar estes casos de uso?
  60. 60. casos de uso análise Descritos na linguagem do cliente Descrito na linguagem dos desenvolvedores Visão externa do sistema Visão interna do sistema Captura as funcionalidades do sistema Mostra, de modo abstrato, como a funcionalidade pode ser realizada Estruturado por casos de uso Estruturado por classes e pacotes
  61. 61.  O modelo de análise e projeto contém as realizações de casos de uso  Pode ser particionado em dois modelos ◦ Modelo de Analise ◦ Modelo de Projeto
  62. 62. Diagramas de ClasseDiagramas de Classe Realização de Caso de Uso Caso de Uso Diagramas de ColaboraçãoDiagramas de Colaboração Diagramas de SequênciaDiagramas de Sequência Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto  Requisitos   Analise e projeto 
  63. 63. MDS - Bacalá Diagrama de Atividades
  64. 64. 1. Analisar Arquitetura 2. Analisar Caso de Uso 3. Projetar Classes 4. Projetar Banco de Dados
  65. 65. Interface Gráfica Negócio Dados Módulo de Vendas Módulo de Estoque Socket
  66. 66. Para cada caso de uso  Identificar as classes de análise • Classes de fronteira • Classes de controle • Classes de entidade Para cada classe  Identificar responsabilidades das classes  Identificar relacionamentos  Identificar atributos
  67. 67. Para cada classe 1. Criar classes de projeto 2. Identificar classes persistentes 3. Definir métodos 4. Definir atributos 5. Definir estados 6. Definir relacionamentos 7. Contemplar os requisitos não-funcionais
  68. 68.  Mapear as classes persistentes em conceitos do Banco de Dados  Definir os tipos de dados mais adequados para o Banco de Dados  Normalizar se necessário
  69. 69. DISCIPLINA DE IMPLEMENTAÇÃO
  70. 70. Disciplina de Implementação OBJETIVOS  Definir a organização do código em termos de subsistemas de implementação organizados em camadas  Implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)  Testar os componentes desenvolvidos como unidades  Integrar os resultados produzidos por implementadores individuais (ou equipes) ao sistema executável
  71. 71. Modelo de projeto Modelo de dados Implementação Documento da arquitetura Modelo de implementação Componentes Plano de Integração Documento da arquitetura
  72. 72. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  73. 73.  Identificar quais componentes participam da iteração (colaboram para os casos de uso da iteração) : C lie n t e C o n t ro la d o r C lie n t e M a q u in a D in h e iro B a n c oLe it o ra C a rt a o C lie n t eF o rm u la rio S a q u e in s e re c a rt a o in ic ia r s e s s a o (d a d o s c a rt a o ) s oli ci t a s e nh a s o lic it a s e n h a e n t ra s e n h a e n t ra s e n h a n e w C lie n t e (d a d o s c a rt a o , s e n h a ) v e rif ic a s e n h a so lic it a v a lo r s o lic it a v a lo r e n t ra v a lo r e n t ra v a lo r v e rif ic a s a ld o (v a lo r) s o lic it a d e b it o (v a lo r) s ol ici t a d e v ol uc a o c art a o s o lic it a e n t re g a d in h e iro c a rt a o d in h e iro
  74. 74.  Identificar quais pacotes participam da iteração (colaboram para os casos de uso da iteração) Applicação Negócio Middleware Básico * * * * * Candidatos a Stubs x x
  75. 75. Aplicação Comunicação Negócio Dados 3 Stubs2 2 1 1 aa bb cc dd ee gg ff hh ii jj  Definir os builds que serão gerados
  76. 76.  Avaliar resultados ◦ A ordem de integração reduz a necessidade de criação de stubs? ◦ A ordem de integração facilita a detecção de erros?
  77. 77. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  78. 78.  Modelo de Implementação ◦ Modelo de projeto gerado a partir da engenharia reversa do código fonte do sistema
  79. 79. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  80. 80.  Check-out dos componentes  Implementar ◦ Operações ◦ Inicialização dos atributos ◦ Estados  Comentar o código implementado ◦ Seguindo um padrão de codificação
  81. 81.  Avaliar o código implementado ◦ Padrão de codificação ◦ Fatores de qualidade de OO e Java  Compilar o código implementado ◦ Com a última versão estável dos componentes auxiliares ◦ Com a versão mais recente dos componentes implementados  Check-in dos componentes
  82. 82. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  83. 83.  Check-out dos componentes  Estabilizar a ocorrência do defeito ◦ Identificar casos de teste mínimos que causam o defeito  Localizar o defeito no código ◦ Isolado do ambiente de produção ◦ Com ferramenta de depuração ◦ Comentando trechos do código ◦ Criando stubs  Corrigir o defeito no código  Check-in dos componentes
  84. 84. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  85. 85.  Implementar componentes de teste ◦ Separados dos componentes a serem testados ◦ Usando ferramenta para geração dos componentes de teste  Ex: Junit ◦ Aproveitando componentes implementados anteriormente (Check-out)  Check-in dos componentes de teste  Executar testes e avaliar resultados
  86. 86. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  87. 87.  Revisar código ◦ Com base nos seguintes documentos:  Padrão de codificação  Fatores de qualidade de OO e Java ◦ Sem verificar se casos de uso foram corretamente implementados ◦ Função corretiva, mas também educativa  Passar mudanças para o programador responsável
  88. 88. Estruturar Modelo de Implementação Revisor de Código Programador Integrador do Sistema e Subsistemas Planejar Integração Integrar Sistema e Subsistemas Implementar Componentes Corrigir Defeitos Realizar Testes de Unidade Revisar Código Fonte
  89. 89.  Check-out de todos os componentes do repositório principal  Integrar componentes em um build  Notificar responsável pelos defeitos  Criar tag (identificador) para o build  Divulgar o build  Check-in dos componentes
  90. 90. DISCIPLINA DE TESTE
  91. 91. Fluxo de Trabalho
  92. 92. Papéis e Atividades
  93. 93. Papéis e Artefatos
  94. 94. DISCIPLINA DE IMPLANTAÇÃO
  95. 95. Finalidade: Descrever as atividades que garantam que o produto de software será disponibilizado a seus usuários finais. Disciplina de Implantação Esta Disciplina descreve três modos de implantação de produto:  A instalação personalizada  O produto em uma forma "compacta"  Acesso ao software por meio da Internet Em cada instância, a ênfase é testar o produto no local de desenvolvimento, seguido de testes beta, antes de ele ser finalmente oferecido ao cliente.
  96. 96. Fluxo de Trabalho
  97. 97. Atividades
  98. 98. Os papéis envolvidos e os artefatos produzidos na disciplina Implantação.
  99. 99.  Formado em Análise de Sistemas  Pós-Graduado em Auditoria em T.I.  Gerente de TI da CLIOC – Coleção de Leishmania do Instituto Oswaldo Cruz – Fiocruz  Certificado em Gestão de Segurança da Informação e Gerenciamento de T.I. pela Academia Latino-Americana (Microsoft TechNet / Módulo Security) Carlos Henrique M. da Silva carloshenrique.85@globo.com

×