Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

A Informação em Perspectiva

O Projeto EAGLE e os seus Dados

Contexto, premissas e principais artefatos

Principais processos e responsabilidades

Principais Axiomas e Postulados Estruturais

Principais Axiomas e Postulados Funcionais

O Projeto EAGLE e os Databases

Índice

O Projeto EAGLE e os Databases

Descrevemos aqui como pretendemos instrumentalizar o comportamento do EAGLE em relação à criação de novos databases corporativos; à alteração de databases previamente registrados no EAGLE; bem como na incorporação de databases (e sistemas) legados [preexistentes à iniciativa de adoção do EAGLE].

clipNote

Oportunamente criaremos diagramas UML (de atividades, colaboração etc.) dos processos aqui descritos, a fim de facilitar o seu entendimento.

Cenário 1 – Green Field: Começando do zero

Nas fases de posicionamento e engenharia:

  • DDP – Data Definition Process. Através de uma ferramenta de suporte (DDST – Data Definition and Simulation Tool), o DHTD é atualizado.
    • O DHTD pode ser atualizado via texto [Linked In Profile edit UI] e/ou interface gráfica [drag-drop & define visual objects].
    • O Modelo de Dados [ERM – Entity Relationship Model] gerado pela interface gráfica pode ser salvo e/ou impresso.
    • Scripts estruturais (CREATE DATABASE, CREATE TABLE etc.) e de inclusão de dados fixos [enums] são gerados.
  • MDP – Mock Data Definition Process. Através do DDST, o responsável pelos DB de testes/QA gera, para cada [definição de] caso de testes, um MDG – Mock Data [Set] Group correspondente, que contém um ou mais MDS – Mock Data Set.
    • Para cada MDS um script de inclusão (cenário) é criado (INSERT INTO…)
    • Ao final, o responsável adiciona os scripts, juntamente com os casos de testes, ao DHTD.
  • Registros MDS podem ser tanto automaticamente gerados como manualmente definidos.
  • Smoke Tests são opcionais.
  • Uma vez definida e aprovada a estrutura dos dados, ela permanecerá imutável durante todo o ciclo de desenvolvimento (iteração).
  • Aqui, todas as atividades sob a responsabilidade das equipes de desenvolvimento, testes, QA e delivery podem ser simuladas.
  • Uma vez que uma simulação é gerada, executada e aprovada, a mesma se torna requerimento formal para UAT – User Acceptance Tests
  • A fase de desenvolvimento não pode ser iniciada até que que a estrutura de dados seja aprovada.
  • A fase de testes não pode ser iniciada até que os casos de testes (com ou sem os seus respectivos scripts de inclusão) para a iteração sejam definidos e aprovados.

Na fase/ambiente de desenvolvimento (coding):

  • Um DB vazio é gerado automaticamente a partir das definições do DHTD.
    • Scripts estruturais são gerados e executados.
    • Um script de inclusão de dados fixos é executado. DB vazios podem conter dados.

      Exemplo: O DHTD pode definir algo como DoorState {0:Unknown; 1: Locked; 2: Closed; 3:Opened}; mapeados para DoorState, ID {int, PK}; Description {varstring, 10}. Neste caso, o DB “vazio” já “nasce” com os quatro registros definidos devidamente inseridos na tabela.

  • Scripts de limpeza são gerados.
  • Quando um novo Kit MVO é criado, pelo responsável pela equipe de desenvolvimento:
    • Os scripts e diagramas gerados tanto aqui como nas fases anteriores são automaticamente adicionados ao kit, em um sub-pacote [envelope? laço? pasta?]

Na fase/ambiente de testes:

  • Os scripts estruturais são executados.
  • O script de inclusão de dados fixos é executado.
  • Nem os casos de teste previamente gerados nem os seus correspondentes scripts podem ser alterados.
  • Novos casos de teste, MDG e MDS podem ser criados e inseridos no kit.
  • Quando um caso de teste é executado:
    • No início, o DB é reinicalizado (DROP TABLES, CREATE TABLE etc), e o script de inclusão correspondente é executado.
    • No final, um script de “estado” (snapshot) é gerado e anexado automaticamente às evidências de teste.
    • O kit pode ser configurado para coletar as evidências relacionadas a todas as execução de testes, ou apenas à mais recente (default). Este parâmetro só pode ser configurado na criação do pacote (não pode ter o seu valor alterado), devendo portanto ter o seu valor definido no documento de planejamento do projeto.
    • Ainda que o kit contenha apenas a última evidência de teste, o DB do QAF manterá todas as anteriores.

Nas fases/ambientes de QA (interno e cliente):

  • Como na fase/ambiente de testes.
  • Todos os casos de testes podem ser executados. A cada nova execução um snapshot é gerado.
  • Os casos de testes são aprovados ou rejeitados.
  • O pacote é aprovado ou rejeitado.
  • O pacote só poderá ser aprovado se todos os seus casos de testes forem aprovados.
  • A equipe do QA interno deverá executar outras atividades – validar a qualidade do código etc. – antes de encaminhar o kit para aprovação do cliente.

