Este documento apresenta o professor Rodrigo Gomes da Silva e seu seminário sobre o Processo Iterativo com RUP. Ele fornece seus contatos, certificações, formação acadêmica e experiência profissional, além da agenda do seminário, que inclui tópicos como sintomas de problemas em desenvolvimento de software, as melhores práticas da engenharia de software, princípios do desenvolvimento iterativo, o processo RUP e suas fases, disciplinas, papéis e artefatos.

1. Professor: Rodrigo Gomes da Silva
Assunto: Introdução ao Processo Iterativo com RUP
Novembro / 2013

2. Apresentação
Rodrigo Gomes da Silva
Contatos:
rodrigo.gomes3@hotmail.com
rogomes@br.ibm.com
rodrigo.gomes@unis.edu.br
Redes Sociais
http://www.linkedin.com/pub/rodrigo-gomes-da-silva/37/568/716
https://twitter.com/rodrigogomes3
https://www.facebook.com/rodrigo.gomesdasilva.92
•
Certificações
–
–
•
Formação:
–
–
–
–
•
Especialista em Design Instrucional para EaD Virtual (UNIFEI)
Especialista em Docência do Ensino Superior (FINOM)
Bacharel em Sistemas de Informação (UEMG)
Técnico em Processamento de Dados (CETEV)
Atualmente:
–
–
•
IBM Certified RMUC – Requirements Management with Use Cases Part 1
IBM Certified RMUC – Requirements Management with Use Cases Part 2
Analista de Requisitos na IBM do Brasil - SP
Professor Universitário – UNIS-MG
Atuações Anteriores
–
–
–
–
–
Professor Universitário – FACECA
Professor Universitário – UNINCOR
Professor Universitário – FIPV
Analista de Sistemas – Sindicato Rural da Campanha
Gerente de TI – Santa Casa de Misericórdia da Campanha

3. Agenda
•
•
•
•
•
•
•
•
•
Sintomas dos problemas de desenvolvimento de software
As 6 melhores práticas da Engenharia de Software
Princípios do Desenvolvimento Iterativo
Processo de Desenvolvimento RUP – Rational Unified Process
Fases do RUP
Disciplinas do RUP
Papéis, Atividades e Artefatos do RUP
Acessar uma Instância do RUP
Documento Visão

4. Sintomas dos Problemas de Desenvolvimento
de Software
•
•
•
•
•
Necessidade dos usuários e do negócio não são totalmente
compreendidas
Módulos não integrados
Dificuldade de manutenção
Qualidade ruim na experiência do usuário final
Time descordenado

5. As 6 Melhores Práticas da Engenharia de
Software
•
•
•
•
•
•
Desenvolvimento iterativo
Gestão de requisitos
Arquitetura baseada em componentes
Modelagem Visual (UML)
Verificação Contínua da Qualidade
Gestão de Mudanças

6. As 6 Melhores Práticas da Engenharia de
Software
•
Desenvolvimento em Cascata
Planejamento
– Atraso na percepção e
resolução de riscos críticos
– Impede a implantação
antecipada
Análise Requisitos
Design
Codificação / Teste
Integração
Sub-Sistemas
Teste de Sistemas
– Frequentemente resulta em
grandes iterações planejadas
– A fase seguinte só inicia
quando a fase anterior termina
– Dificuldade em realizar
mudanças com o projeto em
andamento

7. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 1 - Desenvolvimento Iterativo
– Resolve maiores riscos
antes de grandes
investimentos
– Permite conhecer um
feedback do usuário mais
cedo
– Realiza testes e integrações
contínuamente
– Define marcos do projeto a
curto prazo
– Permite implantações
parciais

8. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 1 - Desenvolvimento Iterativo

9. As 6 Melhores Práticas da Engenharia de
Software
• Risco ( Cascata x Iterativo)

10. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 2 - Gestão de Requisitos
– Certifica-se de resolver o problema certo e construir o sistema
correto
– Através de uma abordagem sistêmica para:
• Compreensão do problema.
• Elicitar, organizar e documentar os requisitos.
• Gerenciando as novas exigências de uma aplicação de software (Change
Request)

11. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 3 - Arquitetura Baseada em
Componentes
– Reuso e customizção de componentes
– Selecione a partir de componentes disponíveis
comercialmente
– Evoluir software existente de forma incremental
– Maior encapsulamento

12. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 4 - Modelagem Visual - UML
– Captura a estrutura e o comportamento
– Mostra como os elementos do sistemas se
encaixam
– Mantém uma conscistência entre concepção e
implementação
– Esconde ou expõe detalhes quando necessário
– Promove uma comunicação não ambígua

13. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 5 - Verificação Contínua da
Qualidade
– Dimensões de Teste da Qualidade
•
•
•
•
•
Funcionalidade
Usabilidade
Confiança
Suportabilidade
Performance

14. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 5 - Verificação Contínua da
Qualidade
– Funcionalidade
• Testa o funcionamento preciso de cada cenário de uso
da aplicação
– Usabilidade
• Testa o aplicativa a partir da perspectiva de
conveniência para o usuário final
– Confiança
• Testa se o aplicativo possui um comportamento
consistente e previsível

15. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 5 - Verificação Contínua da
Qualidade
– Suportabilidade
• Testa a capacidade de manter e apoiar o aplicativo no
momento em que está em produção
– Performance
• Teste de carga com média e alto de pico

16. As 6 Melhores Práticas da Engenharia de
Software
• Melhor Prática 6 - Change Request Management
(Gestão da Solicitação de Mudanca) As solicitações de mudança
podem vir de várias fontes
durante o ciclo de vida do
produto.
Novas características
Requisito
Canal de
Aprovação
Novos requisitos
Bug
Design
Codificação
Teste
Change request
Manutenção
Clientes e usuários
Marketing
Codificadores e
testadores
Outros stakeholders

18. RUP – Rational Unified Process
• O RUP é um processo de
engenharia de software.
– Abordagem disciplinar de
atribuir tarefas e
responsabilidades em um
processo de
desenvolvimento de uma
organização.
• O RUP é um Framework.
– Pode ser instanciado
gerando diversos processos.
• Dependentes da organização.
• Dependentes da aplicação.
Nenhum processo é
adequado para todos as
organizações/aplicações.

19. Processo de Desenvolvimento RUP
•
Um processo define quem está fazendo o quê, quando e
como alcançar um determinado objetivo.
Novos requisitos
ou requisitos alterados
Processo de
Engenharia de
Software
Sistema novo ou
melhorado
• Roteiro para um desenvolvimento eficiente e de qualidade.
– Aborda as melhores práticas
• Visando reduzir o risco e o custo do projeto.

20. Processo de Desenvolvimento RUP
•Um processo descreve quem
está fazendo o que, como e
quando.
– Papéis
• Quem
– Atividades
• Como
– Artefatos
• O que
– Disciplinas
• Quando

21. Instância do RUP – Rational Unified Process
Download Rational Method Composer
http://www.ibm.com/developerworks/br/downloads/r/rup/

22. Instância do RUP – Rational Unified Process
Instância Online do RUP
http://www.wthreex.com/rup/v711_ptbr/index.htm

23. Fases do RUP
Iniciação
Elaboração
Construção
Transição

24. Fases do RUP
Fase de Iniciação
Formular o escopo do projeto. Isso envolve capturar o contexto, bem
como os requisitos e as restrições mais importantes, para que seja
possível depreender critérios de aceitação para o produto final.
Planejar e preparar um caso de negócios. Avaliar alternativas para o
gerenciamento de riscos, as equipes de pessoal, o plano do projeto e
as mudanças de custo/planejamento/lucratividade.
Sintetizar uma sugestão de arquitetura, avaliando as mudanças no
design e em fazer/comprar/reutilizar para que seja possível calcular
custo, planejamento e recursos.
Preparar o ambiente para o projeto, avaliando o projeto e a
organização, selecionando ferramentas e decidindo quais partes do
processo aprimorar.

25. Fases do RUP
Fase de Elaboração
Definir, validar e criar a baseline da arquitetura, com rapidez e
praticidade.
Refinar a Visão, com base nas informações novas obtidas durante a
fase, estabelecendo uma compreensão sólida dos casos de uso mais
críticos que conduzem as decisões de arquitetura e planejamento.
Criar planos de iteração detalhados de baselines para a fase de
construção.
Refinar o processo de desenvolvimento e posicionar o ambiente
de desenvolvimento
Refinar a arquitetura e selecionar componentes. Os componentes
potenciais são avaliados e as decisões de fazer/comprar/reutilizar são
bem compreendidas para determinar o custo da fase de construção e
programar com confiança.

26. Fases do RUP
Fase de Construção
Gerenciamento de recursos, otimização de controle e processo
Desenvolvimento completo do componente e teste dos critérios de
avaliação definidos
Avaliação dos releases do produto de acordo com os critérios de
aceitação para a visão

27. Fases do RUP
Fase de Transição
Executar planos de implementação
Finalizar o material de suporte para o usuário final
Testar o produto liberado no local do desenvolvimento
Criar um release do produto
Obter feedback do usuário
Ajustar o produto com base em feedback
Tornar o produto disponível aos usuários

28. Disciplinas do RUP
• Modelagem de Negócios
• Requisitos
• Análise e Design
• Implementação
• Teste
• Implantação
• Gerenciamento de Configuração e
Mudança
• Gerenciamento de Projetos
• Ambiente

29. Disciplinas do RUP
Modelagem de Negócios
• 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.

30. Disciplinas do RUP
Requisitos
• Estabelecer e manter concordância com os clientes e outros
investidores sobre o que o sistema deve fazer.
• Oferecer aos desenvolvedores do sistema uma compreensão melhor
dos requisitos do sistema.
• Definir os limites do sistema (ou delimitar o sistema).
• Fornecer uma base para planejar o conteúdo técnico das iterações.
• Fornecer uma base para estimar o custo e o tempo de
desenvolvimento do sistema.
• Definir uma interface de usuário para o sistema, focando nas
necessidades e metas dos usuários

31. Disciplinas do RUP
Análise e Design
• Transformar os requisitos em um design do sistema a ser criado.
• Desenvolver uma arquitetura sofisticada para o sistema.
• Adaptar o design para que corresponda ao ambiente de
implementação, projetando-o para fins de desempenho.

32. Disciplinas do RUP
Implementação
• Definir a organização do código em termos de subsistemas de
implementação organizados em camadas
• Implementar os elementos de design em termos de elementos de
implementação (arquivos de origem, executáveis e outros)
• Testar os componentes desenvolvidos como unidades
• Integrar os resultados produzidos por implementadores individuais (ou
equipes) ao sistema executável

33. Disciplinas do RUP
Teste
• Localizar e documentar defeitos na qualidade do software.
• Sugestões sobre a qualidade do software.
• Validar e provar as suposições feitas nas especificações de projeto e
requisitos através de demonstração concreta.
• Validar se o software funciona conforme o projeto.
• Validar se os requisitos são implementados adequadamente.

34. Disciplinas do RUP
Implantação
• Produzir com sucesso lançamentos de produtos e entregar o software
para seus usuários finais.
• 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.

35. Disciplinas do RUP
Gerenciamento de Configuração e Mudanças
• Controlar os vários produtos do trabalho
• Gerenciar diversas variantes de sistemas de software em
desenvolvimento
• Controlar as versões que são utilizadas em determinados builds do
software
• Permitir atualização simultâneas

36. Disciplinas do RUP
Gerenciamento de Projetos
• Fornecer uma estrutura para gerenciar projetos software intensivo.
• Fornecer orientação prática para planejar, formar a equipe, executar e
monitorar projetos
• Fornecer uma estrutura para gerenciar riscos
• Gerenciamento de pessoas: contratar, treinar, instruir
• Gerenciamento de orçamento: definir, alocar e assim por diante
• Gerenciamento de contratos, com fornecedores e clientes
• Planejamento de um projeto repetitivo, através do ciclo de vida e por
uma iteração específica
• Monitoramento do progresso de um projeto repetitivo

