Rational Unified Process

Transcrição

1 Rational Unified Process Engenharia de Software Bruno Braun Fernando Coelho Jonatas Teixeira Vinicius Massuchetto

2 Sobre o RUP Metodologia proprietária de desenvolvimento de software Iterativo e incremental Adquirido pela IBM, tendo o nome convertido para IRUP Compõe o produto RMC (Rational Method Composer) da IBM, um pacote de desenvolvimento para o Eclipse Voltado principalmente para a gerência de grandes equipes Cleanroom, Scrum e FDD são métodos concorrentes

3 Principais Características Gerenciamento de requisitos Arquitetura de componentes Modelos visuais Verificação de qualidade Controle de mudanças

4 Gerenciamento de Requisitos Padronização da documentação. Orientação sobre como descrever: Funcionalidades Restrições de sistema Restrições de projeto Requisitos de negócio Forte direção dos processos pelos casos de uso e pelos cenários de utilização

5 Arquitetura Baseada em Componentes Implementação parcial para demonstrar determinadas funções e propriedades Objetivo é tornar o sistema facilmente extensível Promoção da reutilização de código Entendimento intuitivo da complexidade do sistema Arquitetura executável logo nas fases iniciais do projeto, isolando testes, procedimentos, e evitando o comprometimento de funcionalidades mais amplas Integração gradativa dos componentes com o amadurecimento do projeto

6 Utilização de Modelos Visuais Representação do desenvolvimento em blocos gráficos Entendimento do sistema por pessoas que não possuem um perfil estritamente técnico Formalização e comunicação das decisões de projeto Facilita a obtenção dos requisitos Uso da UML e orientação a objetos

7 Verificação de Qualidade Verificação contínua da qualidade logo nas fases iniciais de implementação Carga de verificação aumenta com o amadurecimento do projeto, mas deve haver um esforço para torná-la constante durante todo o processo de criação do software

8 Controle de Mudanças Em todos os projetos de software a existência de mudanças é inevitável Define métodos para controlar e monitorar mudanças Define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema

9 Iterações Cada iteração resulta em um incremento ao produto Análises modulares de grupos de casos de uso e suas variantes As iterações consistem na passagem por todos os workflows técnicos, cada qual com a sua importância em uma dada iteração

10 Ciclo de Vida Principais fases: Concepção Elaboração Construção Transição

11 Concepção Contém os workflows necessários para que os stakeholders concordem e aprovem o projeto Pode ser feito um protótipo para que o cliente possa aprovar Requisitos essenciais do sistema são transformados em casos de uso Definir riscos e custos

12 Elaboração Complemento de levantamentos, documentação dos casos de uso Revisar modelagem do negócio para os projetos Prova de que a arquitetura se aplica Produção de um protótipo Deve-se aceitar: Visão geral do produto (incremento + integração) Estabilidade Se o plano é confiável Se custos são admissíveis

13 Construção Começa o desenvolvimento do software Além de código, os testes (alfa, beta) Construção é a fase mais longa do projeto Casos de uso mais críticos recebem prioridade As funcionalidades dos sistemas são implementados em curtas iterações Cada iteração resulta em um versão funcional do software

14 Transição Realizada a entrega ("deployment") do software: Implantação e entrega Acompanhamento Qualidade do software Capacitação de usuários

15 Ciclo de Vida

16 Disciplinas Agrupamento dos workflows em atividades correlatas Engenharia Suporte

17

18 Conclusão: Vantagens Grandes riscos são identificados mais cedo Mudanças são facilitadas devido à característica de componentes dos projetos Alto nível de reutilização de código em tecnologias formais e com bagagem de desenvolvimento Aprendizado da equipe em relação ao projeto de acordo com a evolução dos trabalhos Resulta em um produto com melhor qualidade

19 Conclusão: Desvantagens Modelo proprietário É exigida uma alta qualificação técnica dos profissionais envolvidos em suas áreas Integração dos componentes nem sempre é possível da maneira como o método especifica A reutilização de código não é algo plausível em tecnologias novas, assim não há aproveitamento de tempo no nível esperado. Exemplo: dispositivos com poucos recursos ou novas linguagens de programação

20 Obrigado!

21 Referências El Processo Unificado de Desarrollo de Software Introdução ao RUP Melhor Prática: Use Arquiteturas de Componentes Rational Unified Process: Best Practices for Software Development Teams com/developerworks/rational/library/content/03july/1000/1251/1251_bestpractices_t P026B.pdf The Advantages and Disadvantages / Best Practices of RUP Software Development Visão geral do RUP Wikipedia:IBM Rational Unified Process