Metodologia e Conceitos de Implantaçãode Sistemas

Márcio Moreira – 28/7/2009

marcio.moreira@uniminas.br

Até 1969 Década de 70 Década de 80 Década de 90 Atualmente

Evolução das Engenharias de TIAnálise Clássica

A. Estruturada

A. EssencialModelagem O. Objeto

Programação Procedural P. Estruturada Orientada a Eventos O. Objetos

Testes: DepuraçãoProfissionalização

Qualidade TotalAutomaçãoCiclo Cascata Incremental Evolutivo e Espiral Iterativo & Incremental

Fontes: BEI90, CAR98, KRU98, MYE79, PRE95 e SUM07

Engenharia de Software

Instalação ArtesanalInstaladores

DistribuidoresEmpirismo

Transição (RUP/ITIL)Engenharia

de Transição

Engenharia de

Implantação

Metodologia de Implantação

•Estruturar e planejar os inícios dos projetosDefinição

•Definir processos e requisitos de negócioDescoberta

•Arquitetar, projetar e especificar as soluçõesDesenho•Configurar, parametrizar e customizar softwaresConstrução

•Testar unidades, sistemas, integrações e aceitaçãoTeste

•Capacitar analistas e usuários dos softwaresTreinamento

•Migrar dados dos softwares legados para os novosMigração

•Entregar os softwares para a área de operação de TITransição Tecnológica

•Entregar, assistir e garantir softwares em produçãoDistribuição

Etapa Artefato

DefiniçãoPlano do ProjetoCronogramaTemplates (modelos)Lista de Entregáveis

Descoberta

Pain PointsRequisitosProcessosGuias de DesenvolvimentoMatriz de Rastreabilidade

Desenho

Estrutura de ProdutosBlue PrintBD (Desenho de Negócio)Matriz de RastreabilidadeTD (Desenho Técnico)TD de InterfaceControle de Acessos

Construção Drops e BuildsMatriz de Rastreabilidade

Principais artefatos de cada etapa

Etapa Artefato

TesteEstratégia de TestesPlano de TestesCasos de TestesRelatórios de Execução

TreinamentoEstratégia de TreinamentoPlano de CapacitaçãoMateriais de TreinamentoCertificados

Migração

Estratégia de MigraçãoPlanos de MigraçãoMapeamento de DadosETL (Extratores, Transformadores e Carregadores)Auditores de Migração

Transição Tecnológica

Estratégia de TransiçãoPlanos de Transição

Distribuição Planos de DistribuiçãoManuais

Etapas & atividades da metodologiaDefiniçã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)

Treinamen-to Técnico Multiplicador Usuário Final

Migração Levantamento Análise e Detalhamento Construção Testes de

MigraçãoDiagnóstico de Dados

Implementa-ção

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

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.

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.

Conceitos de Descoberta (Discovery) 1/2

Processos

Atividades

Tarefas

Instruções de Trabalho

Grupos de processos

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.

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.

Pain Points Processos

eTOM ITIL Know How

Requisitos

Blue Print

Desenho de Negócio

Especificação de

Interface

Desenho Técnico

D. Técnico de Interface

Build

Conceitos de Desenho 2/2 Projeto de Integração:

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.

Processos

Requisitos

Desenho de Negócio

Desenho Técnico

Especificaç

ão Completa

Conceitos de Construção 1/2

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”.

Parametrização

Configuração

Customizaçã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ídos

Validados

Destinos

Extração

LimpezaTransformaçãoValidação

Carga

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çãoTecnoló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ênciasSigla 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!