Especialização
em Segurança
da Informação
Segurança em Aplicações
2. Processo de Desenvolvimento
Márcio Aurélio Ribeiro Moreira
[email protected]
http://si.lopesgazzani.br/docentes/marcio/
Introdução ao RUP
Márcio Moreira
3. Processo de Desenvolvimento – slide 2
Segurança em Aplicações
Estrutura do RUP
 RUP 7.5:
 Projetos:
Grandes
Pequenos
 Apresentar:
Idiomas
RUP 7.5
Links para
download
Márcio Moreira
3. Processo de Desenvolvimento – slide 3
Segurança em Aplicações
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
Márcio Moreira
3. Processo de Desenvolvimento – slide 4
Segurança em Aplicações
Pilares estratégicos do RUP
Dirigido por Casos de Uso
Centrado em Arquitetura
Iterativo e Incremental
Fases e Iterações
Casos de Uso
Dirige
Guia
Arquitetura
Márcio Moreira
3. Processo de Desenvolvimento – slide 5
Segurança em Aplicações
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
Márcio Moreira
3. Processo de Desenvolvimento – slide 6
Segurança em Aplicações
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
Márcio Moreira
3. Processo de Desenvolvimento – slide 7
Segurança em Aplicações
Disciplinas do RUP
 Modelagem de Negócios:
 Compreensão da Engenharia do Negócio (por que)
 Requisitos:
 Explicitação e coleta de requisitos (escopo: o que)
 Análise e Design (Projeto):
 Transformação dos requisitos em especificação do software (como) Esforço x Disciplina x Tempo
 Implementação:
 Desenvolve, organiza, testa a unidade e integra os componentes do software
 Testes:
 Testa a qualidade do software
 Distribuição:
 Distribui (instala) o software aos usuários (entrega), não é um projeto de implantação completo
 Gestão de configuração e mudanças:
 Cuida do controle e sincronização dos componentes do software
 Gestão do projeto:
 Foca em planejamento, gestão de riscos e gestão do progresso do projeto
 Ambiente:
 Cria e mantém o ambiente (processos e ferramentas) de desenvolvimento interno do software
Márcio Moreira
3. Processo de Desenvolvimento – slide 8
Segurança em Aplicações
Adaptação livre de: JAC98, KER04, KRO03 e RUP08
Complexidade Técnica
Alta
Quando utilizar o RUP
CMM
RUP para pequenos
projetos
RUP para projetos de
médio porte
Criar x Documentar
RUP para grande
projetos
CMMI
Baixa
XP, SCRUN e
Adaptive
Development
Baixa
Márcio Moreira
Complexidade de Gestão
3. Processo de Desenvolvimento – slide 9
Alta
Segurança em Aplicações
Princípios chaves do RUP
 Adaptar o processo:
 Dimensione o processo para cada projeto
 Equilibrar prioridades dos investidores:
 Promova o alinhamento da TI aos negócios
 Trabalhar em conjunto com equipes:
 Motivação, auto-gestão, colaboração, etc.
 Demonstrar valor iterativamente:
 Mostrar o valor produto ao usuário a cada iteração
 Elevar nível de abstração:
 Arquitetar e reutilizar para simplificar e quebrar a complexidade
 Focalizar continuamente na qualidade:
 Para o produto ter qualidade o processo precisa de acompanhamento
Márcio Moreira
3. Processo de Desenvolvimento – slide 10
Segurança em Aplicações
Fluxos de trabalho do RUP
Início do fluxo
Atividade
Atividade
Término do fluxo
Atividades em paralelo
Márcio Moreira
3. Processo de Desenvolvimento – slide 11
Segurança em Aplicações
Detalhamento de fluxos de trabalho
Tarefa
Seqüenciamento
Função (papel)
Tarefa
Produto do trabalho (artefato)
Márcio Moreira
3. Processo de Desenvolvimento – slide 12
Segurança em Aplicações
Disciplinas do RUP
Márcio Moreira
3. Processo de Desenvolvimento – slide 13
Segurança em Aplicações
Objetivos da modelagem de negócio
 Entender os problemas atuais na organização de