Na fase de deploy em ambientes de produção:

  • Os scripts estruturais são executados.
  • O script de inclusão de dados fixos é executado.
  • Smoke Tests são executados.

Cenário 2 – Blue Field: Atualizando pacotes previamente certificados (manutenção evolutiva ou corretiva, versionamento)

Nas fases/ambientes de posicionamento e engenharia:

  • Como no Cenário 1, só que:
    • Aqui, o DDP detecta que já existe uma versão do DB implementado (deployed) e [potencialmente] em uso:
      • O DDP valida o DHTD conforme os scripts apropriados (pertencentes ao KCDA – kit [do ciclo de desenvolvimento] anterior)
        Se o DHTD não é validado, vários alarmes [vermelhos] soam, vários e-mails e SMS são encaminhados, e o processo é abortado.
      • O DDP valida o DB implementado conforme as definições do DHTD
        Se o DB não é validado, alarmes e-mails, SMS, e o processo é abortado.
    • O DDP gera uma cópia da estrutura do DB, bem como de seus dados no DHTD (a nova versão)
    • O DDP permite a alteração do “schema” da nova versão do DB, em um ambiente gráfico especializado (onde tanto a versão atual como a nova [versão], com seus respectivos scripts, são apresentados lado a lado).
    • Registros MDS podem ser:
      • Automaticamente gerados
      • Manualmente definidos
      • Importados do KCDA
      • Gerados automaticamente a partir de um subset dos dados do DB de produção
    • Um script de alteração de estrutura é gerado
    • Smoke testes são obrigatórios.
    • O DDP versiona os dados do DHTD de acordo com as informações fornecidas.

Nas fases/ambientes de desenvolvimento (coding), testes, e QA (interno e cliente):

  • Como no Cenário 1

Na fase de deploy em ambientes de produção:

  • Um backup do DB é gerado
  • O script de alteração de estrutura é executado
  • Smoke Tests são executados.

Cenário 3 – Gray Field: Certificando recursos de negócio (produtos, processos, serviços) legados

Nas fases/ambientes de posicionamento e engenharia:

  • Como no Cenário 1, só que aqui, com relação aos dados:
    • O responsável pela transição informa a localização do(s) DB(s) apropriados (legados);
    • O DDP gera os scripts apropriados a partir da estrutura do(s) DB(s)
    • Registros MDS podem ser:
      • Automaticamente gerados
      • Manualmente definidos
      • Gerados automaticamente a partir de um subset dos dados do DB de produção
      • Smoke testes são obrigatórios
    • O DDP atualiza e versiona o DHTD
  • E com relação ao projeto (solução):
    • Toda a hierarquia de dependência (downstream [de quem eu dependo?]) é verificada.
      • Se todas as suas referências [já] tiverem sido certificadas, a classificação da certificação será maior, determinada de acordo com as suas outras características
      • Caso contrário, a classificação será inferior; e comprovará que a solução não está totalmente sob controle (monitoramento) e, portanto, oferece riscos.

Nas fases/ambientes de desenvolvimento (coding), testes, e QA (interno e cliente):

  • Como no Cenário 1

Na fase de deploy em ambientes de produção:

  • Backup(s) do(s) DB(s) é/são gerados
  • Smoke Tests são executados.

Note que, neste cenário, a verificação mencionada nas primeiras fases (em negrito) faz com que a classificação das certificações garantidas pelo EAGLE sejam dinâmicas (e flexíveis?). Se a solução A passa pelos critérios da verificação e recebe uma classificação “superior”, outras soluções (B e C) – previamente classificadas como “de risco” exclusivamente em função de suas dependências de A – estão agora aptas a receber uma classificação “superior”, de acordo com as suas características particulares.

Nestes casos, de acordo com os parâmetros de configuração definidos tanto em B e C, como para a toda a empresa (ou unidade de negócio):

  • B e C podem ser automaticamente “promovidas”; com a geração automática de novas certificações, selos, notificações (e-mail, SMS, etc.) aos stakeholders apropriados etc (CANS –Certificação Automática e Notificação a Stakeholders)
  • Os stakeholders apropriados podem ser notificados e os responsáveis (custodians) por B e C “convidados” a submeterem as mesmas a um novo processo de avaliação/certificação.

IMPORTANTE: Essas opções só serão oferecidas e respeitadas nos casos de promoção. Casos de demoção de status [que podem ocorrer em outros cenários] serão peremptórios:

  • Demoção automática e CANS
  • Verificação de toda a hierarquia de dependências upstrastream [quem depende de mim?].
↑ Topo ↑
 
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: