Glossário glossary

Este glossário lista (em ordem alfabética) detalhes de todos os documentos da Entrega da Lista de Verificação do Projeto.

Aceitação das partes interessadas acceptance-from-business-stakeholders

A aceitação das partes interessadas confirma que elas, como principais partes interessadas, estão alinhadas com a solução e deram sua aprovação quanto à forma como os requisitos comerciais atendem ao caso comercial.

Testes de aceitação acceptance-tests

O teste de aceitação é executado quando um aplicativo está pronto para produção. Os testes são executados por um grupo que representa os vários tipos de usuários finais, usando cenários da vida real.

Os testes de aceitação são usados para confirmar que:

Quanto mais cedo você planejar e projetar seus testes de aceitação, mais fácil será a implantação final. Eles devem ser definidos juntamente com o cliente e sua equipe de Controle de qualidade.

Embora talvez não seja possível definir todos os detalhes no início do projeto, as definições iniciais devem ser discutidas e acordadas. Os testes de aceitação provavelmente serão baseados nos requisitos fundamentais (funcional e de desempenho).

Acesso coordenado ao sistema de teste access-to-test-system-coordinated

Verifique se os níveis necessários de acesso ao sistema foram concedidos a todas as funções.

Lista de verificação de segurança do Adobe adobe-security-checklist

A Lista de Verificação de Segurança do Adobe é a lista de verificação oficial fornecida para garantir que o Adobe Experience Manager (AEM) seja seguro na instalação. Ele contém as medidas de segurança e as etapas de verificação que devem ser executadas para garantir a integridade da instância.

Configuração de projeto do portal de suporte do Adobe adobe-support-portal-project-set-up

O Portal de suporte do Adobe permite que os parceiros e clientes de implementação configurem a implementação do AEM como um projeto no Portal de suporte.

É possível registrar detalhes; por exemplo, sobre as tecnologias e versões implementadas. Elas proporcionam transparência entre o cliente e o Adobe.

Treinamento do administrador do AEM aem-administrator-training

Treinamento para a equipe administrativa da solução. Consulte os Serviços de treinamento do Adobe para obter mais informações.

Treinamento do autor do AEM aem-author-training

Treinamento para a equipe que produzirá (criará) conteúdo para a solução. Consulte os Serviços de treinamento do Adobe para obter mais informações.

Exame de certificação AEM aem-certification-exam

Verifique se as pessoas apropriadas estão registradas para fazer os exames de certificação relevantes.

Certificado por AEM aem-certified

Certifique-se de que o perfil apropriado tenha passado nos exames de certificação relevantes.

Treinamento técnico em AEM aem-technical-training

Fornecer treinamento técnico para a pessoa apropriada; por exemplo, desenvolvedores, arquitetos, engenheiros e profissionais de negócios.

Acordo sobre KPIs Definidos como Metas para o Projeto agreement-on-kpis-defined-as-goals-for-the-project

Os indicadores-chave de desempenho (KPIs) ajudam uma organização a definir e medir o progresso em direção às metas organizacionais. Depois que uma organização analisar sua missão e definir suas metas, ela deverá medir o progresso em direção a essas metas. Os KPIs fornecem um mecanismo de medição.

Alinhar KPIs de Negócios e Desempenho align-business-and-performance-kpis

O alinhamento dos KPIs (Key Performance Indicators, Indicadores-chave de desempenho) de negócios e desempenho ajuda a reunir todas as pessoas e processos envolvidos dentro da organização. Isso, por sua vez, ajuda a reduzir o tempo e o esforço necessários para atingir as metas de negócios e atingir o objetivo proposto.

Alinhamento da arquitetura de conteúdo com KPIs alignment-of-content-architecture-with-kpis

Garantir que a arquitetura de conteúdo proposta esteja alinhada com os indicadores-chave de desempenho (KPIs) relevantes.

Alinhamento do roteiro do cliente com o cronograma do projeto alignment-of-the-customer-roadmap-with-project-timeline

O roteiro do cliente é composto por marcos de alto nível e metas de negócios. A Linha do tempo do projeto deve seguir e se alinhar a essa estratégia, de modo que quaisquer riscos e/ou possíveis desvios devem ser destacados e rastreados.

Definição da arquitetura do aplicativo application-architecture-definition

A arquitetura do aplicativo deve definir claramente o comportamento dos aplicativos propostos.

Tem como foco:

Tarefas de manutenção específicas do aplicativo definidas application-specific-maintenance-tasks-defined

Além das tarefas de manutenção padrão do Adobe Experience Manager (AEM), é necessário definir outras tarefas operacionais que devem ser executadas para a manutenção contínua da solução.

Equipe devidamente treinada appropriately-trained-staff

Certifique-se de que sua equipe seja composta pela equipe com o treinamento adequado. Para equipes de projeto, a recomendação é ter todos os seguintes itens:

Diagrama da arquitetura architecture-diagram

O diagrama de arquitetura é uma representação gráfica da arquitetura. Inclui a representação de:

Rascunho da arquitetura architecture-draft

Isso fornece uma exibição de alto nível da arquitetura do sistema e da solução. Nesta fase, trata-se de um projeto que será revisto e aperfeiçoado em fases posteriores.

Aprovação do painel de revisão da arquitetura architecture-review-board-sign-off

O Painel de revisão da arquitetura é um órgão interorganizacional que:

O comitê de revisão deve ser representativo de todas as principais partes interessadas envolvidas na arquitetura. Normalmente, eles são compostos por um grupo de executivos responsáveis pela revisão e manutenção da arquitetura geral.

Conjunto de testes automatizado adaptado para conteúdo real e resultados em comparação aos KPIs automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

Scripts de automação e casos de uso automatizados básicos:

Estratégia de teste automatizado automated-testing-strategy

Essa estratégia define uma estrutura para scripts automatizados reutilizáveis, juntamente com a abordagem planejada pela equipe de Controle de qualidade (QA). Ele descreve o plano geral de teste de automação para ajudar a garantir:

Estratégia de teste automatizada validada em relação à carga realista e esperada automated-testing-strategy-validated-against-realistic-and-expected-load

A Estratégia de teste automatizado deve ser validada e ajustada de acordo com o conteúdo e a carga esperada que estarão na solução.

Estratégia de automação automation-strategy

A automação das implantações garante implantações mais rápidas e consistentes. A estratégia de automação descreve a configuração de tais mecanismos de automação, incluindo:

Consciente do plano de comunicação aware-of-communication-plan

Toda a equipe de projeto e todas as partes interessadas devem confirmar que estão cientes do seguinte:

Ciente das definições e dos critérios de sucesso aware-of-success-definitions-and-criteria

Toda a equipe de projeto e todas as partes interessadas devem confirmar que estão cientes do seguinte:

Conceito de backup e restauração backup-and-restore-concept

O conceito de backup e restauração descreve a funcionalidade técnica que será implementada na solução. Ela é exigida pela política de backup e restauração da empresa.

Backup e restauração testados backup-and-restore-tested

Um teste completo com base no conceito de backup e restauração.

Casos de negócios business-case-s

Um documento de business case apresenta os argumentos relacionados a executar a ação, executar a ação alternativa (se disponível) ou não executar nenhuma ação. Os argumentos devem ser ponderados, com base em fatos concretos (sempre que possível/relevante) e destacar tanto os benefícios como os riscos para todos os casos.

Um documento de business case deve ser uma definição clara de todas as opções, concluindo com um argumento convincente para a implementação da solução proposta.

Analista de negócios entende o escopo do projeto e as expectativas business-analyst-understands-scope-of-project-and-expectations

O analista de negócios deve confirmar que entende totalmente:

KPIs Comerciais business-kpis

As organizações usam Indicadores-chave de desempenho (KPIs) para avaliar seu sucesso em atingir metas.

Os KPIs de negócios definem valores mensuráveis que demonstram com que eficiência uma empresa está alcançando os principais objetivos de negócios. É importante escolher KPIs apropriados para seus negócios/cenários com definições claras do que são, como são medidos, como são usados e por quem.

Documentação de requisitos comerciais business-requirements-documentation

Um documento de requisitos comerciais (BRD) detalha a solução de negócios de um projeto, fornecendo uma especificação clara das necessidades e expectativas dos negócios do cliente. O BRD também distingue entre a solução empresarial e a solução técnica.

Ao examinar a solução empresarial, o BRD deve responder à pergunta:
"O que a empresa quer fazer?"

Aprovação dos negócios em quaisquer ajustes necessários para a solução ou arquitetura identificada e alinhada às expectativas de ROI e KPI business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

Os processos de avaliação de riscos e teste de penetração podem produzir problemas e resultados que devem ser abordados na arquitetura ou no desenvolvimento da solução.

Quaisquer ajustes resultantes desses processos devem ser revisados e aprovados pela empresa e avaliados em relação às metas gerais.

Estratégia de armazenamento em cache caching-strategy

A estratégia de armazenamento em cache descreve o que será armazenado em cache para o usuário final. Ele deve ser compatível com os KPIs de desempenho.

Por exemplo, elementos como imagens, JavaScript e outros arquivos de servidor podem ser armazenados em cache para melhorar o desempenho de uma solução.

Diretrizes de codificação coding-guidelines

As Diretrizes de codificação definem os princípios básicos que os desenvolvedores devem seguir ao desenvolver a solução. Estas podem incluir, entre outras:

Manual de operações do Communicate communicate-operations-manual

Assegure-se de que todas as personalidades/funções apropriadas tenham recebido o Manual de Operações.

Comunicar relatório de teste de desempenho communicate-performance-test-report

Verifique se todas as persona/funções apropriadas receberam o Relatório de teste de desempenho.

Comunicar notas de versão communicate-release-notes

Verifique se todas as persona/funções apropriadas receberam as Notas de versão.

Comunique o escopo e as expectativas à equipe communicate-scope-and-expectations-to-team

Garantir que a equipe do projeto esteja totalmente ciente e alinhada com o escopo do projeto e as expectativas de entrega.

Comunicar materiais de treinamento e guias do usuário communicate-training-materials-and-user-guides

Garantir que todos os perfis/funções apropriados recebam os materiais de treinamento e os guias do usuário.

Conformidade com os requisitos de segurança do cliente compliance-with-customer-security-requirements

Garantir que todos os requisitos de segurança do cliente estejam em vigor.

Conformidade com o conceito de segurança compliance-with-security-concept

Certifique-se de que o Conceito de segurança esteja em vigor.

Conceito de relacionamento de componentes e modelos components-and-templates-relationship-concept

A estrutura dos modelos e componentes usados no novo aplicativo. Inclui detalhes como regras de herança, permissões e relacionamentos, entre outros.

Especificação de relacionamento de componentes e modelos components-and-templates-relationship-specification

Detalhes do conceito de relacionamento de componentes e modelos.

Especificação de componentes components-specification

Detalhes de especificação de cada um dos componentes a serem implementados.

Conceito para modelos de interfaces externas concept-for-mock-ups-of-external-interfaces

O conceito de como desenvolver e testar qualquer interface externa que possa não estar aberta/disponível para os ambientes de desenvolvimento ou teste.

Planeje/implemente modelos dessas interfaces para garantir que o teste esteja o mais próximo possível do comportamento semelhante ao de produção.

Documento de arquitetura de conteúdo content-architecture-document

Documentação da arquitetura proposta do conteúdo. Os pormenores devem incluir, entre outros:

Conteúdo validado para migração content-validated-for-migration

O conteúdo do sistema herdado é revisado e o conteúdo selecionado é validado para migração para a nova solução.

Rascunho do Contrato contract-draft

Um rascunho inicial do contrato legal.

Estrutura e formato do conteúdo atual current-content-structure-and-format

Documentação da arquitetura e do formato do conteúdo atual. Isso é usado para gerar a arquitetura de conteúdo futura. Ele também será usado para o Conceito de migração.

Política de backup e restauração do cliente customer-backup-and-restore-policy

Políticas do cliente relacionadas a:

Diretrizes de codificação do cliente customer-coding-guidelines

Quaisquer diretrizes/requisitos do cliente sobre como o desenvolvimento deve ser feito.

Políticas de implantação/liberação do cliente customer-deployment-release-policies

Políticas do cliente que definem como e quando as implantações/versões podem ser feitas.

Geralmente, incluem requisitos de cronograma, programação e aprovação.

Políticas ou requisitos de monitoramento do cliente customer-monitoring-policies-or-requirements

Políticas e requisitos do cliente sobre o que deve ser monitorado. Além de quaisquer recomendações especificadas no Conceito de monitoramento.

Programação de Liberação de Produção do Cliente customer-production-release-schedule

O agendamento definido pelo cliente para lançamentos nos ambientes de produção.

Políticas e requisitos de relatórios do cliente customer-reporting-policies-and-requirements

Quaisquer políticas, ou requisitos, ou ambos, que o cliente tem em relação aos relatórios. Eles podem incluir:

Roteiro do cliente customer-roadmap

Formular um roteiro dos principais marcos a serem implementados, tanto tecnológicos quanto empresariais. Esse roteiro é, então, comunicado ao cliente.

Políticas de segurança do cliente customer-security-policies

O cliente (negócios e TI) terá políticas que definem os níveis de segurança necessários para a solução. Eles podem incluir:

Diretrizes de especificação do cliente customer-specification-guidelines

Quaisquer diretrizes que o cliente tenha relacionadas ao formato, entrega e aprovação das especificações.

Relatórios de teste do cliente customer-test-reports

Relatórios do cliente para o Líder de Qualidade durante o período do Teste de Aceitação do Usuário (UAT).

Personalizações e hotfixes que afetam atualizações documentadas customizations-and-hotfixes-that-affect-upgrades-documented

Quaisquer personalizações e/ou hotfixes aplicados devem ser documentados, pois podem afetar atualizações futuras:

Relatório de teste de aceitação diária do usuário daily-user-acceptance-test-report

Relatórios ou reuniões resultantes do Teste de aceitação do usuário (UAT). Eles devem detalhar:

Segurança Padrão Habilitada default-security-enabled

Verifique se as configurações de segurança padrão para AEM foram ativadas/implementadas.

Políticas e processos de implantação/liberação deployment-release-policies-and-processes

Políticas formalizadas que abrangem a implantação e as versões do seu projeto. Eles podem incluir:

Cadência de implantação estabelecida deployment-cadence-established

Defina a frequência necessária de implantações entre ambientes.

Metodologia de desenvolvimento development-methodology

Uma metodologia de desenvolvimento de software envolve dividir todo o processo de trabalho de desenvolvimento de software em fases distintas (ou estágios), cada uma com atividades distintas. O objetivo é melhorar o planeamento e a gestão.

Ao definir a metodologia, você deve predefinir deliverables e artefatos específicos que são criados e concluídos pela equipe do projeto para desenvolver ou manter seu aplicativo.

Definição da função de desenvolvimento development-role-definition

Definir qual desenvolvedor e/ou função está executando TI (desempenho ou outro) e/ou testes de unidade na solução.

Ambiente de desenvolvimento pronto development-environment-ready

Garantir que o ambiente de desenvolvimento esteja configurado com as ferramentas integradas necessárias para a automação das implantações.

A equipe de desenvolvimento entende o escopo do projeto e as expectativas development-team-understands-scope-of-project-and-expectations

A Equipe de desenvolvimento deve confirmar que entende perfeitamente:

Especificação de caixas de diálogo dialogs-specification

Detalhes sobre as caixas de diálogo necessárias para a solução.

Configuração do ambiente de desenvolvimento de documentos document-development-environment-setup

Documentação do ambiente de desenvolvimento.

Configuração do ambiente de produção de documentos document-production-environment-setup

Documentação do ambiente de produção.

Configuração do ambiente de teste de documento document-test-environment-setup

Documentação do ambiente de teste.

Teste de durabilidade durability-test

O teste de durabilidade mostra o desempenho da solução com uma carga específica. Os testes medem quanto tempo a solução sobrevive quando enviada à carga limite e em que níveis de desempenho.

Teste de durabilidade executado durability-test-executed

Execução dos ensaios de durabilidade.

Conceito de tratamento de erros error-handling-concept

O tratamento de erros refere-se à antecipação, detecção e resolução de erros de programação, aplicativo e comunicação.

Documentação de tratamento de erros error-handling-documentation

Documentação detalhada do tratamento de erros proposto, com base no Conceito de tratamento de erros.

Processos de escalonamento escalation-processes

Definição de todos os processos de escalação. Haverá processos separados para cada nível de projeto:

Estabelecer sessões regulares de análise de qualidade establish-regular-quality-review-sessions

Estabeleça reuniões regulares de análise da qualidade com os membros da equipe apropriados.

Estrutura de permissões existente existing-permissions-structure

Documentação do conjunto existente de permissões e grupos definidos para a solução herdada ou na organização.

Mapa de sistemas existentes existing-systems-map

Um diagrama (ou conjunto de diagramas) dos sistemas e dependências existentes.

Definições e critérios de sucesso esperados expected-success-definitions-and-criteria

O Patrocinador do Projeto coleta as expectativas de negócios relacionadas ao sucesso do projeto. É importante ter o conjunto completo de expectativas disponíveis no início de um projeto, uma vez que estas devem influenciar todas as decisões tomadas ao longo da execução.

As expectativas podem incluir:

Requisitos de designs de experiência experience-designs-requirements

Requisitos para toda a experiência da solução. Isso abrange fatores como personalização, persistência entre dispositivos e experiência do usuário, entre outros.

Especificações da experiência experience-specifications

Detalhes dos requisitos de design de experiência.

Dependências do Sistema Externo e do Usuário/Contexto do Sistema external-system-and-user-dependencies-system-context

Um diagrama (ou conjunto de diagramas) que descreve o ecossistema completo da solução. Isso deve incluir elementos como integrações externas, interfaces, dependências e redes.

Sistema e procedimento de fallback fallback-system-and-procedure

A definição do sistema de fallback:

Sistema de fallback e procedimento testado fallback-system-and-procedure-tested

Teste completo do sistema de fallback.

Aprovação do sistema de fallback das partes interessadas da empresa fallback-system-sign-off-from-business-stakeholders

Aprovação, junto às partes interessadas, de que o sistema de fallback e os procedimentos relacionados garantem as funcionalidades críticas dos negócios.

Confirmação de viabilidade em KPIs feasibility-confirmation-on-kpis

Resultados de um estudo de viabilidade para o AEM e o projeto de solução de alto nível. Eles devem ser medidos em relação aos KPIs para garantir que possam ser atendidos.

Contrato finalizado finalized-contract

É necessário um contrato finalizado e assinado antes de prosseguir com o projeto. Isto é baseado no Rascunho do Contrato.

Funcionalidade da solução aceita pelas partes interessadas functionality-of-the-solution-accepted-by-stakeholders

Confirmação de que as partes interessadas aceitam plenamente o seguinte:

Programação de ativação go-live-schedule

Cronograma e programação das atividades necessárias para:

Caminhos felizes definidos happy-paths-defined

Um caminho feliz é um cenário padrão que não apresenta condições excepcionais ou de erro. Ele é composto pela sequência de atividades executadas quando tudo acontece conforme esperado.

Estimativas de hardware hardware-estimates

Estimativas iniciais de:

O hardware estará disponível para atender aos requisitos hardware-will-be-available-to-fulfill-requirements

Confirmação de que todos os ambientes terão o hardware mínimo necessário em vigor.

Requisitos de alto nível high-level-requirements

A definição dos requisitos de alto nível fornece uma discriminação generalizada dos requisitos do sistema, abrangendo aspectos como:

Os detalhes básicos sobre essas funções são normalmente conhecidos, portanto, este documento não deve ser uma estimativa.

Design de solução de alto nível high-level-solution-design

O design da solução de alto nível explica a arquitetura usada para desenvolver a solução. O diagrama da arquitetura fornece uma visão geral de todo o sistema, identificando os principais componentes desenvolvidos para o produto e suas interfaces.

Mapa de sistema de alto nível high-level-system-map

Este mapa de sistema deve fornecer um diagrama de alto nível do sistema. Ele difere do Contexto da solução na medida em que é um mapa generalizado de todos os sistemas envolvidos; não há interfaces neste diagrama.

Estrutura de conteúdo histórico historical-content-structure

Definição da estrutura de conteúdo do sistema herdado. Isso é usado para referência e também ao preparar a estratégia de migração.

KPIs de Desempenho Histórico e Desempenho Histórico historical-performance-and-historical-performance-kpis

Colete e documente estatísticas de desempenho e KPIs de desempenho do sistema herdado. Eles são usados como ponto de referência e para fazer um benchmark da nova solução.

Identificar as principais soluções/funcionalidades identify-critical-key-solutions-functionalities

Uma lista das funcionalidades críticas para os negócios.

Implementação - alterações com base nos resultados do teste de penetração implementation-changes-based-on-penetration-test-results

Implementação de todas as alterações necessárias (que foram aprovadas) na solução com base nos resultados dos testes de penetração.

Implementação - estratégia de teste automatizado implementation-automated-testing-strategy

Configuração das ferramentas e dos processos necessários para suportar testes automatizados.

Implementação - estratégia de automação implementation-automation-strategy

Configuração do conjunto de ferramentas e dos processos necessários para dar suporte à automação.

Implementação - arquitetura de conteúdo implementation-content-architecture

Implementação da arquitetura de conteúdo, conceitos de marcação e reutilização de conteúdo.

Implementação - design da experiência implementation-experience-design

Implementação dos requisitos para oferecer suporte ao Design de experiência.

Implementação - sistema e procedimentos de fallback implementation-fallback-system-and-procedures

Implementação do sistema de fallback e procedimentos relacionados.

Implementação - Integração implementation-integration

Implementação de integrações com todos os sistemas externos necessários.

Implementação - Estratégia de migração implementation-migration-strategy

Migração juntamente com a validação de conteúdo e outros artefatos para a nova solução.

Implementação - Funções e direitos implementation-roles-and-rights

Implementação de funções e direitos, usuários e grupos.

Implementação - Conceito de segurança implementation-security-concept

Implementação de todas as medidas de segurança, incluindo padrões AEM.

Implementação - Software de segurança implementation-security-software

Implementação da segurança de aplicativos de software.

Implementação - Conceito de segurança da arquitetura do sistema implementation-system-architecture-security-concept

Implementação da segurança do sistema.

Implementação - manuseio de URL implementation-url-handling

Implementação do conceito de manipulação de URL.

Implementação - Fluxos de trabalho implementation-workflows

Implementação dos workflows projetados.

Conceito de implementação implementation-concept

O conceito de implementação fornece os princípios orientadores para toda a implementação. Deve considerar:

Esse conceito também descreve as estruturas, bibliotecas e outros artefatos usados na solução.

Informe o suporte do Adobe sobre o cronograma de ativação inform-adobe-support-about-the-go-live-schedule

Entre em contato com o Suporte Adobe para garantir que qualquer suporte necessário possa ser ativado durante a ativação.

Designs iniciais de experiência initial-experience-designs

Conceitos preliminares para os designs das experiências.

Teste de integração integration-testing

Testes e a confirmação resultante de todas as integrações, internas e externas.

Isso deve ser automatizado e executado com frequência para garantir a estabilidade do sistema.

Processo de rastreamento de problemas issue-tracking-process

Processos claros registram todos os problemas encontrados e rastreiam as atividades em andamento com o objetivo de garantir que todos os problemas sejam resolvidos.

Sistema e processos de controle de problemas issue-tracking-system-and-processes

Um sistema de rastreamento, juntamente com os processos necessários, para registrar todos os problemas encontrados e rastrear as atividades em andamento com o objetivo de garantir que todos os problemas sejam resolvidos.

Todas as partes interessadas do projeto devem ter acesso para facilitar a transparência do estatuto do projeto.

Exemplos incluem Atlassian JIRA e HP Quality Center.

O processo do sistema de controle de problemas está configurado e integrado issue-tracking-system-process-is-set-up-and-integrated

A ferramenta selecionada é totalmente integrada e o acesso é concedido a todas as funções necessárias.

Sistema antigo legacy-system

Para o seu projeto, o sistema herdado é a tecnologia existente, o sistema de computador ou o programa aplicativo que será substituído pela nova solução.

Os detalhes do sistema herdado devem ser coletados para que você saiba o que pode ser removido, quando e o impacto em outros sistemas.

Lista de ferramentas de desenvolvimento a serem usadas list-of-development-tools-to-be-used

Uma descrição das ferramentas usadas na implementação; as ferramentas devem incluir:

Lista de usuários que precisam de acesso ao portal de suporte do Adobe list-of-users-that-require-access-to-adobe-support-portal

Uma lista de todos os usuários e funções que precisam de acesso ao Portal de suporte do Adobe.

Normalmente, a lista é composta pelo Arquiteto de soluções e/ou pela equipe de TI do cliente.

Análise do arquivo de log log-file-analysis

Uma análise, juntamente com as recomendações resultantes, definindo o que deve ser registrado para monitorar a solução:

Tarefas de manutenção (específicas ao AEM) testadas e ativadas maintenance-tasks-aem-specific-tested-and-enabled

Testar e habilitar tarefas de manutenção do AEM, como:

Plano de migração migration-plan

Documentar a migração; incluindo

Estratégia de migração migration-strategy

Uma descrição completa do conteúdo existente, arquitetura de conteúdo e formatos mapeados para a nova solução. Deve abranger:

Ele também deve recomendar como manter o conteúdo atualizado (ou o mais atualizado possível) durante o período entre a migração e a ativação real do novo sistema. Isso pode significar um congelamento de conteúdo, a publicação dupla ou a manutenção de um sistema alfa.

Monitoramento - CPU monitoring-cpu

Monitorar o uso da CPU do sistema pela solução:

Monitoramento - E/S de disco monitoring-disk-i-o

Monitoramento das taxas de entrada e saída de disco da solução:

Monitoramento - Espaço em disco monitoring-disk-space

Monitoramento do uso de espaço em disco da solução:

Você deve monitorar o uso por:

Monitoramento - Sistemas Externos monitoring-external-system-s

Monitorar todas as conexões entre a solução e sistemas externos:

Monitoramento - Largura de banda da rede monitoring-network-bandwidth

Monitorar o uso da largura de banda da rede pela solução:

Monitoramento - Solicitações monitoring-requests

Monitore as solicitações feitas na solução.

Monitoramento - Pontos de Segurança monitoring-security-points

Monitorar nos pontos de segurança definidos.

Monitoramento - Sistema monitoring-system

Monitorar o sistema como um todo; por exemplo:

Monitoramento - Limite e intervenção monitoring-threshold-and-intervention

Monitoramento do limite definido da solução juntamente com a implementação de etapas de intervenção para reduzir a carga.

Conceito de monitoramento monitoring-concept

Os conceitos de monitoramento a serem aplicados à sua solução; incorporando:

Monitorando Pontos Fracos Potenciais monitoring-potential-weak-points

Devem ser identificados e definidos pontos específicos susceptíveis de falha. Quaisquer tarefas de monitorização relacionadas com estas devem também ser definidas.

Os exemplos incluem (entre outros):

Política de monitoramento comunicada ao engenheiro de sistema monitoring-policy-communicated-to-system-engineer

Garantir que os engenheiros de sistema e a equipe de operações conheçam e compreendam quaisquer políticas de monitoramento.

Relatórios de monitoramento - Estrutura em vigor monitoring-reports-structure-in-place

Defina:

Documentação de tarefas operacionais operational-tasks-documentation

Todas as tarefas operacionais documentadas, com sua frequência definida.

Manual de operações operations-manual

Manual, fornecendo todas as informações necessárias para as operações bem-sucedidas e a manutenção da solução:

Também deve detalhar os conceitos de implementação para:

Pacote preparado package-prepared

Pacote de software criado e entregue pronto para implantação.

Testes de penetração penetration-tests

Um teste de penetração (informalmente conhecido como teste de caneta) é um ataque a um sistema de computador que procura por falhas de segurança, potencialmente obtendo acesso aos recursos e dados do computador.

Testes de penetração - Aprovados penetration-tests-passed

Todos os critérios obrigatórios foram aprovados.

Testes de penetração - Resultados penetration-tests-results

Relatórios criados para a empresa explicando os resultados do teste de penetração.

Conceito de desempenho e escalabilidade performance-and-scalability-concept

Documento conceitual sobre como garantir que sua implementação atenda aos KPIs de desempenho e como dimensionar a solução para que ela continue a atender a esses KPIs.

Benchmark de desempenho performance-benchmark

O benchmark de desempenho é usado para definir testes de desempenho, testes de durabilidade e monitoramento. Ele faz isso avaliando as características de desempenho da solução e do hardware do sistema.

KPIs de desempenho performance-kpis

Eles definem os KPIs (Key Performance Indicators, Indicadores-chave de desempenho) necessários para medir o desempenho do sistema. Alguns exemplos incluem tempo de carregamento de página, tempo de resposta do servidor e desempenho de consulta do banco de dados.

Testes de desempenho - Relatório performance-tests-report

Relatórios criados para a empresa, detalhando os resultados dos testes de desempenho.

Testes de Desempenho - Os Resultados Correspondem aos KPIs de Desempenho performance-tests-results-match-performance-kpis

Os resultados devem corresponder aos KPIs definidos e às expectativas de desempenho.

Conceito de teste baseado em persona persona-based-testing-concept

O teste baseado em persona é um método baseado nas diferentes personalidades descritas em Designs de experiência. Ele também testa as contas e os níveis de permissão relacionados.

Geralmente, isso é usado em UAT (User Acceptance Testing, teste de aceitação do usuário).

POC testada e verificada em relação à documentação de requisitos poc-tested-and-verified-against-requirement-documentation

A Prova de conceito (POC) é avaliada em relação aos requisitos para garantir que ambos estejam alinhados.

Post - Lista de verificação de implantação post-deployment-checklist

Uma lista de verificação para definir a série de verificações e tarefas a serem executadas após cada implantação.

Lista de verificação pré-implantação pre-deployment-checklist

Uma lista de verificação para definir a série de verificações e tarefas a serem executadas antes de cada implantação.

Testes de desempenho da linha de base do ambiente de produção production-environment-baseline-performance-tests

É comum executar um teste de linha de base em uma instalação padrão do AEM. Ele é usado como um benchmark para testar a implementação e o hardware em relação ao.

Ambiente de produção pronto production-environment-ready

Confirme se o ambiente de produção está pronto, com implantações automatizadas em vigor.

