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

Principais Axiomas e Postulados Funcionais

O EAGLE deverá contemplar os seguintes requerimentos funcionais:

  • As políticas, regras de negócio e processos descritos na “Estratégia de Aquiles” – aos quais iremos aqui nos referir como FSSA – Functional Solution Suport Artifacts – serão priorizados e implementados tão logo quanto possível.
  • Tais FSSA deverão ser devidamente registrados em seus respectivos repositórios (DB). Para tanto, serão utilizados os DBSA, exclusivamente; ou seja, nenhum dado será adicionado aos DB manualmente, sem o uso de suas correspondentes UI.
  • DRCP – Definition, Registration, [Configuration] Process(es). No processo de implementação tanto dos FSSA acima mencionados como dos DBSA que os suportam, vários outros FSSA poderão/deverão ser “descobertos”. Tais FSSA devem ser igualmente definidos, registrados e configurados.

Os próximos itens são exemplos de FSSA que devem ser contemplados por este processo.

  • As UI principais da solução poderão ser acessadas tanto pelas vias normais de navegação de menus da tela principal do sistema (seja portal ou aplicação desktop), quanto direta e independentemente.
  • O AVF contempla dois distintos Mecanismos de Versionamento: o MVI – “Interno” [under development] e o MVO – “Oficial” [testado, aprovado e certificado].
  • O QAF (cf. PTI #4) contempla KPI – Key Performance Indicators DRCP+. Uma vez definidos e registrados, os KPI relacionados a determinado(s) processo(s) poderão ser configurados; para serem coletados e registrados, ou não.
    • É de responsabilidade exclusiva da equipe de desenvolvimento a criação/geração de novos pacotes, ou kits.
    • Uma vez criado um novo pacote, o seu conteúdo só pode ser acrescido; jamais alterado ou modificado. Equipes de desenvolvimento adicionam código-fonte, scripts de database, arquivos de configuração etc. Equipes de teste adicionam casos e evidências de testes; equipes de QA, manuais, SLAs, documentação etc; equipes do cliente, evidências de testes, termos de aceite etc; e assim por diante.
    • Quando um novo pacote é criado, seus correspondentes ADR e RMF são automaticamente adicionados.
    • Ao ser inserido no pacote, o item recebe uma etiqueta (ticket) que o associa ao kit. Isso garante que um item não será inserido em mais do que um kit.
    • Os itens do kit contarão com até dois tickets de identificação; o primeiro o identifica como “classificado” (pertencente a um kit MVI); o segundo, como “certificado” (kit MVO).
    • Um kit MVO não pode ter o seu conteúdo modificado. Nenhum item poderá adicionado ou removido do mesmo.
    • Quando um kit classificado é rejeitado, o motivo é devidamente registrado, a equipe de desenvolvimento toma as providências necessárias e gera um novo pacote, que referencia o pacote anterior, através de um “link” que identifica a sua precedência. Este ciclo se repete até que o pacote seja definitivamente certificado. Estes ciclos de desenvolvimento/correção internos são “governados” pelo MVI.
    • Kits certificados não são rejeitados, uma vez que já passaram por todo o percurso de desenvolvimento, validação e certificação.
    • Kits certificados, no entanto, podem ser abortados, caso algum defeito seja descoberto após a sua certificação.
    • … (retirement, version regression, green-blue development, etc.)
  • O ACP e o LAP fazem parte do processo PUR – Portfolio Update Route.
    • ACP – Asset Certification Process. É de responsabilidade exclusiva do responsável (custodian) pelo cliente garantir que o pacote aprovado pelo cliente seja submetido ao ACP, onde o kit passa pelo MVO, entre outras atividades.
    • LAP – Package Lifetime Assessment Process. Este processo automatizado avalia um determinado kit de acordo com os seus requerimentos; identificando em que ponto ele se está, no processo de certificação, bem como a classificação (selo de qualidade) por ele alcançada.
      • O LAP pode ser acionado em qualquer ponto do ciclo de vida do kit, independente (antes ou depois) do PUR.
    • Kits classificados (não-certificados) podem ter o seu status alterado (promovido ou demovido) automaticamente, ou não, de acordo com o seu correspondente parâmetro de configuração. O padrão default é a não-alteração automática do kit, o que força a aprovação do mesmo pelo seu responsável (custodian).
    • Aos kits certificados armazenados no portfólio devem sem adicionados os seus respectivos SMD e AMF
      • Kits liberados para entrega não devem conter esses artefatos
      • E esta deve ser a única diferença entre os dois

    Ambientes Corporativos

    Ainda que altamente recomendado para empresas de todos os tamanhos, o EAGLE é desenhado primariamente para grandes corporações, que usualmente possuem diferentes equipes dedicadas a diferentes funções no processo de desenvolvimento, manutenção e gerenciamento de produtos e serviços de software.

    best sign

    O pouco que sei [a única coisa, na verdade – por enquanto] sobre conformidade com o Cobit–SOX Act 2002 é o requerimento que reza que os ambientes de desenvolvimento, controle de qualidade (QA) e produção devem ser totalmente isolados um do outro.

    Então, só para lembrar e [talvez] posicionar o requerimento no local apropriado:

    • Ambientes totalmente isolados de desenvolvimento, testes, QA interno, QA externo/protegido (UAT, cliente), governança, gestão, delivery e produção deverão ser implementados para testar e homologar os processos, repositórios e requerimentos do EAGLE.
    • Nesta fase de desenvolvimento (PoC, protótipo, MVP) este requisito será implementado da seguinte forma:
      • Maquinas e redes virtuais simularão os ambientes mencionados
      • AGP – Asset Governance Portal. Uma aplicação web (intranet/extranet), disponibilizada pelo ambiente de governança, servirá de “canal de comunicação” entre os demais ambientes e o EAGLE
        • Ainda estamos considerando se o Core (Kernel) do EAGLE ficará centralizado (neste caso, provavelmente no ambiente de governança) ou distribuído (em um “modelo” mais holográfico, “fractal”)
      • O ambiente de governança será responsável pela “orquestração” dos processos e manutenção dos artefatos e recursos (assets) de negócio; e hospedará tanto o portfólio corporativo quanto os processos AMR – Asset Monitoring Route e CMR – Corporate Messaging Route.

    Uma das responsabilidades (atividades) do ACP é classificar o pacote de acordo com estes ITGF, gerar a documentação correspondente e adicioná-la ao pacote; juntamente com o selo de certificação de qualidade do EAGLE (ECPS – EAGLE Certified Package Seal). O selo identifica um pacote tanto em relação ao EAGLE quanto a outros ITGF; e como estes últimos, também contempla vários níveis (levels, stages) e cores.

    clipNote

    Dado que um dos principais requerimentos do EAGLE é a qualidade de seus processos e entregáveis (deliverables), ele já deve nascer [pelo menos parcialmente] em conformidade tanto com o Cobit–SOX Act 2002 como com o CMMI (Level 3, pelo menos).

    A documentação do EAGLE descreve e detalha (e comprova) tais conformidades, e mapeia os processos EAGLE com os seus correspondentes nos outros frameworks de governança de TI (ITGF). No futuro, outros ITGF (ITIL, TOGAF, PMI BoK, etc) serão igualmente contemplados.

    ↑ Topo ↑
 

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: