Show Menu
TÓPICOS×

Glossário

Este glossário lista (alfabeticamente) os detalhes de todos os documentos que podem ser entregues na Lista de verificação do projeto .

Aceitação por parte das partes interessadas

A aceitação por parte das partes interessadas empresariais confirma que elas, como partes interessadas-chave, estão alinhadas com a solução e deram a sua aprovação sobre como os requisitos de negócios atendem aos negócios.

Testes de aceitação

O teste de aceitação é realizado 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 reais.
Os testes de aceitação são utilizados para confirmar que:
  • O projeto atende aos requisitos do cliente.
  • A solução é adequada ao propósito.
  • Os usuários aceitam a solução e podem imaginar trabalhar com ela.
  • O cliente aceita o projeto.
Quanto mais cedo você planeja e projeta 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 se basearão em requisitos fundamentais (funcionais e de desempenho).

Acesso ao sistema de teste coordenado

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 da Adobe

A Adobe Security Checklist é a lista de verificação oficial fornecida para garantir que o AEM esteja protegido na instalação. Ele contém as medidas de segurança e as etapas de verificação necessárias para garantir a integridade da sua instância.

Configuração de projeto do portal de suporte da Adobe

O Portal de suporte da Adobe permite que os parceiros de implementação e os clientes configurem a implementação do AEM como um projeto no Portal de suporte.
Podem ser registradas informações pormenorizadas; por exemplo, sobre as tecnologias e versões implementadas. Elas proporcionam transparência entre o cliente e a Adobe.

Treinamento do administrador do AEM

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

Treinamento de autor do AEM

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

Exame de certificação AEM

Certifique-se de que a pessoa adequada esteja registrada para fazer os exames de certificação relevantes.

Certificado para AEM

Certifique-se de que a pessoa adequada passou nos exames de certificação relevantes.

Treinamento técnico do AEM

Fornecer formação técnica para a pessoa adequada; por exemplo, desenvolvedores, arquitetos, engenheiros e empresários.

Acordo sobre KPIs Definidos como Objetivos para o Projeto

Os Indicadores-chave de desempenho (KPIs) ajudam uma organização a definir e medir o progresso em direção às metas e objetivos organizacionais. Uma vez que uma organização tenha analisado a sua missão e definido os seus objetivos, tem de medir o progresso no sentido desses objetivos. Os KPIs fornecem um mecanismo de medição.

Alinhar KPIs de Negócios e Desempenho

O alinhamento da sua empresa e do desempenho Indicadores-chave de desempenho (KPIs) 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 cumprir a finalidade proposta.

Alinhamento da arquitetura de conteúdo com KPIs

Certifique-se de que a arquitetura de conteúdo proposta esteja alinhada aos KPIs (Indicadores-chave de desempenho) relevantes.

Alinhamento do roteiro do cliente com a linha do tempo do projeto

O Roteiro do cliente é composto de marcos de alto nível e objetivos comerciais. A Linha do tempo do projeto deve aderir e alinhar-se com essa estratégia, de modo que quaisquer riscos potenciais e/ou possíveis desvios devem ser destacados e rastreados.

Definição da arquitetura do aplicativo

A arquitetura das aplicações deve definir claramente o comportamento das aplicações propostas.
O foco é:
  • Como eles interagirão entre si e com os usuários.
  • Os dados a serem consumidos e produzidos pelas aplicações, e não pela sua estrutura interna.

Tarefas de Manutenção Específicas do Aplicativo Definidas

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

Pessoal adequadamente treinado

Certifique-se de que sua equipe seja composta por funcionários com o treinamento apropriado. Para equipes de projetos, a recomendação é ter todas as seguintes opções:
  • pelo menos um líder de desenvolvedor certificado pelo AEM
  • pelo menos um arquiteto certificado pelo AEM
  • pelo menos 75% dos desenvolvedores certificados pelo AEM;
    isso permite que os desenvolvedores certificados orientem os desenvolvedores secundários e garante o compartilhamento e a transparência do conhecimento

Diagrama de arquitetura

O diagrama da arquitetura é uma representação gráfica da arquitetura. Inclui representação de:
  • os conceitos
  • princípios
  • elementos e componentes que fazem parte da arquitetura

Rascunho da arquitetura

Isso fornece uma visã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 numa fase posterior.

Sair da placa de revisão da arquitetura

O Architecture Review Board é um órgão interorganizacional que:
  • supervisiona a implementação de uma estratégia coerente
  • garante a conformidade dos sistemas
O conselho de revisão deve ser representativo de todas as partes interessadas envolvidas na arquitetura. Normalmente, eles serã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 comparados aos KPIs

Scripts de automação e casos básicos de uso automatizado:
  • adaptado ao conteúdo da produção
  • verificado em relação aos KPIs

Estratégia de teste automatizado

Esta 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 testes de automação para ajudar a garantir:
  • um retorno sobre o investimento (ROI) mais alto
  • maior cobertura de teste
  • maior confiabilidade no teste com repetição de qualidade

Estratégia de teste automatizada validada em relação à carga realista e esperada

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

Estratégia de automação

A automação de implantações garante implantações mais rápidas e consistentes. A estratégia de automatização descreve a configuração de tais mecanismos de automatização; incluindo:
  • frequência
  • ferramentas a utilizar
  • ambientes a serem implantados em

Conscientes do plano de comunicação

Toda a equipe do projeto e todas as partes interessadas devem confirmar que estão cientes:
  • estrutura de relatórios
  • cadência de relatórios
  • canais de comunicação

Conscientes de definições e critérios de sucesso

Toda a equipe do projeto e todas as partes interessadas devem confirmar que estão cientes:
  • definições de sucesso
  • critérios de sucesso

Conceito de backup e restauração

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.

Teste de backup e restauração

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

Caso(s) comercial(is)

Um documento de caso comercial apresenta os argumentos relacionados com a tomada da ação, a tomada de medidas alternativas (se disponíveis) ou a não tomada de qualquer ação. Os argumentos devem ser equilibrados, baseados em fatos concretos (sempre que possível/relevantes) 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

O Analista de negócios deve confirmar que entende completamente:
  • âmbito do projeto
  • todas as expectativas do cliente
  • que essa é a base de todas as decisões tomadas por pessoa, por fase do projeto

KPIs de negócios

As organizações usam os Indicadores-chave de desempenho (KPIs) para avaliar seu sucesso ao atingir metas.
Os KPIs de negócios definem valores mensuráveis que demonstram a eficácia de uma empresa em atingir objetivos-chave de negócios. É importante escolher os KPIs adequados à sua empresa/cenário com definições claras do que são, como serão avaliados, como serão usados e por quem.

Documentação de requisitos de empresa

Um documento de requisitos de negócios (BRD) detalha a solução de negócios para um projeto, fornecendo uma especificação clara das necessidades e expectativas de negócios do cliente. A BRD também distingue entre a solução de negócios e a solução técnica.
Ao examinar a solução de negócios, o BRD deve responder à pergunta: "O que o negócio quer fazer?"

Desconecte-se de qualquer ajuste necessário à solução ou arquitetura identificada e alinhada às expectativas de ROI e KPI

Os processos de avaliação dos riscos e de ensaio de penetração podem suscitar problemas e resultados que devem ser abordados na arquitetura ou no desenvolvimento da solução.
Quaisquer ajustamentos resultantes destes processos têm de ser revistos e aprovados pelas empresas e aferidos em função dos objetivos globais.

Estratégia de cache

A estratégia de 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

As diretrizes de codificação definem os princípios básicos que os desenvolvedores devem seguir ao desenvolver a solução. Estes podem incluir, entre outros:
  • convenções de nomenclatura
  • uso do serviço
  • uso da biblioteca

Comunicar Manual de Operações

Certifique-se de que todas as pessoas/funções apropriadas receberam o Manual de Operações.

Comunicar o relatório de teste de desempenho

Certifique-se de que todas as pessoas/funções apropriadas tenham recebido o Relatório de teste de desempenho.

Comunicar notas de versão

Certifique-se de que todas as pessoas/funções apropriadas receberam as Notas de versão.

Comunicar escopo e expectativas ao grupo

Certifique-se de que a equipe do projeto esteja totalmente ciente e alinhada ao escopo do projeto e às expectativas de entrega.

Comunicar materiais de treinamento e guias de usuário

Certifique-se de que todas as pessoas/funções apropriadas recebam os materiais de treinamento e os guias do usuário.

Conformidade com os requisitos de segurança do cliente

Verifique se todos os requisitos de segurança do cliente estão em vigor.

Conformidade com o conceito de segurança

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

Conceito de relacionamento entre componentes e modelos

O outline dos modelos e componentes que serão usados no novo aplicativo. Inclui detalhes como regras de herança, permissões e relações, entre outros.

Especificação de relacionamento de componentes e modelos

Detalhes do conceito de relacionamento entre componentes e modelos.

Especificação de componentes

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

Conceito para mock-ups de interfaces externas

O conceito de como desenvolver e testar quaisquer interfaces externas que possam não estar abertas/disponíveis 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 à produção.

Documento da arquitetura de conteúdo

Documentação da arquitetura proposta do conteúdo. Os pormenores devem incluir (entre outros):
  • árvore de conteúdo
  • marcação de conceitos
  • estratégias para a reutilização de conteúdo

Conteúdo validado para migração

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

Projeto de contrato

Um projeto inicial do contrato legal.

Estrutura e formato do conteúdo atual

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

Política de backup e restauração do cliente

Políticas do cliente relativas:
  • processos de backup para dados e solução
  • armazenamento do backup
  • confirmação de que o backup está funcionando como esperado
  • restauração, em caso de falha

Diretrizes de codificação do cliente

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

Políticas de implantação/liberação do cliente

Políticas do cliente que definem como e quando implantações/versões podem ser feitas.
Geralmente, incluem-se linhas do tempo, programação e requisitos de aprovação.

Políticas ou requisitos de monitoramento do cliente

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

Programação de lançamento de produção do cliente

A programação definida pelo cliente para lançamentos nos ambientes de produção.

Políticas e requisitos de relatórios do cliente

Quaisquer políticas e/ou requisitos que o cliente tenha em relação aos relatórios. Eles podem incluir:
  • com que frequência relatórios específicos devem ser entregues
  • o formato para relatórios específicos
  • requisitos especiais

Roteiro do cliente

Elaborar um roteiro das principais etapas a implementar, tanto tecnológicas como empresariais. Esse roteiro é então comunicado ao cliente.

Políticas de segurança do cliente

O cliente (empresa e TI) terá políticas que definem os níveis de segurança necessários para a solução. Eles podem incluir:
  • Requisitos para a aprovação de uma avaliação de risco.
  • Requisitos aplicáveis aos ensaios de penetração de passagem.
  • Quaisquer requisitos específicos de segurança; como escape de todos os campos de entrada, uso de criptografia (SSL), certificados e autenticação e sessão.

Diretrizes de especificação do cliente

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

Relatórios de teste do cliente

Relatórios do cliente para o cliente potencial de qualidade durante o período UAT (User Acceptance Test).

Personalizações e correções que afetam atualizações documentadas

Quaisquer correções personalizadas e/ou aplicadas aplicadas devem ser documentadas, pois podem afetar futuras atualizações:
  • O AEM pode ser altamente personalizado para atender às necessidades dos negócios. Todas as personalizações que possam afetar a atualização devem ser totalmente documentadas. Por exemplo, quaisquer alterações importantes na interface do usuário (IU) do AEM.
  • Todas as atualizações necessárias para a solução atual devem estar completamente documentadas; podem incluir:
    • pacotes de correção cumulativos (CFP)
    • service packs (SP)
    • hotfixes
    • atualizações

Relatório de teste de aceitação de usuário diário

Relatórios ou reuniões resultantes do Teste de aceitação de usuário (UAT). Eles devem detalhar:
  • os problemas reportados
  • priorização destas questões

Segurança padrão ativada

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

Políticas e processos de implantação/versão

Políticas formalizadas que abrangem a implantação e a(s) versão(ões) do projeto. Eles podem incluir:
  • tempo de lançamento
  • planeamento de férias
  • frequência
  • e pode depender do ambiente em questão

Cadência de implantação estabelecida

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

Metodologia de desenvolvimento

Uma metodologia de desenvolvimento de software envolve quebrar todo o processo de desenvolvimento de software em fases (ou etapas) distintas, cada uma com atividades distintas. O objetivo é melhorar o planeamento e a gestão.
Ao definir a metodologia, você deve pré-definir resultados e artefatos específicos criados e concluídos pela equipe do projeto para desenvolver ou manter seu aplicativo.

Definição da função de desenvolvimento

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

Ambiente de desenvolvimento pronto

Certifique-se de que o ambiente de desenvolvimento esteja configurado com a ferramenta integrada necessária para a automação de implantações.

Equipe de desenvolvimento entende o escopo do projeto e as expectativas

A equipe de desenvolvimento deve confirmar que compreende perfeitamente:
  • âmbito do projeto
  • todas as expectativas do cliente
  • que essa é a base de todas as decisões tomadas por pessoa, por fase do projeto

Especificação de caixas de diálogo

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

Configuração do Ambiente de Desenvolvimento de Documentos

Documentação do ambiente de desenvolvimento.

Configuração do Ambiente de Produção de Documentos

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

Configuração do Ambiente de Teste de Documento

Documentação do ambiente de teste.

Teste de durabilidade

O teste de durabilidade mostra o desempenho da solução sob uma carga específica. Os testes medem o tempo de sobrevivência da solução quando submetida à carga limite e em que níveis de desempenho.

Teste de durabilidade executado

Execução do(s) teste(s) de durabilidade.

Erro ao lidar com o conceito

A manipulação 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

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

Processos de escalonamento

Definição de todos os processos de escalonamento. Haverá processos separados para cada nível de projeto:
  • Equipe do projeto
  • Cliente
  • Adobe

Estabelecer Sessões Regulares de Revisão de Qualidade

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

Estrutura de permissões existente

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

Mapa de sistemas existentes

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

Definições e critérios de sucesso esperados

O patrocinador do projeto coleta as expectativas de negócios relacionadas ao sucesso do projeto. É importante ter à disposição o conjunto completo de expectativas no início de um projeto, uma vez que estas devem influenciar todas as decisões tomadas ao longo da sua execução.
As expectativas podem incluir:
  • KPIs específicos, como o aumento percentual de páginas servidas
  • menos tempo para publicar conteúdo
  • objetivos de nível superior, como uma interface fácil de usar

Requisitos dos designs de experiência

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

Detalhes dos requisitos de design da experiência.

Dependências externas do sistema e do usuário/Contexto do sistema

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 de fallback e procedimento

A definição do sistema de fallback:
  • as funcionalidades críticas para os negócios que devem continuar a operar em caso de falha crítica
  • os processos necessários em caso de recuperação

Sistema de fallback e procedimento testados

Teste completo do sistema de fallback.

Sign-off do sistema de fallback dos participantes da empresa

Assinar, junto das partes interessadas, que o sistema de fallback e os procedimentos relacionados irão garantir as funcionalidades críticas dos negócios.

Confirmação de viabilidade em KPIs

Resultados de um estudo de viabilidade para o AEM e o projeto de solução de alto nível. Estes devem ser medidos em relação aos KPIs, a fim de garantir que estes possam ser cumpridos.

Contrato Finalizado

É necessário um contrato concluído e assinado antes de prosseguir com o projeto. Este projeto baseia-se no Contrato .

Funcionalidade da solução aceita pelas partes interessadas

Confirmação de que as partes interessadas aceitam plenamente:
  • funcionalidade da solução
  • quaisquer problemas conhecidos na solução

Agendamento ao vivo

Linha do tempo e programação das atividades necessárias para:
  • preparação para entrar no ar
  • o real vai ao vivo

Caminhos felizes Definidos

Um caminho feliz é um cenário padrão sem condições excepcionais ou de erro. É composto pela sequência de atividades executadas quando tudo corre como esperado.

Estimativas de hardware

Estimativas iniciais de:
  • o hardware necessário para a instalação básica do AEM
  • quaisquer requisitos adicionais, com base no projeto de solução de alto nível

O hardware estará disponível para atender aos requisitos

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

Requisitos de alto nível

A definição dos requisitos de alto nível fornece uma desagregação generalizada dos requisitos do sistema, abrangendo aspectos como:
  • Processos de negócios
  • Principais funções do sistema
Os detalhes básicos sobre essas funções são geralmente conhecidos, portanto este documento não deve ser uma estimativa.

Design de soluções de alto nível

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

Mapa do sistema de alto nível

Este mapa do sistema deve fornecer um diagrama de alto nível do sistema. É diferente do Contexto da solução, pois é um mapa generalizado de todos os sistemas envolvidos, não há interfaces neste diagrama.

Estrutura do conteúdo histórico

Definição da estrutura de conteúdo do sistema herdado. Esta opção é utilizada como referência e também na preparação da estratégia de migração.

KPIs de desempenho histórico e desempenho histórico

Você precisa coletar e documentar estatísticas de desempenho e KPIs de desempenho do sistema herdado. Estes são então utilizados como ponto de referência e para aferir a nova solução.

Identificar as principais soluções/funcionalidades

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

Implementação - mudanças com base nos resultados dos testes de penetração

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

Implementação - Estratégia de teste automatizada

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

Implementação - Estratégia de automação

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

Implementação - Arquitetura de conteúdo

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

Implementação - Experience Design

Implementação dos requisitos para suportar o Experience Design.

Implementação - Sistema de fallback e procedimentos

Aplicação do sistema de emergência e procedimentos conexos.

Implementação - Integração

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

Implementação - Estratégia de migração

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

Implementação - funções e direitos

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

Implementação - Conceito de segurança

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

Implementação - Software de segurança

Implementação da segurança do aplicativo de software.

Implementação - Conceito de segurança da arquitetura do sistema

Implementação da segurança do sistema.

Implementação - Tratamento de URL

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

Implementação - fluxos de trabalho

Implementação dos fluxos de trabalho projetados.

Conceito de implementação

O conceito de implementação fornece os princípios orientadores para toda a implementação. Deve ter em conta:
  • Operações
  • Manutenção
  • Compatibilidade
  • Reutilização
  • Segurança
  • Escalabilidade
Este conceito também pode delinear as estruturas, bibliotecas e outros artefatos usados na solução.

Informe o suporte da Adobe sobre a programação em tempo real

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

Designs de experiência iniciais

Conceitos preliminares para os projetos das experiências.

Teste de integração

Teste e a confirmação resultante de todas as integrações, tanto internas quanto externas.
Isso deve ser automatizado e executado com frequência para garantir a estabilidade do sistema.

Processo de rastreamento de edição

Processos claros registram todos os problemas encontrados e acompanham as atividades em curso, com o objetivo de garantir que todos os problemas sejam abordados.

Sistema de rastreamento de problemas e processos

Um sistema de rastreamento, juntamente com os processos necessários, para registrar todos os problemas encontrados e acompanhar as atividades em curso, com o objetivo de garantir que todos os problemas sejam abordados.
Todas as partes interessadas no projeto devem ter acesso a fim de facilitar a transparência do estatuto do projeto.
Exemplos incluem Atlassian JIRA e HP Quality Center.

O processo do sistema de rastreamento de problemas está configurado e integrado

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

Sistema antigo

Para o seu projeto, o sistema herdado é a tecnologia, o sistema de computador ou o programa de aplicativos existentes que serão substituídos pela nova solução.
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

Um resumo das ferramentas a utilizar na execução; as ferramentas devem incluir:
  • ferramentas de documentação
  • ferramentas de rastreamento de problemas
  • ferramentas de implantação
  • ferramentas de construção

Lista de usuários que exigem acesso ao portal de suporte da Adobe

Uma lista de todos os usuários e funções que precisarão acessar o Portal de suporte da Adobe.
Normalmente, a lista é composta pelo arquiteto de soluções e/ou pela equipe de TI do cliente.

Análise do arquivo de log

Uma análise, juntamente com as recomendações resultantes, definindo o que precisa ser registrado para monitorar a solução:
  • atividades a registrar
  • nível de granularidade
  • informações registradas para cada atividade

Tarefas de manutenção (específicas do AEM) testadas e ativadas

Testar e ativar tarefas de manutenção do AEM, como:
  • compactação
  • limpeza do sistema
  • remoção de fluxo de trabalho

Plano de migração

Documentar a migração; incluindo
  • linha do tempo para a migração
  • plano de manutenção de conteúdo, de acordo com a estratégia de migração

Estratégia de migração

Uma descrição completa do conteúdo, da arquitetura de conteúdo e dos formatos existentes mapeados para a nova solução. Deve abranger:
  • pormenores técnicos da migração automática, se possível
  • testes de fumaça para executar após a migração, para validar o conteúdo migrado
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 o início real do novo sistema. Isso pode significar um congelamento de conteúdo, uma dupla publicação ou a manutenção de um sistema alfa.

Monitoramento - CPU

Monitorando o uso da CPU do sistema pela solução:
  • média
  • picos

Monitoramento - E/S de disco

Monitorando as taxas de entrada e saída de disco da solução:
  • média
  • picos

Monitoramento - Espaço em disco

Monitorando o uso de espaço em disco pela solução:
  • média
  • crescimento ao longo do tempo
Você deve monitorar o uso ao:
  • repositório
  • arquivos de registro

Monitoramento - Sistema(s) Externo(s)

Monitore todas as conexões entre a solução e os sistemas externos:
  • taxa de tráfego
  • picos
  • estabilidade

Monitoramento - Largura de banda da rede

Monitore o uso da largura de banda de rede da solução:
  • taxa média de tráfego
  • picos
  • estabilidade

Monitoramento - Solicitações

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

Monitoramento - Pontos de segurança

Monitore nos pontos de segurança definidos.

Monitoramento - Sistema

Monitorar o sistema em geral; por exemplo:
  • disponibilidade
  • desempenho médio
  • picos de desempenho
  • alertas

Controlo - Limiar e Intervenção

Monitorização do limiar definido pela solução juntamente com a implementação de medidas de intervenção para reduzir a carga.

Conceito de monitoramento

Os conceitos de monitoramento a serem aplicados à sua solução; incorporando:
  • Monitoramento padrão do AEM
  • monitorização do sistema
  • requisitos de monitoramento específicos do cliente

Monitorando possíveis pontos fracos

Devem ser identificados e definidos pontos específicos susceptíveis de falha. Todas as tarefas de acompanhamento relacionadas com estas devem também ser definidas.
Os exemplos incluem (entre outros):
  • fluxos de trabalho principais
  • processamento de transações
  • pontos de integração

Política de monitoramento comunicada ao engenheiro de sistemas

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

Relatórios de monitoramento - Estrutura em vigor

Definir:
  • quando os relatórios de monitoramento devem ser gerados
  • a quem devem ser entregues

Documentação de tarefas operacionais

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

Manual de Operações

Manual que fornece todas as informações necessárias para as operações bem-sucedidas e para a manutenção da solução:
  • todas as tarefas operacionais
  • principais contatos
  • planos de implantação
  • listas de verificação pré/pós implantação
  • quaisquer outras tarefas críticas
Devem também especificar os conceitos de implementação para:
  • atendendo aos KPIs de desempenho
  • dimensionamento da solução para continuar a atender a esses KPIs

Pacote preparado

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

Ensaios de penetração

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

Testes de Penetração - Aprovado

Todos os critérios obrigatórios foram aprovados.

Testes de penetração - resultados

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

Conceito de desempenho e escalabilidade

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

O Performance Benchmark é 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

Eles definem os Indicadores-chave de desempenho (KPIs) 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

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

Testes de desempenho - os resultados correspondem aos KPIs de desempenho

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

Conceito de teste baseado em pessoa

O teste baseado em pessoa é um método baseado nas diferentes personagens descritas nos Experience Designs. Ele também testa as contas e seus níveis de permissões relacionados.
Isso é usado com frequência no UAT (User Acceptance Testing, teste de aceitação de usuário).

Teste e verificação do POC com base na documentação do requisito

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

Lista de verificação pós-implantação

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 de pré-implantação

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

É comum executar um teste básico em uma instalação padrão do AEM. Isso é usado como um benchmark para testar a implementação e o hardware.

Ambiente de produção pronto

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

Sign-off de produção dos participantes da empresa

Antes de Ir ao vivo para o ambiente de produção, o Production Sign off (PSO) deve ser concedido. Esse é o resultado de uma revisão da versão que entrará na produção, juntamente com quaisquer problemas conhecidos. O logoff é fornecido como parte do cronograma do Go Live.

Processo e política de logoff de produção

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

Plano de comunicação do projeto

Defina o plano de comunicação para as partes interessadas do negócio e para a equipe do projeto.

Esforços do projeto - Estimativas finais

As estimativas Esforços do Projeto - Estimativas Iniciais iniciais foram elevadas e efetuadas de acordo com os elevados requisitos de execução.
Estas são agora revistas, aperfeiçoadas e alargadas de modo a fornecer as estimativas finais. As estimativas devem ser fornecidas por cada líder de projeto adequado, incluindo gestão de projetos, consultoria, arquitetura, testes e desenvolvimento.
Estas estimativas são utilizadas para os recursos e a orçamentação.

Esforços do Projeto - Estimativas Iniciais

As estimativas iniciais são elevadas e efetuadas de acordo com os elevados requisitos de execução. Este processo será revisto e aperfeiçoado em fases posteriores.

Organização do projeto

A documentação necessária para descrever a organização e a estrutura de relatórios do projeto e da equipe.
Geralmente, assume o formulário ou inclui um gráfico para apresentar uma visão geral visual das linhas do tempo e responsabilidades. Há muitas ferramentas disponíveis para ajudar nisso.

Documento de escopo do projeto

O documento de escopo do projeto requer que você identifique e documente uma lista de:
  • Objetivos específicos do projeto
  • Resultados
  • Recursos
  • Funções
  • Tarefas
  • Prazos
  • Esforço planejado
Abrange o que deve ser alcançado, juntamente com o trabalho que deve ser feito, para a realização do projeto

Relatórios de status do projeto dentro de uma cadência definida

Relatórios de estado do projeto entregues de acordo com o calendário acordado e com o formato necessário.

Prova de conceito (POC)

A Prova de Conceito (POC) implementa uma gama limitada de funções para a solução.
Deverá ter por objetivo demonstrar a viabilidade da solução, verificar se esta pode cumprir o objetivo exigido e provar que existe o potencial da sua utilização.

Regras de Expurgação

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, a fim de manter a integridade e o tamanho do repositório.

Formato e cadência do relatório de qualidade

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

O gerenciador de projetos coordena todas as funções necessárias para a versão à produção.

Notas de versão

As notas de versão fazem parte da documentação da versão. As notas de versão devem abranger:
  • pré-requisitos
  • requisitos incluídos
  • problemas resolvidos
  • problemas conhecidos na versão
Ele é usado com o Runbook para executar etapas e verificações pré e pós instalação.
Para ver um exemplo, consulte as Notas de versão do AEM.

Versão em execução no ambiente de produção

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

Condições relevantes do contrato

Você deve destacar termos específicos do contrato que sejam relevantes para a implementação do projeto; como etapas contratuais, períodos de fatura ou requisitos de pessoal.

Apresentação de relatórios

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

Otimização do repositório

Os dados nunca são substituídos em um arquivo tar, o uso do disco aumenta mesmo quando apenas os dados existentes são atualizados.
Para contrariar o tamanho cada vez maior do repositório, uma estratégia de otimização é implementada para remover dados obsoletos.

Solicitação para configurar a seção do projeto no portal de suporte da Adobe

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

Documentação dos requisitos

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

Recursos disponíveis para suporte em funcionamento

Certifique-se de que todas as funções necessárias para entrar no ar estejam com equipe e disponíveis.

Avaliação do risco

A Avaliação de risco é executada pelo(s) departamento(s) de TI e/ou segurança do cliente.
Avalia os riscos técnicos e empresariais do projeto. A avaliação é necessária para a solução garantir a conformidade com as políticas de segurança.

Plano de redução do risco

O Plano de Mitigação do Risco inclui a Avaliação do Risco. Juntos, eles cobrem:
  • riscos identificados
  • possíveis soluções para esses riscos, caso surjam na implementação

Expectativas de ROI

Defina as expectativas de retorno sobre o investimento (ROI) anexadas à solução.
Pretendem 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

Especificação pormenorizada dos conceitos relativos às funções e direitos de acesso exigidos para a nova candidatura, incluindo uma descrição pormenorizada:
  • funções
  • grupos
  • usuários
  • permissões
  • bem como o gerenciamento e provisionamento de usuários

Conceito de funções e direitos atende às diretrizes de segurança

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

Uma especificação detalhada baseada no Conceito de funções e direitos.

Recomendações da arquitetura de segurança

Recomendações relacionadas à segurança para a arquitetura de software e hardware.

Diretrizes de codificação baseadas em segurança

Essas diretrizes definem como o código de desenvolvimento deve ser feito, com base em requisitos de segurança como:
  • convenções de nomenclatura
  • bibliotecas
  • orientações relativas aos quadros
  • Uso da API

Security Checklist

Lista de verificação específica de itens do projeto, com base no Conceito de segurança junto 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

Defina e documente os detalhes da configuração de segurança necessária para o aplicativo, a arquitetura e a infraestrutura.

Rascunho do conceito de segurança

Um resumo de alto nível cobrindo a configuração de segurança do:
  • aplicativo
  • arquitetura
  • infraestrutura

Problemas de segurança listados e avaliados

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

Logon de segurança dos participantes da empresa

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

Configurar processos de suporte

Defina os processos de suporte necessários.

SLAs para sistemas de terceiros

Certifique-se de que os SLAs (Service Level Agreements, contratos de nível de serviço) 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

Os testes de fumaça consistem em um conjunto de etapas definidas que testam as principais funcionalidades da solução para garantir as operações básicas e a funcionalidade da solução.
Eles são executados, em qualquer ambiente, após a instalação ou implantação.

Testes de fumaça executados para validação do sistema

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

Estratégia da arquitetura de software

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

Placa de revisão de solução estabelecida e conjunto de cadências da reunião

O Solution Review Board é geralmente composto de participantes do cliente.
O Conselho de Administração reúne-se regularmente para rever os requisitos atualmente abrangidos e as especificações relevantes numa base contínua. O objetivo é assegurar o alinhamento com a definição e os critérios de sucesso e contribuir também para o desenvolvimento dos requisitos.

Runbook de solução

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

Processo de aprovação e logoff da solução

O processo de aprovação e aprovação descreve os critérios que devem ser cumpridos antes que a solução possa ser lançada em um ambiente produtivo.
Pode também servir como um marco contratual.

Conceito de funcionalidade especial

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

Especificação de funcionalidade especial

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

Diretrizes de especificação

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

Processo de revisão e aprovação de especificações definido e comunicado

Deve ser implementado um processo claro de aprovação de especificações pelo cliente. Este processo garante clareza e firmeza do âmbito dos requisitos.

Equipe selecionada para treinamento de administrador do AEM

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

Equipe selecionada para treinamento de autor e usuário final

Equipe interna que precisará de treinamento para criar a solução.

Partes interessadas

As partes interessadas são os principais intervenientes e/ou papéis que têm 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 de definições e critérios de sucesso

Confirmação de que todas as partes interessadas fora da equipe de implementação real estão cientes do seguinte:
  • definições de sucesso
  • critérios de sucesso

As partes interessadas entendem o projeto e as expectativas

Confirmação de que todos os participantes fora da equipe de implementação real estão alinhados com o projeto geral e as expectativas, tanto internos à equipe do projeto quanto ao cliente.

Definição do Formato do Relatório de Status

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

Critérios de sucesso e definição

O cliente, o patrocinador do projeto e o gerente ou consultor do projeto devem especificar:
  • O que define um resultado bem-sucedido para o projeto.
  • Os critérios específicos necessários para satisfazer essa definição de sucesso.
São utilizados para garantir que os critérios de sucesso sejam cumpridos:
  • Como base para os KPIs.
  • Ao tomar decisões ao longo da execução.

Suporte na validação de problemas relatados

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

Processos de suporte e acesso ao portal de suporte da Adobe

O acesso ao portal de suporte da Adobe é fundamental para enviar tíquetes sobre qualquer problema com base em produtos que possa surgir durante a implementação.
O acesso deve ser alocado aos membros principais da equipe.

Definição da arquitetura do sistema

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

Documentação da arquitetura do sistema

Um documento que detalha a arquitetura do sistema; incluindo interfaces, localização de rede e integrações para todos os ambientes, entre outras informações.

Conceito de segurança da arquitetura do sistema

Uma descrição de alto nível de como tornar a arquitetura do sistema compatível com quaisquer políticas de segurança. Pode abranger:
  • firewalls e regras de firewall
  • zonas de segurança
  • gestores de tráfego locais e gerais
  • servidores web
  • proxies e proxies reversos

Fatores de risco do sistema identificados e verificados

Todos os fatores de risco encontrados na avaliação do risco (ou noutras revisões) são identificados e avaliados:
  • o nível de risco implícito em cada uma
  • juntamente com o esforço estimado para quaisquer alterações à execução necessárias para as resolver.

O grupo está ciente de definições e critérios de sucesso

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

A equipe está ciente do plano de comunicação

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 projeto e expectativas

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

Requisitos técnicos

Esses requisitos são específicos para a implementação técnica de serviços que suportam a solução.

Fatores de risco técnico verificados

Identificar e verificar os potenciais riscos técnicos. Os riscos técnicos podem incluir:
  • script entre sites
  • campos de entrada voltados para o usuário final
  • infraestrutura
  • idade da tecnologia
  • número de integrações
  • e dependências

Especificação técnica

A especificação técnica abrange (entre outras informações):
  • interfaces
  • configurações
  • APIs
  • serviços que suportam os requisitos da solução

Especificação do modelo

As especificações dos modelos necessários. Eles devem cobrir detalhes incluindo parsys, blueprint e mapeamento de herança, entre outros.
As especificações são baseadas nos requisitos de negócios e nos requisitos de experiência.

Test Cases

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

Testar conteúdo

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

Certifique-se de que o ambiente de teste esteja pronto, com implantações automatizadas em vigor, para garantir que todos os códigos de candidato a lançamento estejam atualizados para testes.

Relatórios de teste

Relatórios com os resultados dos ensaios; incluindo:
  • defeitos levantados
  • status dos casos de teste executados
  • outros tópicos relacionados à qualidade
Note-se que:
  • Qualquer equipe de ensaio deve poder manter-se neutra e apresentar os resultados dos ensaios.
  • Cabe ao gestor do projeto avaliar as implicações dos resultados e decidir as medidas adequadas.

Test Suite

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

Test Tool Suite Seleted

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

Conceito de teste

O conceito de ensaio é o quadro de testes muito elevado para o projeto; incluindo, controle de qualidade, UAT, desempenho, segurança e teste de integração.

Planos de teste

Estes planos descrevem em maior pormenor a execução de testes para cada fase de desenvolvimento e baseiam-se na Estratégia de Teste.

Escopo de teste

Esses requisitos são específicos para a implementação técnica de serviços que suportam a solução.

Estratégia de teste

A estratégia de teste descreve a estratégia de alto nível para garantia de qualidade e teste 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

Conceito de nível arquitetônico e de sistema para integração com sistemas de terceiros.

Especificação de integração de terceiros

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

Conceito de segurança de terceiros

Conceito para garantir a segurança de integrações de terceiros. Deve ser compatível com as políticas de segurança apropriadas.

Sistema de terceiros para integração

Verifique se todos os sistemas de terceiros estão disponíveis, com a documentação apropriada, para a implementação da integração.

Acesso a sistemas de terceiros ativado

Direitos de acesso obrigatórios concedidos às respectivas funções utilizadas em conjunto com sistemas de terceiros.

Conceito de teste de terceiros

Define:
  • casos de uso para testar as integrações
  • funcionalidade relacionada a qualquer aplicativo de terceiros

Definição de limite

Define os valores principais para pontos de monitoramento no sistema.
Por exemplo:
  • quantos quilobytes (KB) de registros não enviados geram um aviso na instância do servidor principal
  • o número de milissegundos de atraso médio por transação tolerados antes que um aviso seja gerado no servidor principal

Linha do tempo e marcos

Isso deve definir os prazos do projeto e os marcos contratuais a serem usados para:
  • Faturação.
  • Alinhamento com as definições de sucesso, critérios de sucesso e os KPIs.

Total de esforços do projeto

Todas as estimativas do esforço, de cada um dos clientes potenciais do projeto, devem ser consolidadas; incluindo despesas gerais, desenvolvimento, engenharia de sistemas, arquitetura e testes.
Se o acordo incluir um nível de apoio, os esforços de apoio e de operações devem também ser incluídos.

Materiais de treinamento

Materiais a serem usados em sessões de treinamento. Os materiais devem ser criados especificamente para a solução e projetados para serem usados em conjunto com os Guias do Usuário.

Compreende o escopo do projeto e as expectativas

A pessoa adequada deve confirmar que entende completamente:
  • âmbito do projeto
  • todas as expectativas do cliente
  • que essa é a base de todas as decisões tomadas por pessoa, por fase do projeto

Conceito de tratamento de URL

Seu conceito de tratamento de URL deve abranger funcionalidades de URL específicas do AEM, incluindo:
  • URLs personalizados
  • externalização de link
  • páginas de erro
  • mapeamento
O conceito deve também abranger:
  • quaisquer regras de regravação
  • hosts virtuais no servidor da Web
  • Considerações sobre SEO, como robots.txt
  • um mapa do site

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

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

Os Guias do Usuário fornecem informações e assistência para os usuários da solução:
  • editores
  • usuários avançados
  • administradores

Plano de Orçamento Validado

O plano orçamental deve ser revisto e validado por todas as partes interessadas. Eles precisam verificar detalhes como faturamento, valores e métodos/tempo do relatório de orçamento.

Resultados do teste da caixa branca

O teste de caixa branca é um método que testa as estruturas internas ou o funcionamento de um aplicativo, em vez de 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

Com base no conceito de fluxos de trabalho, essas especificações devem definir, em detalhes, as etapas que criarão o fluxo de trabalho completo.
A especificação de cada fluxo de trabalho deve incluir (no mínimo):
  • caso de uso
  • funções
  • etapas
  • resultados
  • manipulação de erros

Conceito de fluxos de trabalho

Os fluxos de trabalho permitem automatizar as atividades do AEM. O conceito de fluxos de trabalho descreve:
  • os processos que precisarão de automação
  • os serviços e as funções no AEM que serão afetados