37. Disciplinas do RUP
Ambiente
• Fornecer a organização de desenvolvimento de software com o
ambiente de desenvolvimento de software -- para processos e
ferramentas -- que oferecerão suporte à equipe de desenvolvimento.

38. Iteração no RUP
O que é uma Iteração?
• Envolve as atividades de desenvolvimento que levam ao release
• Uma passagem completa por pelo menos as disciplinas:
• Requisitos
• Análise e Design
• Implementação
• Teste
• É como um pequeno projeto cascata

39. Iteração no RUP
Por que Iterar?
• Projetos organizados para percorrer cada disciplina em sequencia,
abordagem “cascata”

40. Iteração no RUP
Por que Iterar?
• A iteração permite percorrer várias vezes as
diversas disciplinas de desenvolvimento:
• Melhor entendimento dos requisitos
• Planejamento de uma arquitetura
robusta
• Organiza o desenvolvimento
• Libera uma série de implementações
que são gradualmente mais complexas

41. RUP – Análise eixos Horizontal - Vertical

42. Papéis do RUP
•É uma definição abstrata para um conjunto
de atividades realizadas e seus artefatos.
•Um papel pode ser realizado por:
– um pessoa ou
– uma equipe
•Um papel corresponde a:
– Responsabilidades e
– Comportamentos.
Exemplos

43. Papéis do RUP
• Atribuições
– Coleta de todos os conjuntos de funções publicados. Identificam
os principais papéis e atividades de cada papél do time.

44. Papéis do RUP
•
Analistas
– Sistemas, Processos de negócios, Projeto de Negócios, Revisor do modelo de
Negócios, Revisor de requisitos, Requisitos, Projetista de interface.
•
Desenvolvedores
– Arquiteto, Designer, Database Designer, Programador, Integrador, Revisor da
arquitetura, Revisor de código
•
Testadores
– Testador
– Projetista de testes
•
Gerentes
– Projeto, Processo, Configuração, Mudanças, Revisão de projeto

45. Papéis do RUP
•
Exemplo do Papél Analista de Sistemas

46. Atividades do RUP
•Atividade
– Uma atividade é uma unidade de
trabalho atribuída a um papel.
– A atividade tem um propósito
claro.
• Criação e atualização de
artefatos.
– A atividade deve ser utilizada
como elemento para
planejamento e controle de
progresso.
•Exemplo de atividades:
– Planejar uma iteração.
• Papel: Gerente de Projeto.
– Identificar atores e use cases.
• Papel: Analista de Sistemas.
– Revisar o design.
• Papel: Revisor
•Atividades e Artefatos:
– As atividades estão estritamente
ligadas a artefatos.
– Os artefatos são as entradas ou
saídas de uma atividade.
– Os artefatos servem como
mecanismo de comunicação entre as
atividades.

47. Artefatos do RUP
•Artefato
– Um artefato é um pedaço de
informação que é produzido,
modificado ou utilizado pelo
processo.
– Artefatos podem ser:
•
•
•
•
•
Modelos.
Elementos de Modelo.
Documentos.
Código Fontes.
Executáveis.
•Artefatos podem ser expresso:
– Visualmente.
– Textualmente.
: anActor
anActor

48. Documento Visão
• Esta tarefa descreve como
desenvolver a visão geral para o
sistema, incluindo o problema a ser
resolvido, os investidores chave, o
escopo/limite do sistema, os
recursos-chave do sistema e
quaisquer restrições.
A finalidade dessa tarefa é:
• Estabelecer um acordo sobre quais
problemas precisam ser resolvidos.
• Identificar investidores do sistema.
• Definir os limites do sistema.
• Descrever os principais recursos do
sistema.

49. Certificação em RUP
IBM Certified Solution Designer - IBM Rational Unified Process
V7.0
http://www-03.ibm.com/certify/certs/38008003.shtml

50. Atividade Prática
• Dividir a sala em 4 grupos
• Desenvolver o Documento Visão dos sistemas propostos:
• Controle acadêmico de notas
• Controle de recebimento de mensalidades
• Controle de contas à pagar
• Controle de empréstimos de livros de uma biblioteca
• Cada grupo deverá apresentar o Documento Visão Construído
Template Documento
Visão