1 / 21

Metodologia e Conceitos de Implantação de Sistemas Márcio Moreira – 28/7/2009 marcio.moreira@uniminas.br

Metodologia e Conceitos de Implantação de Sistemas Márcio Moreira – 28/7/2009 marcio.moreira@uniminas.br. Evolução das Engenharias de TI. Análise Clássica A. Estruturada A. Essencial Modelagem O. Objeto. Engenharia de Software.

lieu
Download Presentation

Metodologia e Conceitos de Implantação de Sistemas Márcio Moreira – 28/7/2009 marcio.moreira@uniminas.br

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Metodologia e Conceitos de Implantaçãode SistemasMárcio Moreira – 28/7/2009marcio.moreira@uniminas.br

  2. Evolução das Engenharias de TI Análise Clássica A. Estruturada A. Essencial Modelagem O. Objeto Engenharia de Software Programação Procedural P. Estruturada Orientada a Eventos O. Objetos Engenharia de Implantação Ciclo Cascata Incremental Evolutivo e Espiral Iterativo & Incremental Engenharia de Transição Testes: Depuração Profissionalização Qualidade Total Automação Instalação Artesanal Instaladores Distribuidores Empirismo Transição (RUP/ITIL) Fontes: BEI90, CAR98, KRU98, MYE79, PRE95 e SUM07

  3. Metodologia de Implantação

  4. Principais artefatos de cada etapa

  5. Etapas & atividades da metodologia

  6. 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. • 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. Grupos de processos

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

  8. Conceitos de Desenho 1/2 eTOM ITIL Know How • 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 Requisitos Blue Print Desenho de Negócio Especificação de Interface Desenho Técnico D. Técnico de Interface Build

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

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

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

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

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

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

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

  16. Conceitos de Migração 1/2 Legados • 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. Extração Extraídos Limpeza Transformação Validação Validados Carga Destinos

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

  18. 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 knowhow, perfis e pessoas. • Administração financeira: • Contratos, licenças, associados e espaço físico.

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

  20. Referências

  21. Obrigado!

More Related