Aprovação da produção das partes interessadas da empresa production-sign-off-from-business-stakeholders

Antes de entrar no ambiente de produção, o Logon de produção (PSO) deve ser concedido. Esse é o resultado de uma revisão da versão que entrará em produção, juntamente com quaisquer problemas conhecidos. A aprovação é fornecida como parte da programação da ativação.

Processo e política de aprovação da produção production-sign-off-process-and-policy

A política e o processo necessários para obter a aprovação de produção antes de mover o pacote para o ambiente de produção.

Plano de comunicação do projeto project-communication-plan

Definir o plano de comunicação para as partes interessadas da empresa e a equipe do projeto.

Esforços do projeto - Estimativas finais project-efforts-final-estimates

As estimativas iniciais foram de alto nível e foram feitas de acordo com os requisitos de alto nível para a implementação.

Elas agora são revisadas, refinadas e expandidas para fornecer as estimativas finais. As estimativas devem ser fornecidas por cada líder de projeto apropriado, incluindo gerenciamento de projeto, consultoria, arquitetura, teste e desenvolvimento.

Essas estimativas são usadas para recursos e orçamento.

Esforços do Projeto - Estimativas Iniciais project-efforts-initial-estimates

As estimativas iniciais são de alto nível e feitas de acordo com os requisitos de alto nível para a implementação. Esse processo será revisto e aperfeiçoado em fases posteriores.

Organização do Projeto project-organization

A documentação necessária para descrever a organização e a estrutura de relatórios do projeto e da equipe.

Geralmente assume a forma, ou inclui, um gráfico para apresentar uma visão geral visual de linhas do tempo e responsabilidades. Há muitas ferramentas disponíveis para ajudar nisso.

Documento do escopo do projeto project-scope-document

O documento de escopo do projeto requer que você identifique e documente uma lista de:

Abrange o que deve ser alcançado, juntamente com o trabalho que deve ser feito, para realizar o projeto

Relatórios de status de projeto em uma cadência definida project-status-reports-within-a-defined-cadence

Relatórios de status de projeto entregues de acordo com o agendamento acordado e com o formato necessário.

Prova de conceito (POC) proof-of-concept-poc

A Prova de conceito (POC) implementa uma variedade limitada de funções para a solução.

Deve ter por objetivo demonstrar a viabilidade da solução, verificar se pode cumprir o objetivo pretendido e provar que existe o potencial da sua utilização.

Regras de Expurgação purge-rules

O AEM mantém várias versões de ativos e conteúdo. As regras de limpeza são projetadas e configuradas para remover periodicamente as versões mais antigas para manter a integridade e o tamanho do repositório.

Formato e cadência do relatório de qualidade quality-report-format-and-cadence

Defina o conteúdo e o formato necessários do relatório de qualidade, juntamente com a frequência com que ele deve ser entregue.

Versão coordenada release-coordinated

O gerente de projeto coordena todas as funções necessárias para a liberação para produção.

Notas de versão release-notes

As notas de versão fazem parte da documentação da versão. As notas de versão devem abranger:

Ele é usado com o Runbook para executar etapas e verificações pré e pós-instalação.

Versão em execução no ambiente de produção release-running-on-production-environment

Versão final em execução e ativa na produção.

Condições Relevantes do Contrato relevant-contract-terms

Destacar termos contratuais específicos relevantes para a implementação do projeto, como marcos contratuais, períodos de fatura ou requisitos de pessoal.

Cadência de relatórios reporting-cadence

Juntamente com o cliente, defina a frequência dos relatórios entregues a ele.

Otimização do repositório repository-optimization

Os dados nunca são sobregravados em um arquivo tar, o uso do disco aumenta mesmo quando atualiza apenas os dados existentes.

Para neutralizar o tamanho cada vez maior do repositório, uma estratégia de otimização é implementada para remover dados obsoletos.

Seção Solicitação de configuração de projeto no portal de suporte do Adobe request-for-setting-up-project-section-in-adobe-support-portal

A solicitação oficial para configurar seu projeto no Portal de suporte do Adobe.

Documentação dos requisitos requirements-documentation

Este conjunto de documentação abrange os requisitos funcionais e não funcionais, juntamente com os esforços estimados.

Recursos disponíveis para dar suporte à ativação resources-available-to-support-go-live

Certifique-se de que todas as funções necessárias para entrar em funcionamento tenham uma equipe e estejam disponíveis.

Avaliação de riscos risk-assessment

A avaliação de riscos é executada pelo departamento de TI, pelo departamento de segurança do cliente ou por ambos.

Ele avalia os riscos técnicos e comerciais do projeto. A avaliação é necessária para que a solução garanta a conformidade com as políticas de segurança.

Plano de Mitigação de Riscos risk-mitigation-plan

O Plano de Mitigação de Riscos inclui a Avaliação de Riscos. Juntos, abrangem:

Expectativas de ROI roi-expectations

Definir as expectativas de retorno do investimento (ROI) que estão associadas à solução.

Têm por objetivo indicar a eficiência da solução em termos econômicos, definindo os benefícios/lucros esperados em relação ao investimento estimado.

Conceito de funções e direitos roles-and-rights-concept

Especificação detalhada dos conceitos relacionados às funções e direitos de acesso necessários para o novo aplicativo, incluindo uma descrição de alto nível de:

O conceito de funções e direitos atende às diretrizes de segurança roles-and-rights-concept-meets-security-guidelines

Revisão do conceito de Funções e Direitos para garantir que ele atenda às políticas de segurança.

Especificação de funções e direitos roles-and-rights-specification

Uma especificação detalhada com base nas Funções e no Conceito de direitos.

Arquitetura de segurança Recommendations security-architecture-recommendations

Recommendations relacionado à segurança da arquitetura de software e hardware.

Diretrizes de codificação com base em segurança security-based-coding-guidelines

Essas diretrizes definem como a codificação de desenvolvimento deve ser feita, com base em requisitos de segurança como:

Lista de verificação de segurança security-checklist

Lista de verificação de itens específica do projeto, com base no Conceito de segurança, juntamente com quaisquer políticas adicionais necessárias para garantir a conformidade da solução.

Geralmente, isso também é incluído como parte das etapas pós-implantação no runbook.

Conceito de segurança security-concept

Definir e documentar detalhes da configuração de segurança necessária para o aplicativo, a arquitetura e a infraestrutura.

Rascunho do conceito de segurança security-concept-draft

Uma descrição de alto nível que aborda a configuração de segurança do:

Problemas de segurança listados e avaliados security-issues-listed-and-assessed

Todas as questões de segurança da solução listadas e avaliadas, incluindo estimativas de esforço.

Aprovação de segurança das partes interessadas da empresa security-sign-off-from-business-stakeholders

Faça logoff das partes interessadas para garantir que a implementação de segurança esteja em conformidade com as políticas e expectativas.

Configurar processos de suporte set-up-support-processes

Estabeleça os processos de suporte necessários.

SLAs para sistemas de terceiros slas-for-third-party-systems

Garantir que os Contratos de nível de serviço (SLAs) estejam disponíveis e sejam comunicados às equipes de desenvolvimento e operações para uso durante a implementação e o suporte.

Conceito de teste de fumaça smoke-test-concept

Os testes de fumaça consistem em um conjunto de etapas definidas que testam as principais funcionalidades da solução para garantir operações básicas e a funcionalidade da solução.

Elas são executadas, em qualquer ambiente, após a instalação ou implantação.

Testes de fumaça executados para validação do sistema smoke-tests-executed-for-system-validation

Os Testes de fumaça devem ser executados em todos os sistemas para garantir o funcionamento correto da funcionalidade básica da solução na instalação ou implantação em qualquer ambiente.

Estratégia de arquitetura de software software-architecture-strategy

A estratégia de alto nível para a arquitetura de software; incluindo serviços, servlets, estruturas e outras decisões de implementação.

Painel de análise da solução estabelecido e conjunto de cadência da reunião solution-review-board-established-and-meeting-cadence-set

O Solution Review Board é composto pelas partes interessadas do cliente.

O conselho realiza reuniões regulares para analisar os requisitos atualmente previstos e as especificações relevantes de forma contínua. O objetivo é garantir o alinhamento com a definição de sucesso e os critérios, bem como contribuir para o desenvolvimento dos requisitos.

Runbook de soluções solution-runbook

Instruções de instalação da solução, juntamente com as tarefas operacionais básicas a serem executadas na instalação.

Processo de aprovação e aceitação da solução solution-sign-off-and-acceptance-process

O processo de aprovação e aceitação descreve os critérios que devem ser cumpridos antes que a solução possa ser liberada em um ambiente produtivo.

Também pode servir como um marco contratual.

Conceito especial de funcionalidade special-functionality-concept

O conceito inicial para qualquer funcionalidade especial que seja considerada fora do escopo normal de desenvolvimento na plataforma AEM.

Especificação de funcionalidade especial special-functionality-specification

Detalhes de qualquer funcionalidade especial considerada fora do escopo normal de desenvolvimento na plataforma AEM.

Diretrizes de especificação specification-guidelines

Quaisquer diretrizes do cliente sobre como a especificação deve ser feita.

Processo de Revisão e Aprovação da Especificação Definido e Comunicado specification-review-and-approval-process-defined-and-communicated

Deve ser posto em prática um processo claro para a aprovação das especificações pelo cliente. Esse processo garante clareza e firmeza no escopo dos requisitos.

Equipe selecionada para treinamento de administrador do AEM staff-selected-for-aem-administrator-training

Equipe interna que precisa de treinamento para administrar a solução.

Equipe selecionada para treinamento de autor e usuário final staff-selected-for-author-and-end-user-training

Equipe interna que precisa de treinamento para ser autora da solução.

Partes interessadas stakeholders

As partes interessadas são as principais pessoas e/ou funções com um interesse significativo no projeto. Alguns contribuirão para o orçamento do projeto.

As partes interessadas podem ser internas e/ou externas.

As partes interessadas estão cientes das definições e dos critérios de sucesso stakeholders-are-aware-of-success-definitions-and-criteria

Confirmação de que todas as partes interessadas fora da equipe de implementação real estão cientes do:

Partes interessadas entendem o projeto e as expectativas stakeholders-understand-project-and-expectations

Confirmação de que todas as partes interessadas fora da equipe de implementação real estão alinhadas com o projeto geral e as expectativas, tanto internas da equipe do projeto quanto do cliente.

Definição do Formato de Relatório de Status status-report-format-definition

Os relatórios de status são uma ferramenta essencial de comunicação. O formato deve estar alinhado a quaisquer requisitos de relatório do cliente.

Critérios de sucesso e definição success-criteria-and-definition

O cliente, o patrocinador do projeto e o gerente ou consultor do projeto devem especificar:

Eles são usados para garantir que os critérios para o sucesso sejam atendidos:

Suporte na validação de problemas relatados support-in-validation-of-reported-issues

Parte das responsabilidades do Líder de qualidade é garantir que haja recursos disponíveis para suportar qualquer usuário durante os testes. Por exemplo, para ajudar o usuário a testar o, ao relatar problemas e para ajudar a validar os problemas em relação ao ambiente de teste.

Processos de suporte e acesso ao portal de suporte do Adobe support-processes-and-access-to-adobe-support-portal

O acesso ao Portal de suporte do Adobe é fundamental para enviar tíquetes sobre qualquer problema baseado em produtos que possa surgir durante a implementação.

O acesso deve ser concedido aos principais membros da equipe.

Definição da arquitetura do sistema system-architecture-definition

Uma proposta inicial e a definição da arquitetura para todos os ambientes da solução.

Documentação da arquitetura do sistema system-architecture-documentation

Um documento detalhando a arquitetura do sistema; incluindo interfaces, local de rede e integrações para todos os ambientes, entre outras informações.

Conceito de segurança da arquitetura do sistema system-architecture-security-concept

Uma descrição de alto nível de como tornar a arquitetura do sistema compatível com quaisquer políticas de segurança. Isso pode abranger:

Fatores de risco do sistema identificados e verificados system-risk-factors-identified-and-verified

Quaisquer fatores de risco encontrados na avaliação de riscos (ou em outras revisões) são identificados e avaliados:

A equipe está ciente das definições e dos critérios de sucesso team-is-aware-of-success-definitions-and-criteria

Confirmação de que toda a equipe do está ciente das definições e dos critérios de sucesso.

A equipe está ciente do plano de comunicação team-is-aware-of-the-communication-plan

Confirmação de que todos os membros da equipe estão cientes de quem deve se comunicar com o cliente, juntamente com detalhes de como e quando.

Equipe entende o projeto e as expectativas team-understands-project-and-expectations

Alinhamento com o projeto geral e as expectativas, tanto internas à equipe do projeto quanto ao cliente.

Requisitos técnicos technical-requirements

Esses requisitos são específicos para a implementação técnica dos serviços que oferecem suporte à solução.

Fatores de risco técnico verificados technical-risk-factors-verified

Identificar e verificar possíveis riscos técnicos. Os riscos técnicos podem incluir:

Especificação técnica technical-specification

As especificações técnicas abrangem (entre outras informações):

Especificação do modelo template-specification

As especificações dos modelos necessários. Esses devem abranger detalhes, incluindo parsys, blueprint e mapeamento de herança, entre outros.

As especificações se baseiam nos Requisitos comerciais e nos Requisitos de experiência.

Casos de teste test-cases

Casos de teste específicos as etapas detalhadas necessárias para executar o teste funcional da solução.

Testar conteúdo test-content

O conteúdo do teste deve estar o mais próximo possível do conteúdo de produção. Deve ser de uma seleção ampla o suficiente para permitir o teste de todos os cenários.

Ambiente de teste pronto test-environment-ready

Garantir que o ambiente de teste esteja pronto, com implantações automatizadas em vigor para garantir que todo o código candidato à versão esteja atualizado para teste.

Relatórios de teste test-reports

Relatórios detalhando os resultados dos testes, incluindo:

É de notar que:

Conjunto de teste test-suite

Seleção do conjunto de automação e das ferramentas. Eles são usados para automatizar testes, incluindo aqueles para casos de uso.

Testar conjunto de ferramentas selecionado test-tooling-suite-selected

Conjunto de automação e ferramentas selecionados para automação de casos de uso e outras tarefas de execução de teste.

Conceito de teste testing-concept

O Conceito de teste é o esboço de alto nível de teste para o projeto; incluindo testes de QA, UAT, desempenho, segurança e integração.

Planos de teste testing-plans

Esses planos descrevem com mais detalhes a execução de testes para cada fase de desenvolvimento e se baseiam na Estratégia de testes.

Escopo do teste testing-scope

Esses requisitos são específicos para a implementação técnica dos serviços que oferecem suporte à solução.

Estratégia de testes testing-strategy

A estratégia de testes descreve a estratégia de alto nível para garantia da qualidade e testes de aceitação do usuário. Isso inclui linhas do tempo, cadência de relatórios e execução.

Conceito de integração de terceiros third-party-integration-concept

Conceito de arquitetura e nível de sistema para a integração com sistemas de terceiros.

Especificação de integração de terceiros third-party-integration-specification

Detalhes dos requisitos (funcionais e não funcionais) para a funcionalidade compatível e a integração de sistemas de terceiros.

Conceito de segurança de terceiros third-party-security-concept

Conceito para garantir a segurança de quaisquer integrações de terceiros. Deve estar em conformidade com as políticas de segurança apropriadas.

Sistema de terceiros para integração third-party-system-for-integration

Garantir que todos os sistemas de terceiros estejam disponíveis, com a documentação apropriada, para implementação da integração.

Acesso a sistemas de terceiros ativado third-party-systems-access-enabled

Direitos de acesso necessários concedidos às respectivas funções usadas com sistemas de terceiros.

Conceito de teste de terceiros third-party-testing-concept

Define:

Definição de limite threshold-definition

Define os valores principais para pontos de monitoramento no sistema.

Por exemplo:

Linha do tempo e etapas timeline-and-milestones

Deve definir os prazos do projeto e as etapas contratuais a utilizar para:

Esforços Totais do Projeto total-project-efforts

Todas as estimativas de esforço, de cada um dos clientes potenciais do projeto, devem ser consolidadas; incluindo as despesas gerais, desenvolvimento, engenharia de sistema, arquitetura e esforços de teste.

Se houver um nível de suporte incluído no contrato, os esforços de suporte e operações também devem ser incluídos.

Materiais de treinamento training-materials

Materiais a serem usados em sessões de treinamento. O material deve ser criado especificamente para a solução e projetado para ser usado com os Guias do Usuário.

Compreende o escopo do projeto e as expectativas understands-scope-of-project-and-expectations

A pessoa apropriada deve confirmar que entende totalmente:

Conceito de manuseio de URL url-handling-concept

Seu conceito de manipulação de URL deve abranger funcionalidades de URL específicas do AEM, incluindo:

O conceito deve abranger igualmente:

Casos de uso use-cases

Um caso de uso é a lista de ações ou etapas de evento necessárias para atingir uma meta. Normalmente, eles definem as interações entre uma função e a solução. A função pode ser um usuário ou um sistema externo.

Casos de uso convertidos em cenários de teste use-cases-converted-into-test-scenarios

Os cenários de teste são baseados nos casos de uso técnico e comercial. Eles são usados para testar se o comportamento da solução é o esperado.

Guias do usuário user-guides

Os Guias do usuário fornecem informações e assistência aos usuários da solução:

Plano de Orçamento Validado validated-budget-plan

O plano de orçamento deve ser revisado e validado por todas as partes interessadas. Eles devem verificar detalhes como faturamento, quantias e métodos/tempo de emissão de relatórios de orçamento.

Resultados do teste de caixa branca white-box-test-results

O teste de caixa branca é um método que testa as estruturas internas ou o funcionamento de um aplicativo, em oposição à sua funcionalidade. O teste de caixa branca pode ser aplicado nos níveis de unidade, integração e sistema do processo de teste de software.

Especificações do fluxo de trabalho workflow-specifications

Com base no Conceito de workflows, essas especificações devem definir, em detalhes, as etapas que criam o workflow completo.

A especificação de cada workflow deve incluir (no mínimo):

Conceito de fluxos de trabalho workflows-concept

Os workflows permitem automatizar atividades do AEM. O Conceito de fluxos de trabalho descreve: