Metodologia e Conceitos de Implantação
de Sistemas
Márcio Moreira – 28/7/2009
[email protected]
Evolução das Engenharias de TI
Até 1969
Ciclo Cascata
Década de 70
Incremental
Década de 80
Evolutivo e Espiral
Década de 90
Engenharia
de Software
Iterativo & Incremental
Atualmente
Engenharia
de
Implantação
Engenharia
de
Transição
Fontes: BEI90, CAR98, KRU98, MYE79, PRE95 e SUM07
Metodologia de Implantação
Definição
Descoberta
Desenho
Construção
Teste
Treinamento
Migração
Transição Tecnológica
Distribuição
•Estruturar e planejar os inícios dos projetos
•Definir processos e requisitos de negócio
•Arquitetar, projetar e especificar as soluções
•Configurar, parametrizar e customizar softwares
•Testar unidades, sistemas, integrações e aceitação
•Capacitar analistas e usuários dos softwares
•Migrar dados dos softwares legados para os novos
•Entregar os softwares para a área de operação de TI
•Entregar, assistir e garantir softwares em produção
Principais artefatos de cada etapa
Etapa
Artefato
Definição
Plano do Projeto
Cronograma
Templates (modelos)
Lista de Entregáveis
Descoberta
Pain Points
Requisitos
Processos
Guias de Desenvolvimento
Matriz de Rastreabilidade
Desenho
Construção
Estrutura de Produtos
Blue Print
BD (Desenho de Negócio)
Matriz de Rastreabilidade
TD (Desenho Técnico)
TD de Interface
Controle de Acessos
Drops e Builds
Matriz de Rastreabilidade
Etapa
Artefato
Teste
Estratégia de Testes
Plano de Testes
Casos de Testes
Relatórios de Execução
Treinamento
Estratégia de Treinamento
Plano de Capacitação
Materiais de Treinamento
Certificados
Migração
Estratégia de Migração
Planos de Migração
Mapeamento de Dados
ETL (Extratores,
Transformadores e
Carregadores)
Auditores de Migração
Transição
Tecnológica
Estratégia de Transição
Planos de Transição
Distribuição
Planos de Distribuição
Manuais
Etapas & atividades da metodologia
Definição
Iniciação
Descoberta
Pain Points
Processos
Requisitos
Desenho
Arquitetura de
Solução
Desenho de
Negócio
Projeto de
Integração
Desenho
Técnico
Construção
Construção
Teste
Unitário
Sistema
Integrado
Aceitação
(UAT)
Treinamento
Técnico
Multiplicador
Usuário Final
Migração
Levantamento
Análise e
Detalhamento
Construção
Testes de
Migração
Diagnóstico
de Dados
Transição
Tecnológica
Definição da
Estratégia
Estratégia de
Operação
Competências
Ambientes
Processos
Distribuição
Transição
(Ambiente)
Deploy
(Instalação)
Go Live
Operação
Assistida
Garantia
Implementação
Conceitos de Descoberta (Discovery) 1/2
 Pain Points:
 Conjunto de pontos de dor que os gestores e a
corporação tinham e que impediam a fluidez e o
bom funcionamento da corporação na época.
 Serviu de base para a definição de processos e
requisitos.
Grupos de
processos
Processos
 Processos:
 Conjunto de funções de negócio, mapeadas até o
nível de atividades, seguindo o modelo e a
arquitetura eTOM e complementado pelo modelo
ITIL nos processos de Garantia de Qualidade
(Assurance).
 Transação:
• Conjunto de atividades dos processos que representam
uma interação do cliente com a empresa.
• Ex.: Prover Novo Serviço, Mudança de Endereço, etc.
Atividades
Tarefas
Instruções
de
Trabalho
Conceitos de Descoberta (Discovery) 2/2
 Requisitos:
 “Descreve uma condição ou capacidade que o sistema deve
suportar. Eles podem ser derivado de necessidades, contratos,
padrões, especificações ou imposições” (JAC98).
 Classificações (GRA92 e IE610.12):
• Funcionais:
– “Ações que o sistema deve ser capaz de executar, sem levar em conta
restrições físicas. Também descrevem o comportamento de entrada e
saída do sistema.”
– Normalmente associados a: funcionalidades e usabilidade.
• Não funcionais:
– “Descrevem atributos do sistema ou do ambiente do sistema”.
– Normalmente associados a: confiabilidade, performance, suportabilidade,
projeto, implementação, interface, físicos, etc.
 No programa:
• Os requisitos devem ser escritos no nível de requisitos (necessidade) de
negócio, não entrando em detalhes técnicos (estes podem ser chamados de
requisitos técnicos) nem no mérito da solução.
Conceitos de Desenho 1/2
 Arquitetura de Solução:
 Como as responsabilidades dos
requisitos devem ser divididas entre
os sistemas envolvidos, tomando-se
como base as transações do processo
de negócio e os fluxos de integração
entre os sistemas, resultando no Blue
Print.
eTOM
ITIL
Pain Points
Processos
Requisitos
Blue Print
 Desenho de Negócio:
 Como os requisitos de negócio e a
solução definida no Blue Print devem
ser implementados em cada sistema.
 Cada documento deve explicitar as
regras de negócio e telas envolvidas,
além dos fluxos básicos e
alternativos da solução.
Desenho
de Negócio
Especificação
de Interface
Desenho
Técnico
D. Técnico
de Interface
Build
Know
How
Processos
Conceitos de Desenho 2/2
Especificação
Completa
Desenho
 Projeto de Integração:
Requisitos
de Negócio
Desenho
Técnico
 Projeto das integrações especificadas no Blue Print que serão
implementadas entre os sistemas.
 Cada integração é descrita num documento de Especificação de Interface,
separando-se as interfaces de entrada (inbound) e saída (outbound)
descrevendo-se a especificação dos contratos (XSD, XML e WSDL)
associados.
 Desenho Técnico:
 Documentos de Desenho Técnico:
• Especificação técnica das soluções definidas nos Desenhos de Negócio
detalhando: camada de apresentação (telas, visões, applets, etc.), camada de
controle (objetos e componentes de negócio, fluxos de trabalho, regras,
máquinas de estado, etc.) e camada de persistência (entidades e modelo de
dados).
 Documentos de Desenho Técnico de Interfaces:
• Especificação técnica das interfaces de integração dos sistemas detalhando os
serviços (de negócio e de Internet), fluxos de trabalho, agendamento, carga e
extração de dados.
Customi
zação
Conceitos de Construção 1/2
Configu
ração
Parametrizaç
ão
 Construção:
 São configurações, parametrizações e customizações no
software guiadas pelos Desenhos de Negócio e Técnico.
 Configuração/Parametrização:
• “Ação de determinar parâmetros em um determinado sistema
através da inserção, alteração e remoção de dados em
campos e atributos nativos do próprio sistema”.
 Customização:
• “Alterações, supressões ou inclusões no código fonte e/ou
alterações no modelo de dados da aplicação, bem como a
utilização de objetos, parâmetros, funcionalidades ou modelo
de dados para atender requisitos para os quais a aplicação
não foi projetada, ou ainda qualquer outra alteração que
impeça ou dificulte a migração para novas versões da
aplicação”.
Conceitos de Construção 2/2
 Build:
 “Versão operacional (instalável) de um software, ou de
parte dele, que demonstra um sub-conjunto de
funcionalidades (capacidades) oferecidas no produto final
(software)” (RUP03).
 Os Builds devem fazer parte do controle de configuração
(versões do software), pois fornecem um ponto de revisão
das entregas do software e ajudam a resolver questões de
instalações, configuração, integração, etc.
 Drop:
 Neste programa, representa uma iteração (GIL88) na
etapa de Construção, onde um conjunto de funcionalidades
do software são escolhidas para serem entregues em um
ou mais Builds.
Conceitos de Testes 1/3
 Caso de Teste:
 “Especificação formal de entradas, condições e resultados
esperados, identificados com o propósito de avaliar um ou
mais aspectos de um determinado item do software”
(RUP03).
 Passos dos Casos de Teste (Test Script):
• “Instruções detalhadas para realização de cada etapa do Caso
de Teste” (RUP03).
 Cenários dos Casos de Teste:
• Identificação das variações (tipos de: clientes, produtos, etc.)
cada Caso de Teste deve ser executado.
 Unidade (RUP03):
 Menor elemento (parte) com o qual cada desenvolvedor
pode trabalhar, usualmente um componente do software.
Conceitos de Testes 2/3
 Teste Unitário (RUP03):
 Teste realizado com cada unidade testável do software.
 Normalmente é executado pelo próprio desenvolvedor e envolve
teste de funcionalidades e de controle de fluxo.
 Teste de Sistema (RUP03):
 Teste realizado com o software inteiro funcionando.
 Utilizando um ciclo iterativo de desenvolvimento é possível
executar este teste com parte do software pronto.
 Teste Integrado (RUP03):
 Teste realizado com a integração (acoplamento) de módulos
(pacotes ou sub-sistemas) de um mesmo software.
 Testa interfaces e não deve ser executado por desenvolvedores.
 No programa:
• Consideramos cada software como um módulo e estamos testando a
integração dos vários softwares.
Conceitos de Testes 3/3
 Teste de Aceitação (UAT: User Acceptance Test):
 Teste executado por usuários para verificar se o software
está pronto para ser distribuído e utilizado pelos demais
usuários na realização de suas atividades (RUP03).
 Podem ser feitos de forma (RUP03):
• Formal:
– Seguindo uma seqüência de Casos de Testes planejados.
• Informal (aleatória ou ad hoc):
– O teste é feito de forma livre, exploratória ou aleatória, ou seja,
não segue uma seqüência pré-definida.
 Teste de Regressão (RUP03):
 Execução repetida dos Casos de Testes que falharam, bem
como os Casos de Testes impactados por eles, após a
correção dos erros que causaram as falhas.
Conceitos de Treinamentos
 Treinamentos Técnicos:
 Capacitação de Analistas de Sistemas e de Negócios para
realização de suas atividades no projeto ou na Operação
do Software.
 Normalmente, ministrados por fabricantes ou integradores.
 Treinamentos de Multiplicadores:
 Capacitação de usuários quem tenham habilidade
multiplicar aos usuários finais os conhecimentos adquiridos
sobre a utilização do software.
 Normalmente, ministrados pelos integradores.
 Treinamentos de Usuários:
 Capacitação dos usuários finais na utilização do software.
 Normalmente, ministrados pelos multiplicadores.
Conceitos de Migração 1/2
 ETL (Extract, Transform and Load)(KIM04):
 Extração:
• Leitura dos dados nos legados, conversão destes em
um esquema intermediário e cópia para área
intermediária (base de extração).
 Transformação:
• Limpeza, adequação (transformação), validação dos
dados aos domínios (tipos, formatos, etc.) destinos ou
geração de erros.
• Limpeza:
– Inclui a definição de valores padrões, tratamento de dados
ausentes, campos obrigatórios, únicos, etc.
– Uma parte significativa pode e deve ser feita nos legados.
 Carga:
• Colocação dos dados válidos nos respectivos destinos.
• Envolve criação de registros, gestão de agregações e a
carga destes.
Legados
Extração
Extraídos
Limpeza
Transformação
Validação
Validados
Carga
Destinos
Conceitos de Migração 2/2
 Mapeamento dos dados:
 Identificação, à partir do destino, de quais atributos de origem
(legados) representam quais atributos de destino.
 Auditoria de dados:
 Verificação se os dados de origem passaram por todas etapas do
processo de migração até chegar ao destino.
 Construção de Migração:
 Construção das ferramentas: extratores, transformadores,
carregadores, auditores, etc.
 Testes de Migração:
 Verificação se ferramentas construídas estão realizando o
trabalho como deveriam.
 Diagnóstico de Dados:
 Verificação e execução de rotinas de limpeza, adequação e
inclusão de dados nos sistemas legados.
Conceitos de Transição
Tecnológica
 Transição Tecnológica (CAR07):
 Conceito ITIL que refere-se à entrega de um projeto para a área
de operações de TI.
• Envolve gestão de: mudanças na infra-estrutura de TI, riscos e
garantia de qualidade dos serviços de TI.
• Deve ser planejado para entregar não só as aplicações testadas, mas
também transferir o conhecimento.
 No programa foram tratadas as seguintes dimensões:
• Ambientes:
– Infra-estrutura, Sistemas Operacionais, Bancos de Dados e Aplicações.
• Processos:
– Transição (operação assistida, bugs, etc.), gestão (demandas, defeitos,
etc.) procedimentos (instruções de trabalho) e operação.
• Competências:
– Capacitação, treinamentos, transferência de know how, perfis e pessoas.
• Administração financeira:
– Contratos, licenças, associados e espaço físico.
Conceitos de Distribuição
(Deployment)
 Transição (implantação)(RUP03):
 Preparação das condições (infra, documentação, etc.) necessárias
para colocação do software no ambiente e em ritmo de produção.
 Deploy (RUP03):
 Ação de instalação do software num determinado ambiente.
 Go Live (colocar em produção):
 Execução dos procedimentos das mudanças (changes ITIL) para
colocação do software em produção.
 Operação Assistida:
 Período no qual os integradores e a equipe do projeto devem
apoiar a equipe de Operação de TI. Normalmente 30 dias.
 Garantia:
 Período no qual os integradores devem oferecer gratuitamente a
correção de erros nos softwares. Normalmente 90 dias.
Referências
Sigla
Referência
BEI90
BEIZER, Boris. Software testing techniques. Scottdale: Coriolis Group, 1990, 2 ed.
CAR98
CARZANIGAYZ, A., et. al. A Characterization Framework for Software Deployment Technologies.
Technical Report CU-CS-857-98, University of Colorado, April 1998.
CAR07
CARTLIDGE, A., HANNA, A., & et al. An Introductory Overview of ITIL V3. London: itSMF UK.
2007. http://www.itsmfi.org/files/itSMF_ITILV3_Intro_Overview_0.pdf.
GIL88
Tom Gilb. Principles of Software Engineering Management. 1988. Harlow, England: Addison
Wesley Longman
GRA92
Robert Grady. Practical Software Metrics for Project Management and Process Improvement.
1992. Prentice-Hall.
IE610.12
IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. The
Institute of Electrical and Electronics Engineers, Inc.: New York, NY, 10017-2394, USA. 1990.
JAC98
Ivar Jacobson, Grady Booch, and James Rumbaugh. The Unified Software Development Process.
1998. Addison Wesley Longman.
KIM04
Kimball, Ralph; Joe Caserta. The Data Warehouse ETL Toolkit. Wiley. 2004. ISBN 0-7645-6757-8.
KRU98
P. Kruchten; The Rational Unified Process: An Introduction, Object
Technology Series, Addison-Wesley, 1998.
MYE79
MYERS, Glenford J. The art of software testing. New York: John Wiley & Sons, 1979.
PRE95
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books. 1995.
RUP03
Rational Software. RUP – Rational Unified Process. 2003. Rational Software Corporation and IBM.
SUM07
Sommerville, Ian. Engenharia de Software. 8ª Ed. Pearson / Prentice Hall. 2007.
Obrigado!