destino e identificar os potenciais de aprimoramento.
 Avaliar o impacto da alteração organizacional.
 Assegurar que os clientes, usuários,
desenvolvedores e outros parceiros tenham uma
compreensão comum da organização.
 Derivar os requisitos do sistema de software
necessários para suportar a organização de destino.
 Entender como um sistema de software a ser
implementado se ajusta à organização.
Márcio Moreira
3. Processo de Desenvolvimento – slide 14
Segurança em Aplicações
Atividades da modelagem de
negócios
Cenário 3: 1 Negócio e n Sistemas
(revisão do negócio)
Cenário 4: 1 Sistema e n Negócios
(1 aplicativo para vários empresas)
as-is
to-be
Cenário 6: Renovação
(reengenharia do negócio)
Cenário 1: Gráfico da Organização
(sem mudança de negócio)
Cenário 5: Novo Negócio
(Projeto = ao 3/4, - esta atividade)
Márcio Moreira
3. Processo de Desenvolvimento – slide 15
Segurança em Aplicações
Objetivos das atividades de
modelagem do negócio
 Avaliar o status do negócio (as-is):
 Essa atividade visa avaliar o status da organização e definir os objetivos da
modelagem de negócio.
 Descrever o negócio atual (as-is):
 Essa atividade busca compreender como o negócio está e refinar os
objetivos do esforço de modelagem de negócio.
 Definir o negócio (to-be):
 Essa atividade deve definir o negócio previsto.
 Explorar a automação do processo:
 Essa atividade explora as oportunidades de automação dos processos de
negócios considerados.
 Desenvolver o modelo de domínio:
 Essa atividade visa desenvolver o Modelo de Domínio, que é um
subconjunto do Modelo de Análise de Negócio.
Márcio Moreira
3. Processo de Desenvolvimento – slide 16
Segurança em Aplicações
Visão de
Negócio
Márcio Moreira
Onde queremos ir?
Metas de
Negócio
Avaliação da
Organização
Processo de
Negócio
Estratégia de
Negócio
Essência da modelagem de negócio
Como chegaremos lá?
Onde estamos?
Modelo de
Negócio
Processo de
Negócio
M. de Casos de Uso ou
Diagrama de Domínio
Casos de Uso e Processo
ou Operações de Negócio
3. Processo de Desenvolvimento – slide 17
Detalhes do
Negócio
Arquitetura de
Negócio
Regras de Negócio
Glossário de Negócio
Estrutura de: mercado,
processos, pessoas, etc.
Segurança em Aplicações
Requisitos = f( comunicação )
Márcio Moreira
3. Processo de Desenvolvimento – slide 18
Segurança em Aplicações
Objetivos da disciplina de 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.
Márcio Moreira
3. Processo de Desenvolvimento – slide 19
Segurança em Aplicações
Fluxo de trabalho de requisitos
Márcio Moreira
3. Processo de Desenvolvimento – slide 20
Segurança em Aplicações
Objetivos das atividades
Problema
 Análise do problema:
 Essa atividade estabelece o acordo sobre o problema a ser resolvido e propõe
uma solução de alto nível.
Soluções
 Compreender as necessidades dos envolvidos (lista de funcionalidades):
Funcionali
dades
 Essa atividade busca entender o que os envolvidos desejam a partir da
solução proposta e define os recursos principais para a solução.
 Definir o sistema:
 Essa atividade destaca os requisitos chave e busca aceitação no escopo do
sistema.
Requisitos
 Gerenciar o escopo do sistema:
 Essa atividade assegura que os requisitos do sistema estejam limpos e
estabelece um conjunto gerenciável de trabalhos de requisitos para iteração.
 Refinar a definição do sistema:
 Essa atividade detalha os requisitos a serem desenvolvidos no ciclo atual de
desenvolvimento.
Detalhes
 Gerenciar requisitos variáveis:
 Essa atividade gerencia as alterações nos requisitos e avalia seus impactos.
Márcio Moreira
3. Processo de Desenvolvimento – slide 21
Segurança em Aplicações
Tipos de Requisitos – FURPS+
Funcionality:
Usability:
Reliability:
Performance:
Suportability:
+:
Funcionalidade
Usabilidade
Confiabilidade
Desempenho
Suportabilidade
Restrições de projeto
Requisitos de: implementação, físicos e interface
Márcio Moreira
3. Processo de Desenvolvimento – slide 22
Segurança em Aplicações
Modelo de
Casos de Uso
Plano Gestão
de Requisitos
Estruturar o
Software
Detalhar o Sistema
Essência da coleta de requisitos
Márcio Moreira
Como vamos colher, analisar
e manter os requisitos?
Esboço
Seqüencial
Processo
Pedido dos
Envolvidos
Lista de
Features
Casos de Uso
Arquitetura do
Software
Estrutura de: mercado,
processos, pessoas, etc.
Requisitos do
Software
Regras de Negócio
Glossário de Negócio
e/ou
Modelo de
Domínio
3. Processo de Desenvolvimento – slide 23
Segurança em Aplicações
Objetivos da disciplina de análise &
design
Transformar os requisitos em um design
(projeto) do sistema a ser criado.
Desenvolver uma arquitetura sofisticada
para o sistema.
Adaptar o design (projeto) para que
corresponda ao ambiente de
implementação, projetando-o para fins de
desempenho.
Márcio Moreira
3. Processo de Desenvolvimento – slide 24
Segurança em Aplicações
Fluxo de trabalho de análise & design
Márcio Moreira
3. Processo de Desenvolvimento – slide 25
Segurança em Aplicações
Objetivos das atividades
 Realizar Síntese Arquitetural (utilizada na Iniciação):
 Construir e avaliar uma Prova de Conceito Arquitetural, para demonstrar que o sistema idealizado
é factível.
 Definir uma Sugestão de Arquitetura:
 Criar um esboço inicial da arquitetura de software.
 Identificação de Serviço:
 Identificar e qualificar serviços candidatos.
 Analisar Comportamento:
 Transformar descrições comportamentais fornecidas pelos requisitos em um conjunto de
elementos, no qual o design possa se basear.
 Refinar a Arquitetura:
 Concluir a arquitetura para uma iteração.
 Projetar Componentes:
 Refinar o design do sistema.
 Projetar o Banco de Dados:
 Identificar as classes de design a serem persistidas em um banco de dados e projetar as
estruturas de banco de dados correspondentes.
 Especificação de Serviço:
 Especificar o comportamento de serviço e identificar os fornecedores de serviços e partições.
Márcio Moreira
3. Processo de Desenvolvimento – slide 26
Segurança em Aplicações
Arquitetura do
Software
Descrição Arquitetural e
M. de Análise e de Serviços
Modelo de
Análise
Casos de Uso
Análise de realização dos
Casos de Uso
Pacotes de
Análise
Especificar o
Software
Estruturar o
software
Essência da análise & projeto
Márcio Moreira
Classes de análise
Mapa de navegação
Projeto
Arquitetural
Descrição Arquitetural e
M. de Projeto e Implementação
Projeto de
Casos de Uso
Projeto de
Classes
Modelo de Dados
Classes de Projeto e Testes
Componentes de Serviços
Projeto de
sub-sistemas
3. Processo de Desenvolvimento – slide 27
Projetos de realização
dos Casos de Uso
Projeto de sub-sistemas
Projeto de interfaces
Segurança em Aplicações
Objetivos da 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
desenvolvedores individuais (ou equipes) ao
sistema executável
Márcio Moreira
3. Processo de Desenvolvimento – slide 28
Segurança em Aplicações
Fluxo de trabalho da implementação
1
1
Iteração 1
Build 1
Subsistema 1
Comp1
Comp2
Build 2
Subsistema 2
Comp3
Márcio Moreira
Comp4
Comp5
Subsistema 1
C1
C6
3. Processo de Desenvolvimento – slide 29
Segurança em Aplicações
Objetivos das atividades
 Estruturar o modelo de implementação:
 Estruturar a implementação para assegurar uma implementação, integração e
processo de build estável
 Planejar a integração:
 Planejar como será feita a integração do sistema para a iteração em andamento
 Realização de serviço:
 Composta pela atividade de Decisões de Realização
 Decidir como serão realizados os serviços da iteração
 Implementar componentes:
 Concluir uma parte da implementação, para que possa ser liberada para integração
 Integrar cada subsistema:
 Integrar as mudanças de vários desenvolvedores, para criar uma nova versão
consistente de um Subsistema de Implementação
 Integrar o sistema:
 Integrar os subsistemas de implementação, para criar uma nova versão consistente
do sistema total
Márcio Moreira
3. Processo de Desenvolvimento – slide 30
Segurança em Aplicações
Essência da implementação
Planejamento
• Modelo de Implementação
• Plano de Integração de Builds
Desenvolvimento e Teste Unitário:
• Subsistemas e interfaces
• Componentes (software, serviços e testes) desenvolvidos
• Componentes (software, serviços e testes) testados
Integração:
• Builds
• Subsistemas integrados
• Sistema integrado
Márcio Moreira
3. Processo de Desenvolvimento – slide 31
Segurança em Aplicações
Conceitos de testes
 Teste:
 É a execução controlada do software visando revelar falhas
 Falha: Desvio de comportamento
 Erro:
Origem da falha (bug)
 Teste de Regressão:
 Execução repetida dos Casos de Testes que falharam, bem como
dos Casos de Testes impactados por eles, após a correção dos
erros (bugs) que causaram as falhas
 Importância:
 Testes não provam que o software está livre de falhas. Eles
minimizam este risco, aumentam a confiança e agregam valor ao
produto
 São partes integrantes da qualidade
Márcio Moreira
3. Processo de Desenvolvimento – slide 32
Segurança em Aplicações
Elementos de testes
 De Planejamento:
 Estratégia de Teste:
 Plano de Testes:
 Idéias de Teste:
Define como o esforço de teste será conduzido
Define objetivos, metas, abordagem e recursos
testes de cada iteração
Lista de idéias a serem utilizadas nos testes
 De Desenvolvimento:
 Casos de Testes:
 Scripts de Testes:
 Dados de Teste:
 Cenários de Teste:
Entradas, passos e saídas esperadas de cada teste
Códigos executados durante (preparação, execução,
passos e geração de resultados) os Casos de Teste
Massa de dados usada para realização dos testes
Variações que um mesmo Caso de Teste pode ter
 De Execução:
 Registro de Testes:
Saída bruta da execução dos testes
 Resultados de Testes: Avaliação dos resultados dos registros de testes
Márcio Moreira
3. Processo de Desenvolvimento – slide 33
Segurança em Aplicações
Níveis de testes
 Quanto às pessoas:
 Desenvolvedores
 Testes independentes:
Sistema A
Subsistema
A1
CmpA11
CmpA12
Sistema B
Subsistema A2
CmpA21
CmpA22
CmpA23
Subsistema
B1
CmpB11
CmpB12
Subsistema
B2
CmpB21
CmpB22
 Entidades verificadoras (certificadoras) ou Usuários chaves do cliente
 Quanto a granularidade:





Testes de unidade
Testes de integração
Testes de sistema
[Testes Integrados
Testes de aceitação
(desenvolvedores)
(desenv.) (subsistemas)
(ambos)
(ambos) (outros sistemas) ausente no RUP]
(cliente) (UAT: User Acceptance Test)
 Quanto à forma:
 Formal: Seguem os casos de testes
 Informal: Não seguem roteiro (exploratórios, ad hoc ou aleatórios)
Márcio Moreira
3. Processo de Desenvolvimento – slide 34
Segurança em Aplicações
Stubs
Testes de Sistema
Sistema D
Testes Integrados e UAT
Sistema D
Stub
Stub
Sistema A
Sistema B
Sistema A
Sistema B
Stub
Sistema C
Márcio Moreira
Sistema C
3. Processo de Desenvolvimento – slide 35
Segurança em Aplicações
Visões de testes
 Quanto à visão do sistema:
 Caixa preta (fora do sistema, sem visão interna)
 Caixa branca (dentro do sistema)
 Uso de testes nas dimensões da qualidade:
