Metodologia de Desenvolvimento de Software – RUP Apresentação & Introdução

1. Metodologia de Desenvolvimento de Software – RUPApresentação & Introdução Márcio Aurélio Ribeiro Moreira marcio.moreira@pitagoras.com.br http://si.lopesgazzani.com.br/docentes/marcio/

2. Apresentação da Disciplina

3. Apresentação da disciplina • Objetivos da disciplina: • Introduzir os conceitos relacionados ao RUP • Apresentar as Fases, Iterações e Disciplinas do RUP • Apresentar práticas relacionadas ao RUP • Apresentar o material disponível do RUP • Relacionar os fatores críticos de sucesso da Engenharia de Software • Discutir as habilidades e competências do Engenheiro de Software

4. Ementa da disciplina • Apresentação e Introdução • 1. Modelagem de Negócios • 2. Requisitos • 3. Análise & Projeto • 4. Implementação • 5. Testes • 6. Distribuição • 7. Gestão de Configuração e Mudança • 8. Gestão de Projetos • 9. Ambiente

5. Bibliografia • Fundamental: • IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects. 2008. IBM Rational. • Suplementar: • Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process. 1998. Addison Wesley Longman. • Per Kroll e Philippe Kruchten 2003. The Rational Unified Process Made Easy, A Practitioners Guide to the RUP. Addison Wesley Longman. • Ian Sommerville. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007.

6. Sistema de avaliação • 50% Teórico: • Média de “n” simulados • 50% Prático: • Média de “n” exercícios

7. Plano de aulas

8. Introdução à Engenharia de Software

9. Problemas clássicos da ESOF Fonte: KRO03

10. Dúvidas da engenharia de software • Qual a melhor forma de obter requisitos? • Informal, Fluxos de Dados, DER ou Casos de Uso • O que é mais importante para o cliente? • Saber logo se o projeto é viável e factível ou • Começar a ver telas do software funcionando • O que é mais fácil gerenciar? • 6 projetos de 30 dias ou • 1 projeto de 6 meses • Qual construção suportará mais mudanças? • Uma feita com base na expertise de um mestre de obras especialista ou • Uma feita pelo mesmo mestre de obras, mas com um projeto estrutural considerando as necessidades atuais e futuras do prédio

11. Evolução dos softwares Análise Clássica A. Estruturada A. Essencial Modelagem O. Objeto Programação Procedural P. Estruturada Orientada a Eventos O. Objetos Engenharia de Software Ciclo Cascata Incremental Evolutivo e Espiral Iterativo & Incremental Testes: Depuração Profissionalização Qualidade Total Automação Programa Monolítico ModularizaçãoClient-Server Arquitetura MVC (Web) Fontes: BEI90, CAR98, DEM89, GIL88, JAC98, KRU98, MSP91, MYE79, PRE95, SUM07 e YOU92

12. Clientes Clientes Fatores críticos de sucesso da fabricação de software Visão de Negócio (direção, gestão, administração) Pessoas (CHA) Qualidade Processos Gestão de Projetos Infra-estrutura TI/comunicação Fontes: JAC98, KRO03, PRE95 e SUM07

13. Pessoas (CHA) Gestão de pessoas • CHA: • Conhecimentos: Expertise em TI • Habilidades: Trabalho em equipe, comunicação, foco, ... • Atitudes: Assertividade, pró-atividade, ... • Desenvolver pessoas  desenvolver a organização: • Busca de propósitos comuns • Busca da felicidade: • Harmonia entre pensamentos, expressão e ações • Capacitação e certificações • Metas  Tensão Criativa  Superação • Motivação  Resultados  Motivação • Atração e retenção de talentos

14. Processos Processos de engenhariade software • Cascata – Uma disciplina só após a outra • MSF – Microsoft Solutions Framework • Fases: visão, planejamento, estabilização e instalação • Disciplinas: projeto, riscos e competência • Mais ágil e menos formal que o RUP • RUP – RationalUnifiedProcess • Desenvolvido pela Rational (hoje da IBM) • Processo mais utilizado atualmente • XP – Extreme Programming • Atividades: planejamento, projeto, codificação e teste • Gera sensação de produtividade constante

15. Comparativo de disciplinas

16. Nível 2 – Repetível 1 – Inicial 0 - Inexistente 3 – Definido 4 - Gerenciado 5 – Otimizado Caótico (Tentativa e Erro) Não há procedimentos Dependência de indivíduos Institucionalizado Processo de Medição Processo de Melhoria Característica Automação Desconhecimento do domínio Mudanças tecnológicas Processos de métricas e análise Planejamento e Gestão de projetos Padronização, treinamento e teste Área Foco (com problema) Maturidade e níveis de processos Alta Maturidade de TI Baixa Fonte: ITIL – Planning to Implement Service Management

17. O modelo cascata • Principais problemas: • O cliente participa do projeto somente no início e no final • Os riscos são mitigados no final do projeto • Tem descoberta tardia de erros de projeto

18. O modelo iterativo Módulo 1 Módulo 2 Módulo 3

19. O modelo iterativo e incremental Módulo 3 Módulo 2 Módulo 1 Módulo 1 Módulo 2 Módulo 1

20. Nível de risco dos modelos Risco Cascata Redução de Riscos Iterativo e Incremental Tempo Fonte: KRO03

