7. http://www.takenami.com.br
Melhores Práticas para Desenv. de Software
• Desenvolvimento interativo
• Gerenciamento de Requisitos
• Arquitetura baseada em Componentes
• Modelo de Software Visual
• Verificação contínua da qualidade do Software
• Gerenciamento e controle de mudanças
8. http://www.takenami.com.br
Desenvolvimento Iterativo
Desenvolvimento em Desenvolvimento
Cascata Iterativo
9. http://www.takenami.com.br
Desenvolvimento Iterativo
Requisitos
Modelagem Análise & Projeto
de Negócio
Implementa
ção
Desenvolvimento
Avaliação Teste
10. http://www.takenami.com.br
Vantagens do Desenvolvimento Iterativo
• Os riscos são atacados mais cedo
• Mudanças nos requisitos
• Refinamento de arquitetura
• Aprendizado e aprimoramento
• Aumento do reuso
11. http://www.takenami.com.br
Gerenciamento de Requisitos
• Requisitos não são óbvios
• Requisitos não são facilmente expresso em palavras
• Existem vários tipos de requisitos em diferentes
níveis de detalhes
• O número de requisitos pode explodir
• Requisitos estão interligados
• Existem várias pessoas interessadas nos requisitos
• Requisitos mudam
12. http://www.takenami.com.br
Arquitetura Baseada em Componentes
• Define uma arquitetura modular
• Facilita o reúso
• Arquiteturas e componentes prontos
• Permite escalabilidade
• Facilita manutenção
14. http://www.takenami.com.br
Modelagem Visual
• Ajuda a entender sistemas complexos
• Facilita a linguagem e comunicação entre o
mundo real e o que vai ser desenvolvido
• Explora e compara alternativas
• Forma uma base para a implementação
• Facilita a captura dos requisitos
• Comunica as decisões sem ambigüidades
18. http://www.takenami.com.br
Verificação Contínua da Qualidade
• O que é qualidade?
• Onde está a qualidade?
- Qualidade do Processo
- Qualidade do Produto
• Gerência da qualidade consiste em:
- Identificar métricas
- Coletar dados
- Identificar os pontos que afetam a qualidade o quanto antes
- Alinhar a equipe ao processo adotado
19. http://www.takenami.com.br
Gerência de Mudanças
• Controla:
- Os artefatos criados
- Acesso aos artefatos
- Mudanças nos artefatos
- Baselines
- Geração dos Releases
• Controlando Mudanças de Software
22. http://www.takenami.com.br
O que é RUP?
• O RUP (Rational Unified Process) é um
framework para desenvolvimento de software
criado pela empresas Rational
• Tem como objetivo oferecer um processo de
desenvolvimento “bem definido” e “bem gerido”
• Utiliza as 6 melhores práticas de
desenvolvimento de software
23. http://www.takenami.com.br
Características do RUP
• Utiliza desenvolvimento Iterativo e Incremental
• Sustentado em UML
• Dirigida por caso de uso (use-case driven)
- A identificação de casos de uso e cenários típicos conduz todo o
processo de desenvolvimento, desde a análise de requisitos até o
teste do sistema final
• Centrado na arquitetura
- Promove a definição inicial de uma arquitetura de software
robusta, que facilita o desenvolvimento, reutilização e
manutenção
• Define: Quem?, Como?, O que? e Quando?
24. http://www.takenami.com.br
Principais Conceitos
• Fases
- Define as etapas para desenvolvimento do software
- Diferente do modelo cascata um fase envolve várias
atividades que vai desde a modelagem a implantação
- Cada fase é dividida em iterações
• Disciplinas
- Agrupam workflow com os mesmo objetivos
- Definem áreas de conhecimento utilizada no framework
- Também conhecido como Core Workflow
26. http://www.takenami.com.br
Outros Conceitos
• Fluxo de Trabalho
- Agrupam atividades relacionadas
• Atividades
- São tarefas que podem ser entregues a trabalhadores individuais
• Artefato
- São inputs e outputs de actividades
• Modelos
- Agrupam artefactos desenvolvidos num workflow
• Papeis (workers)
- São perfis a que correspondem competências para a realização de
atividades
27. http://www.takenami.com.br
Definições dos Conceitos
Papeis (Workers) - Quem?
Atividades (Activities) - Como?
Artefatos (Artifacts) - O Que?
Fluxo de Trabalho (Workflows) - Quando?
30. http://www.takenami.com.br
Fases
• Concepção (Inception)
- Definição do escopo do projeto, identificação dos atores,
casos de uso e descrição dos mais significativos
• Elaboração (Elaboration)
- Análise do sistema, definição da arquitetura de software
• Construção (Construction)
- Desenvolvimento iterativo e incremental do produto
• Transição (Transition)
- Atividades de “entrega” do software
31. http://www.takenami.com.br
Concepção
• Estabelecer o escopo e os limites, com critérios
de aceitação bem definidos
• Discriminar os casos de usos críticos
• Exibir uma arquitetura candidata
• Estabelecer estimativa de: Custo, Esforço e
Cronograma
• Preparar o ambiente do projeto
32. http://www.takenami.com.br
Concepção - Milestone
• Viabilidade
- Examina os objetivos e decide seguir ou cancelar o
projeto
• Critério de avaliação
- Entendimento e acordo com os requisitos
- Credibilidade no equilíbrio de: esforço x custo x
cronograma
- Acerto das prioridades
33. http://www.takenami.com.br
Elaboração
• Levantamento e elicitação da maioria dos
requisitos
• Identificação dos riscos mais significativos
• Tamanho real do projeto
• Estabelecer uma arquitetura
• Provar que a arquitetura funciona
• Produzir um protótipo evolucionário
• Estabelecer um ambiente
34. http://www.takenami.com.br
Elaboração - Milestone
• Examina os objetivos, arquitetura e riscos do
projeto
• Critério de avaliação
- Requisitos, visão e arquitetura estáveis
- Verificar que, com os protótipos, todos os riscos
foram atacados
- Planos de Iteração da fase de construção
- Despesas atuais batem com estimadas
35. http://www.takenami.com.br
Construção
• Desenvolver incrementalmente e lançar as
versões de teste (alpha, beta)
• Completar o desenvolvimento de todos os
Casos de Uso
• Casos de Uso com maior prioridade e/ou risco
de desenvolvimento primeiro
• Cada iteração é um mini-projeto: Análise,
projeto,codificação, teste e integração
36. http://www.takenami.com.br
Construção - Milestone
• Sistema e manual
• Critério de avaliação
- O Sistema passou em todos os testes de integração?
- O sistema já esta maduro o suficiente pra ser
entregue?
- Os stakeholders estão prontos para usá-lo?
• Despesas reais versus planejadas continuam
aceitaveis?
37. http://www.takenami.com.br
Transição
• Conversão do ambiente para produção
• Treinamento de usuários e manutenção
• Suporte ao usuário
38. http://www.takenami.com.br
Transição - Milestone
• Os objetivos foram cumpridos?
• Critério de avaliação
- O usuário está satisfeito
- Despesas reais versus planejadas continuam
aceitáveis?
• Gerar base de conhecimento para próximo
projeto
39. http://www.takenami.com.br
Ciclo de vida do RUP
• Cada fase pode ser dividida em iterações
• Cada iteração é incremental pois envolvem todas
as disciplinas
40. http://www.takenami.com.br
Iterações
• Cada iteração resulta num incremento ao
produto
- Tipicamente é analisado e implementado um grupo
de casos de utilização ou de variantes de casos de
utilização
• Cada iteração passa pelos workflows técnicos
- Importância relativa dos workflows varia com as fases
41. http://www.takenami.com.br
Disciplinas
• Agrupa os workflows de atividades correlatas
• Dividem-se em 2 grupos:
- Engenharia
- Suporte
43. http://www.takenami.com.br
Workflow
• Sequência de atividades que produzem um
resultado de valor observável
• Geralmente expresso em um diagrama de
atividade
• Organizado em disciplinas
46. http://www.takenami.com.br
Atividades
• Unidade de trabalho com um propósito claro
• Pode ser decomposto em vários passos
• Os passos podem ser visto como tarefas
• Possui sempre um responsável
47. http://www.takenami.com.br
Atividades
• Exemplos:
- Identificar casos de uso e atores
a) Worker: Analista de Sistemas
- Revisar o projeto
a) Worker: Revisor de Projeto
- Executar teste de desempenho
a) Worker: Testador de desempenho
49. http://www.takenami.com.br
Atividades
• A atividade Find Use Case and Actors se
decompõe nos passos:
- Identificar os atores
- Identificar os casos de uso
- Descrever a interação entre os atores e uc
- Organizar em pacotes
- Apresentar o modelo em um diagrama
- Avaliar os resultados
50. http://www.takenami.com.br
Artefatos
• Tudo que é produzido durante o
desenvolvimento
• Artefato x Produto
• Sujeito a Gerencia de Configuração
• Mantidos por controle de versão
52. http://www.takenami.com.br
Modelos
• Conjunto de artefatos gerados num workflow
• Modelo de Negócio
• Modelo da Arquitetura
• Esboço do artefato a ser desenvolvido
53. http://www.takenami.com.br
Papeis (Workers)
• Define o comportamento e as responsabilidades
de um indivíduo em uma equipe
• Um pessoas pode assumir mais de um papel
dentro do projeto