Dimensão
Funcionalidade
Unidade Integração Interna Sistema Integração Externa Aceitação


Usabilidade






Confiabilidade





Desempenho








Suportabilidade
Márcio Moreira
3. Processo de Desenvolvimento – slide 36
Segurança em Aplicações
Modelo V de testes
Nível 1
Modelagem
de Negócio
Nível 2
Nível 3
Nível 4
Nível 5
Nível 6
Márcio Moreira
Teste de
Aceitação
Teste
Integrado
Requisitos
Teste de
Sistema
Arquitetura
Teste de
Integração
Análise
Teste
Unitário
Projeto
Implementa
ção
3. Processo de Desenvolvimento – slide 37
Segurança em Aplicações
Tamanho Real
Tipos de testes
• Volume
esperado
Contenção
• Volume extra
Carga
Estresse
• Até onde vai?
• Condições
extremas
 Funcionalidade:
 Função:
 Segurança:
 Volume:
A parte testável funciona como foi projetada?
Somente usuários autorizados têm acesso à funcionalidade?
A funcionalidade suporta o volume de dados especificado?
 Utilidade:
 Usabilidade:
O software tem a usabilidade que é esperada dele?
 Confiabilidade:
 Integridade:
 Estrutura:
 Estresse:
O software tem a robustez (resistência a defeitos) esperada?
Os links, botões e opções de navegação funcionam corretamente?
Como o software lidas com muitos dados, pouca memória, etc.?
 Desempenho:




Tamanho real:
Contenção:
Carga:
Perfil de desempenho:
O software tem o desempenho esperado quando com volume real?
Como o software lida com solicitação excessiva de um recurso?
Aumentando o volume de transações, até onde o software suporta?
O software possui gargalos ou processos ineficientes?
 Suportabilidade:
 Configuração:
 Instalação:
Márcio Moreira
Nosso software funciona em diferentes configurações (hw/sw)?
O processo de instalação funciona em diferentes configurações?
3. Processo de Desenvolvimento – slide 38
Segurança em Aplicações
Objetivos dos testes
 Localizar e documentar defeitos na qualidade
do software
 Dar 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 estão implementados
adequadamente
Márcio Moreira
3. Processo de Desenvolvimento – slide 39
Segurança em Aplicações
Fluxo de trabalho de testes
Márcio Moreira
3. Processo de Desenvolvimento – slide 40
Segurança em Aplicações
Objetivos das atividades
 Definir missão de avaliação:
 Identificar o foco apropriado do esforço de teste para a iteração e estabelecer
consenso com os envolvidos sobre as metas que conduzirão o esforço de teste
 Validar abordagem do teste:
 Verificar por meio da demonstração que a abordagem de testes funcionará, produz
resultados precisos e é apropriada para os recursos disponíveis
 Validar a estabilidade da construção:
 Validar que a construção esteja estável o suficiente, para que sejam iniciados o teste
detalhado e o esforço de avaliação
 Testar e avaliar:
 Executar os testes e verificar se eles tem a amplitude e o detalhamento necessários
para garantir que os testes atinjam seus propósitos
 Realizar a missão aceitável (atingimos a missão de aceitação?):
 Garantir a aceitação do produto através das avaliações dos testes
 Aprimorar vantagens dos testes:
 Manter e aprimorar os recursos de testes
Márcio Moreira
3. Processo de Desenvolvimento – slide 41
Segurança em Aplicações
Essência dos testes
Planejamento:
• Estratégia, Plano e Idéias de Testes
• Arquitetura de Testes
• Ambiente de Testes
Desenvolvimento :
• Casos de Testes
• Scripts, Dados e Cenários de Testes
• Projeto e Interfaces de Testes
Execução:
• Log de Testes
• Mudanças (bugs ou ajustes a serem feitos)
• Resultados e Avaliação dos Testes
Márcio Moreira
3. Processo de Desenvolvimento – slide 42
Segurança em Aplicações
Conceitos de distribuição
 Distribuição (implantação):
 Disciplina responsável por garantir que o software esteja disponível para os
usuários
 Formas de distribuição previstas:
 Instalação personalizada
 Oferta de produto "comprados em loja"
 Acesso ao software por meio da Internet
 Quando distribuir?
 Após os testes feitos no ambiente fabril (Construção) e os beta testes
(Transição)
 Unidade de Implantação:
 Software e materiais auxiliares para instalar em um nó de rede
 Produto:
 Conjunto de todas as unidades de implantação necessárias
Márcio Moreira
3. Processo de Desenvolvimento – slide 43
Segurança em Aplicações
Objetivos da distribuição
Definir a Lista de Materiais do produto
Fazer um Plano de Implantação
Produzir o Produto
Preparar o Material de Suporte ao Usuário
Desenvolver o software de instalação
Produzir as notas da versão (release)
Preparar os materiais de treinamento
Disponibilizar o software para os usuários
Márcio Moreira
3. Processo de Desenvolvimento – slide 44
Segurança em Aplicações
Fluxo de trabalho de distribuição
Márcio Moreira
3. Processo de Desenvolvimento – slide 45
Segurança em Aplicações
Objetivos das atividades
 Planejar a Implantação:
 Planejar quando e como o produto será distribuído
 Desenvolver Material de Suporte:
 Preparar os materiais necessários para suporte aos usuários
 Gerenciar Testes de Aceitação:
 Garantir a aceitação do software pelos clientes antes do lançamento geral
 Produzir a Unidade de Implantação:
 Empacotar o produto de forma que ele seja instalável
 Produto para Beta Teste:
 Liberar o software para usuários beta e tratar seus feedbacks
 Gerenciar Teste de Aceitação para Instalação Customizada:
 Especialização de Gerenciar Testes de Aceitação
 Empacotar Produto:
 Preparar um produto para que ele seja comprável em lojas
 Fornecer Acesso ao Site de Download:
 Disponibilizar o software para download na Internet
Márcio Moreira
3. Processo de Desenvolvimento – slide 46
Segurança em Aplicações
Essência da distribuição
Preparação:
• Plano de Implantação
• Lista de Materiais, Ilustração e Artefatos de Instalação
• Materiais de Treinamento e Suporte
Testes:
• Ambiente de testes
• Controle de Mudanças
• Resultados e Avaliação dos Testes
Distribuição:
• Notas de versão (release)
• Unidade de Implantação
• Produto
Márcio Moreira
3. Processo de Desenvolvimento – slide 47
Segurança em Aplicações
Conceitos de GCM
 Configuração:
 Conjunto de requisitos (funcionais ou não) atendidos por uma
versão do software
 Mudanças:
 Qualquer alteração em artefatos (produtos do trabalho) já validados
 Linha Base:
 Conjunto formado pela configuração e artefatos que compõem uma
versão do software
 É altamente recomendável a utilização de um software de controle
de versões (SubVersion, SourceSafe, etc.) para gerir a linha base
 Benefícios da GCM:
 Controle de artefatos evitando problemas de: atualização
simultânea, notificação limitada (alguns não ficam sabendo da
alteração) e múltiplas versões
Márcio Moreira
3. Processo de Desenvolvimento – slide 48
Segurança em Aplicações
Objetivos da GCM
 Suportar métodos de desenvolvimento
 Manter a integridade do produto
 Assegurar a integralidade e correção do produto
configurado
 Fornecer um ambiente estável dentro do qual se
possa desenvolver o produto
 Restringir as alterações nos Produtos de Trabalho
(artefatos) de acordo com as políticas do projeto
 Fornecer uma auditoria acompanhando o porque,
quando e por quem foi feita alteração nos artefatos
Márcio Moreira
3. Processo de Desenvolvimento – slide 49
Segurança em Aplicações
Fluxo de trabalho da GCM
Márcio Moreira
3. Processo de Desenvolvimento – slide 50
Segurança em Aplicações
Objetivos das atividades
 Planejar o Controle de Mudança e Configuração do Projeto:
 Como serão tratadas as mudanças nos artefatos no desenvolvimento do
software
 Criar Ambientes para CM (Gerenciamento de Configuração) do Projeto:
 Disponibilizar um ambiente onde o produto possa desenvolvido e
disponibilizado
 Gerenciar Solicitações de Mudança:
 Garantir que as mudanças aprovadas sejam feitas de forma consistente no
projeto
 Monitorar e Relatar o Status de Configuração:
 Dar visibilidade para as alterações de configuração do produto
 Alterar e Liberar Itens de Configuração:
 Gerenciar os artefatos do projeto entregues e disponibilizados pelo projeto
 Gerenciar Baselines e Releases:
 Garantir que uma release seja uma baseline consistente de artefatos
Márcio Moreira
3. Processo de Desenvolvimento – slide 51
Segurança em Aplicações
Essência da GCM
Preparação:
• Plano de Gestão de Configuração
• Repositório de Projeto e Espaço de Trabalho
• Controle de Mudanças
Mudanças:
• Plano de Desenvolvimento do Software
• Plano de Iteração
• Ordem de Trabalho
Avaliações:
• Métricas de Projeto
• Registro de Auditoria de Configuração
Márcio Moreira
3. Processo de Desenvolvimento – slide 52
Segurança em Aplicações
Objetivos da gestão de projetos
 Inseridos no RUP:
 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
 Não tratados pelo RUP:
 Gerenciamento de pessoas: contratar, treinar, instruir
 Gerenciamento de orçamento: definir, alocar e assim por
diante
 Gerenciamento de contratos, com fornecedores e clientes
 Para gestão de projetos completa: recomendação PMI
Márcio Moreira
3. Processo de Desenvolvimento – slide 53
Segurança em Aplicações
Fluxo de trabalho da gestão projetos
Márcio Moreira
3. Processo de Desenvolvimento – slide 54
Segurança em Aplicações
Objetivos das atividades 1
 Conceber Novo Projeto:
 Levar o projeto da idéia à decisão de continuar ou abandonar o projeto
 Avaliar Risco e Escopo do Projeto:
 Reavaliar o escopo e o risco do projeto e atualizar o Caso de Negócios
(Business Case)
 Planejar o Projeto:
 Desenvolver os componentes e seções do Plano de Desenvolvimento do
Software
 Planejar o Restante da Iteração Inicial:
 Detalhar o Plano de Iteração para conduzir o restante da iteração inicial
 Gerenciar Iteração:
 Iniciar, finalizar e revisar uma iteração
 Reavaliar Escopo e Risco do Projeto:
 Reavaliar o escopo e o risco do projeto e atualizar o Caso de Negócios
(Business Case)
Márcio Moreira
3. Processo de Desenvolvimento – slide 55
Segurança em Aplicações
Objetivos das atividades 2
 Monitorar & Controlar Projeto:
 Lançar o trabalho diário, monitorar o status do projeto, relatar a
situação para envolvidos e lidar com os problemas
 Planejar Próxima Iteração:
 Detalhar o Plano de Iteração para conduzir a próxima iteração
 Refinar o Plano de Desenvolvimento:
 Refinar, quando necessário, o Plano de Desenvolvimento do
Software
 Fechamento de Fase:
 Fechar uma fase assegurando que os objetivos dela foram atingidos
 Fechamento do Projeto:
 Fechar o projeto assegurando que os objetivos dele foram atingidos
Márcio Moreira
3. Processo de Desenvolvimento – slide 56
Segurança em Aplicações
Essência da Gestão de Projetos
Planejamento:
• Caso de Negócio (Business Case)
• Plano de Desenvolvimento do Software
• Plano de Iteração
Execução:
• Lista de Riscos
• Lista de Problemas
• Ordem de Trabalho
Monitoramento e Controle:
• Registro de Revisão
• Avaliação de Status
• Avaliação de Iteração
Márcio Moreira
3. Processo de Desenvolvimento – slide 57
Segurança em Aplicações
Conceitos
 Ambiente:
 Tudo aquilo que o projeto
necessita para desenvolver e
implementar o software, tais
como: processo, orientações,
ferramentas, modelos e infraestrutura (hardware e
software)
 Ambiente de
desenvolvimento:
Individual (Espaço
de Trabalho)
Desenvolvimento
Integração
(Repositório)
Sistemas
Infra-estrutura dos
Ambientes
 Ambiente aplicado à
implementação do software
Testes
Integrados
Performance e
Aceitação
Produção
Produção
 Ambiente de testes:
 Ambiente aplicado aos testes
Márcio Moreira
3. Processo de Desenvolvimento – slide 58
Segurança em Aplicações
Funções envolvidas
 Administrador de Sistemas:
 Responsável pela infra-estrutura do ambiente
 Especialista em Ferramentas:
 Seleciona, adquire, instala e suporta as ferramentas necessárias
 Engenheiro de Processos:
 Responsável pelo processo a ser aplicado ao desenvolvimento
Márcio Moreira
3. Processo de Desenvolvimento – slide 59
Segurança em Aplicações
Objetivos da disciplina de ambiente
Fornecer a organização do desenvolvimento
bem como o ambiente (processos e
ferramentas) que suportarão a equipe de
desenvolvimento do projeto
Fornecer e manter todos os ambientes
necessários ao desenvolvimento do projeto
Em linha gerais, podemos dizer que a
disciplina de ambiente suporta todas as
outras
Márcio Moreira
3. Processo de Desenvolvimento – slide 60
Segurança em Aplicações
Fluxo de trabalho de ambiente
Márcio Moreira
3. Processo de Desenvolvimento – slide 61
Segurança em Aplicações
Objetivos das atividades
Preparar ambiente do projeto:
Utilizada na iniciação, com o propósito de preparar
o ambiente de desenvolvimento do projeto
Preparar o ambiente para uma iteração:
Adequar o ambiente de desenvolvimento do
projeto para uma iteração
Suportar o ambiente durante uma iteração:
Garantir que todas as demandas de processos e
ferramentas sejam atendidas durante uma
iteração do projeto
Márcio Moreira
3. Processo de Desenvolvimento – slide 62
Segurança em Aplicações
Essência da disciplina de ambiente
Preparação do Projeto:
•
•
•
•
Processo de Desenvolvimento
Caso de Desenvolvimento
Diretrizes e Templates Específicas do Projeto
Ferramentas
Preparação de Iteração:
•
•
•
•
•
Caso de Desenvolvimento
Diretrizes e Templates Específicas do Projeto
Requisições de Mudança
Manual de Guia de Estilo
Ferramentas
Suporte de Iteração:
• Infra-estrutura de Desenvolvimento
Márcio Moreira
3. Processo de Desenvolvimento – slide 63
Segurança em Aplicações
Referências
Sigla
Referência
FER08
Fernando Dantas. Resumo do livro: The Rational Unified Process Made Easy.
www.fernandodantas.com.br . 2008.
JAC98
Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process.
1998. Addison Wesley Longman.
KRO03
Per Kroll e Philippe Kruchten 2003. The Rational Unified Process Made Easy, A Practitioners Guide
to the RUP. Addison Wesley Longman.
KRU98
P. Kruchten; The Rational Unified Process: An Introduction, Object Technology Series, AddisonWesley, 1998.
MAR05 Márcio Moreira. Resumo do livro Unified Process. Márcio. Uberlândia (MG). 2005.
MAR06
Márcio Moreira. Engenharia de Software - RUP . Uniube - Universidade de Uberaba - Uberlândia
(MG). 2006.
PRE95 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books. 1995.
RUP08
IBM Rational. RUP – Rational Unified Process – 7.5 – For Large and Small Projects. 2008. IBM
Rational.
SUM07 Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007.
Márcio Moreira
3. Processo de Desenvolvimento – slide 64
Segurança em Aplicações