21. Progresso do projeto dos modelos Protótipos  Arquitetura  Funcionalidades  Produto Síndrome dos 90% Processo Iterativo & Incremental % de Codificação Completo do Projeto Cascata Tempo Fonte: KRO03

22. Custo das mudanças • Softwares atuais são complexos  requisitos inexatos  mudanças são necessárias (e devem ser estimuladas) • As mudanças devem ser detectadas e tratadas o mais cedo possível  menor custo Fonte: KRO03

23. Gestão de Projetos Gestão de projetos (GP) • PMI – Project Management Institute: • Project Management BodyofKnowledge (PMBOK) • Metodologia mais utilizada atualmente • Prince2 – Metodologia do governo inglês: • Adotada em vários países europeus • TenSetp • Processo de uma multinacional americana que é representante do PMI • Agile • Resultante de um manifesto feito por 17 especialistas em Fevereiro de 2001 em Utah – USA • ISO 10006: • A International Standards Organization tomou o PMI como base e fez uma simplificação

24. PMBOK do PMI – 47 Processos Disciplinas Grupos de Processos 2 24 4 3 7 6 4 4 6 8 11 6 3 4 2

25. X Projeto de Desenvolvimento Requisitos Análise Projeto Testes Qualidade Verificação da qualidade

26. Qualidade • Fazer certo na primeira vez • A qualidade deve ser meta e resultado em todas as etapas do processo, não somente no final • É preciso garantir a qualidade do: • Produto (resultante do projeto) • Processo aplicado ao projeto • E consequentemente: • do Projeto e das Pessoas.

27. Introdução ao RUP

28. Histórico do RUP & do UML

29. Resumo do Histórico Gestão de Projetos   Web D.  R.Time Modelagem de Negócio   GC&M Booch Jacobson Rumbaugh Requisitos   Testes Análise & Projeto   OOSE (Jacobson) Fonte: RAT98 e IBM03

30. Estrutura do RUP • RUP 7.5: • Projetos: • Grandes • Pequenos • Apresentar: • Idiomas • RUP 7.5 • Links para download

31. Dirige Guia Arquitetura Pilares estratégicos do RUP • Dirigido por Casos de Uso • Centrado em Arquitetura • Iterativo e Incremental • Fases e Iterações Casos de Uso

32. As fases do RUP e seus objetivos • Iniciação (concepção): • Definir o macro escopo • Verificar a viabilidade econômica • Elaboração: • Verificar a viabilidade técnica • Definir a arquitetura básica (versão α) • Construção • Desenvolver o software (versão β) • Transição • Fazer testes de aceitação e entregar o produto

33. As iterações do RUP • São mini-projetos com objetivos de: • Integração de middleware, versão-alfa, casos de uso ... versão-beta e produto • Vantagens: • Redução de riscos • Percepção antecipada • Quebra da complexidade • Facilitação do gerenciamento • Trabalho com parte dos requisitos • Construção de builds executáveis • Evolução incremental do sistema pelos componentes

34. Disciplinas do RUP Esforço x Disciplina x Tempo

35. Do problema do clienteà solução do usuário Problema clássico Mapeando o território Espaço do Problema Problema Necessidades Espaço da Solução Funcionalidades Rastreabilidade Produto a ser feito Requisitos do Software Casos de Testes Docum. Usuário Projeto Fonte: KRO03

36. Processo adaptável ao projeto Versões pré-definidas RationalMethodcomposer • Grandes Projetos • Pequenos Projetos Fases  X  X X   X  X X  X Disciplinas Atividades  X  Tarefas X  X  X Artefatos X X  X 

37. Elementos essenciais do RUP • Visão: Desenvolva uma visão • Processo: Adote um processo para o projeto • Plano: Crie e gerencie o plano • Riscos: Mitigue riscos e rastreie problemas • Caso de Negócios: Examine o caso de negócios • Arquitetura: Projete arquitetura de componente • Protótipo: Construa e teste progressivamente • Avaliação: Avalie regularmente os resultados • Controle de Mudanças: Gerencie e controle as alterações • Suporte ao Usuário: Implemente um produto utilizável

38. Outros princípios chaves do RUP

39. Quando utilizar o RUP RUP para pequenos projetos RUP para projetos de médio porte CMM RUP para grande projetos CMMI Cascata Nível de Integração Iterativo Baixa Complexidade Técnica Alta Informal Nível de Formalidade Formal Adaptação livre de: JAC98, KER04, KRO03 e RUP08 Criar x Documentar XP, SCRUM e Adaptive Development Baixa Complexidade de Gestão Alta

40. Pesquisa: metodologia em Uberlândia feita com 177 profissionais Porte empresa Ti na empresa Perfil das pessoas Fonte: MOR13

41. Relação da empresa com metodologia Usa metodologia metodologia Fases do rup Fonte: MOR13

42. Disciplinas utilizadas nas empresas Fonte: MOR13 59% de Similaridade com o RUP

43. Conclusões sobre o RUP • Ele resolveu os problemas clássicos do desenvolvimento de software • Ele definiu o que é a Engenharia de Software • Ele serviu de base para as metodologias que estão surgindo • Ele pode ser utilizado para projetos de todos os portes

44. Fluxos de trabalho do RUP Início do fluxo Atividade Atividade Término do fluxo Atividades em paralelo

45. Detalhamento de fluxos de trabalho Tarefa Seqüenciamento Entradas Função (papel) Tarefa Saídas Produto do trabalho (artefato)

46. Referências