Este glossário lista (alfabeticamente) detalhes de todos os documentos entregáveis da Lista de verificação do projeto.
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.
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:
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 você possa não ser capaz de definir todos os detalhes no próprio start 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).
Verifique se os níveis necessários de acesso ao sistema foram concedidos a todas as funções.
A Lista de verificação de segurança do Adobe é a lista de verificação oficial fornecida para garantir que a AEM esteja segura na instalação. Ele contém as medidas de segurança e as etapas de verificação que você precisa executar para garantir a integridade da sua instância.
O Portal de suporte do 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 o Adobe.
Treinamento para a equipe administrativa da solução. Consulte os Serviços de treinamento do Adobe para obter mais informações.
Treinamento para a equipe que produzirá (cria) conteúdo para a solução. Consulte os Serviços de treinamento do Adobe para obter mais informações.
Certifique-se de que a pessoa apropriada esteja registrada para fazer os exames de certificação relevantes.
Certifique-se de que a pessoa apropriada tenha passado nos exames de certificação relevantes.
Fornecer formação técnica para a pessoa adequada; por exemplo, desenvolvedores, arquitetos, engenheiros e empresários.
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.
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.
Certifique-se de que a arquitetura de conteúdo proposta esteja alinhada aos KPIs (Indicadores-chave de desempenho) relevantes.
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.
A arquitetura de aplicativos deve definir claramente o comportamento dos aplicativos propostos.
O foco é:
Além das tarefas de manutenção padrão da Adobe Experience Manager (AEM), é necessário definir outras tarefas operacionais que precisam ser executadas para a manutenção contínua da solução.
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 AEM
pelo menos um arquiteto certificado AEM
pelo menos 75% dos desenvolvedores AEM certificados;
isso permite que os desenvolvedores certificados orientem os desenvolvedores secundários e garante o compartilhamento e a transparência do conhecimento
O diagrama da arquitetura é uma representação gráfica da arquitetura. Inclui representação de:
Isso fornece uma visualizaçã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.
O Architecture Review Board é um órgão interorganizacional que:
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.
Scripts de automação e casos básicos de uso 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:
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.
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:
Toda a equipe do projeto e todas as partes interessadas devem confirmar que estão cientes:
Toda a equipe do projeto e todas as partes interessadas devem confirmar que estão cientes:
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.
Um teste completo com base no conceito de backup e restauração.
Um documento de business case 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.
O Analista de negócios deve confirmar que entende completamente:
As organizações usam os Indicadores-chave de desempenho (KPIs) para avaliar seu sucesso ao atingir públicos alvos.
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.
Um BRD (Business Requirements documento, de requisitos de negócios) 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?"
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.
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.
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:
Certifique-se de que todas as pessoas/funções apropriadas receberam o Manual de Operações.
Certifique-se de que todas as pessoas/funções apropriadas tenham recebido o Relatório de teste de desempenho.
Certifique-se de que todas as pessoas/funções apropriadas receberam as Notas de versão.
Certifique-se de que a equipe do projeto esteja totalmente ciente e alinhada ao escopo do projeto e às expectativas do delivery.
Certifique-se de que todas as pessoas/funções apropriadas recebam os materiais de treinamento e os guias do usuário.
Verifique se todos os requisitos de segurança do cliente estão em vigor.
Certifique-se de que o Conceito de segurança esteja implementado.
A estrutura de tópicos 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.
Detalhes do conceito de relacionamento entre componentes e modelos.
Detalhes da especificação para cada um dos componentes a serem implementados.
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.
Documentação da arquitetura proposta do conteúdo. Os pormenores devem incluir (entre outros):
O conteúdo herdado do sistema é revisado e o conteúdo selecionado é validado para migração para a nova solução.
Um projeto inicial do contrato legal.
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íticas do cliente relativas:
Quaisquer diretrizes/requisitos do cliente sobre como o desenvolvimento deve ser feito.
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 e requisitos do cliente sobre o que deve ser monitorado. Além de quaisquer recomendações especificadas no Conceito de Monitorização.
A programação definida pelo cliente para lançamentos nos ambientes de produção.
Quaisquer políticas e/ou requisitos que o cliente tenha em relação ao relatórios. Eles podem incluir:
Elaborar um roteiro das principais etapas a implementar, tanto tecnológicas como empresariais. Esse roteiro é então comunicado ao 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:
Quaisquer diretrizes que o cliente tenha relacionadas ao formato, delivery e assinatura das especificações.
Relatórios do cliente para o cliente potencial de qualidade durante o período UAT (User Acceptance Test, Teste de aceitação de usuário).
Todas as personalizações e/ou hotfixes aplicados devem ser documentados, pois podem afetar futuras atualizações:
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:
Relatórios ou reuniões resultantes do Teste de aceitação de usuário (UAT). Eles devem detalhar:
Verifique se as configurações de segurança padrão para AEM foram ativadas/implementadas.
Políticas formalizadas que abrangem a implantação e a(s) versão(ões) do seu projeto. Eles podem incluir:
Defina a frequência necessária de implantações em ambientes.
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.
Defina qual desenvolvedor e/ou função está executando a TI (desempenho ou outros) e/ou testes de unidade na solução.
Certifique-se de que o ambiente de desenvolvimento esteja configurado com a ferramenta integrada necessária para a automação de implantações.
A equipe de desenvolvimento deve confirmar que compreende perfeitamente:
Detalhes sobre as caixas de diálogo necessárias para a solução.
Documentação do ambiente de desenvolvimento.
Documentação do ambiente de produção.
Documentação do ambiente de teste.
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.
Execução do(s) teste(s) de durabilidade.
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 detalhada do tratamento de erros proposto, com base no conceito de tratamento de erros.
Definição de todos os processos de escalonamento. Haverá processos separados para cada nível de projeto:
Estabelecer reuniões regulares de análise da qualidade com os membros da equipe apropriados.
Documentação do conjunto existente de permissões e grupos definidos para a solução herdada ou dentro da organização.
Um diagrama (ou conjunto de diagramas) dos sistemas e dependências existentes.
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 start de um projeto, uma vez que estas devem influenciar todas as decisões tomadas ao longo da execução.
As expectativas podem incluir:
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.
Detalhes dos requisitos de design da experiência.
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.
A definição do sistema de fallback:
Teste completo do sistema de fallback.
Assinar, junto das partes interessadas, que o sistema de fallback e os procedimentos relacionados irão garantir as funcionalidades críticas dos negócios.
Resultados de um estudo de viabilidade tanto para AEM como para a concepção de soluções de alto nível. Estes devem ser medidos em relação aos KPIs, a fim de garantir que estes possam ser cumpridos.
É necessário um contrato concluído e assinado antes de prosseguir com o projeto. Isso se baseia no Contrato Draft.
Confirmação de que as partes interessadas aceitam plenamente:
Linha do tempo e programação das atividades necessárias para:
Um caminho feliz é um cenário padrão sem condições excepcionais ou de erro. Ele é composto pela sequência de atividades executadas quando tudo corre como esperado.
Estimativas iniciais de:
Confirmação de que todos os ambientes terão o hardware mínimo necessário no lugar.
A definição dos requisitos de alto nível fornece uma desagregação generalizada dos requisitos do sistema, abrangendo aspectos como:
Os detalhes básicos sobre essas funções são geralmente conhecidos, portanto esse documento não deve ser uma estimativa.
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.
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.
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.
Você precisa coletar e documento de 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.
Uma lista das funcionalidades críticas dos negócios.
Implementação de todas as alterações necessárias (que foram canceladas) na solução com base nos resultados dos testes de penetração.
Configuração das ferramentas e dos processos necessários para suportar testes automatizados.
Configuração do conjunto de ferramentas e dos processos necessários para oferecer suporte à automação.
Implementação da arquitetura de conteúdo, marcação de conceitos e reutilização de conteúdo.
Implementação dos requisitos para suportar o Experience Design.
Aplicação do sistema de emergência e procedimentos conexos.
Implementação de integrações com todos os sistemas externos necessários.
Migração juntamente com a validação de conteúdo e outros artefatos para a nova solução.
Implementação de funções e direitos, usuários e grupos.
Aplicação de todas as medidas de segurança, incluindo os incumprimentos AEM.
Implementação da segurança do aplicativo de software.
Implementação da segurança do sistema.
Implementação do conceito de manipulação de URL.
Implementação dos workflows projetados.
O conceito de implementação fornece os princípios orientadores para toda a implementação. Deve ter em conta:
Este conceito também pode delinear as estruturas, bibliotecas e outros artefatos usados na solução.
Entre em contato com o suporte ao Adobe para garantir que qualquer suporte necessário possa ser ativado durante a ativação.
Conceitos preliminares para os projetos das experiências.
Testes 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.
Os processos claros registram todos os problemas encontrados e acompanham as atividades em curso com o objetivo de garantir que todos os problemas sejam abordados.
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 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.
A ferramenta selecionada está totalmente integrada e o acesso é concedido a todas as funções necessárias.
Para o seu projeto, o sistema herdado é a tecnologia existente, o sistema de computador ou o programa de aplicativo que será substituído 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.
Um resumo das ferramentas a utilizar na execução; as ferramentas devem incluir:
Uma lista de todos os usuários e funções que precisarão acessar o Portal de suporte do Adobe.
Normalmente, a lista é composta pelo arquiteto de soluções e/ou pela equipe de TI do cliente.
Uma análise, juntamente com as recomendações resultantes, definindo o que precisa ser registrado para monitorar a solução:
Testar e ativar AEM tarefas de manutenção, como:
Documento da migração; incluindo
Uma descrição completa do conteúdo, da arquitetura de conteúdo e dos formatos existentes 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 entrada em funcionamento do novo sistema. Isso pode significar um congelamento de conteúdo, publicação de duplos ou a manutenção de um sistema alfa.
Monitorando o uso da CPU do sistema pela solução:
Monitorando as taxas de entrada e saída de disco da solução:
Monitorando o uso de espaço em disco pela solução:
Você deve monitorar o uso ao:
Monitore todas as conexões entre a solução e os sistemas externos:
Monitore o uso da largura de banda de rede da solução:
Monitore as solicitações feitas na solução.
Monitore nos pontos de segurança definidos.
Monitorar o sistema em geral; por exemplo:
Monitorização do limiar definido pela solução juntamente com a implementação de medidas de intervenção para reduzir a carga.
Os conceitos de monitoramento a serem aplicados à sua solução; incorporando:
Devem ser identificados e definidos pontos específicos susceptíveis de falha. Devem também ser definidas quaisquer tarefas de monitorização relacionadas com estas.
Os exemplos incluem (entre outros):
Certifique-se de que os engenheiros do sistema e a equipe de operações conheçam e compreendam quaisquer políticas de monitoramento.
Definir:
Todas as tarefas operacionais documentadas, com sua frequência definida.
Manual que fornece todas as informações necessárias para as operações bem-sucedidas e para a manutenção da solução:
Devem também especificar os conceitos de implementação para:
Pacote de software criado e entregue pronto para implantaçã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.
Todos os critérios obrigatórios foram aprovados.
Relatórios criados para a empresa explicando os resultados do teste de penetração.
Documento conceitual sobre como garantir que sua implementação atenda aos KPIs de desempenho e como escalar a solução para que ela continue a atender a esses KPIs.
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.
Eles definem os Indicadores-chave de desempenho (KPIs) necessários para medir o desempenho do sistema. Alguns exemplos incluem tempo de carregamento da página, tempo de resposta do servidor e desempenho do query do banco de dados.
Relatórios criados para a empresa, detalhando os resultados dos testes de desempenho.
Os resultados devem corresponder aos KPIs definidos e às expectativas de desempenho.
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).
A Prova de conceito (POC) é aferida em relação aos requisitos para garantir que ambos estejam alinhados.
Uma lista de verificação para definir a série de verificações e tarefas a serem executadas após cada 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.
É normal executar um teste de linha de base em uma instalação padrão de AEM. Isso é usado como um benchmark para testar a implementação e o hardware.
Confirme se o ambiente de produção está pronto, com implantações automatizadas em vigor.
Antes de Go Live 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.
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.
Defina o plano de comunicação para as partes interessadas do negócio e para a equipe do projeto.
As estimativas iniciais eram de alto nível e efetuadas de acordo com os requisitos de alto nível para a implementação.
Estas são agora revistas, aperfeiçoadas e alargadas de modo a fornecerem 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.
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.
A documentação necessária para descrever a organização e a estrutura do 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.
O documento de escopo do projeto exige que você identifique e documento uma lista de:
Abrange o que deve ser alcançado, juntamente com o trabalho que deve ser feito, para a realização do projeto
Relatórios de estado do projeto entregues de acordo com o calendário acordado e com o formato necessário.
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.
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.
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.
O gerenciador de projetos coordena todas as funções necessárias para a versão à produção.
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 de pré e pós instalação.
Para ver um exemplo, consulte as Notas de versão AEM.
Versão final em execução e ativa na produção.
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.
Em conjunto com o cliente, defina a frequência dos relatórios entregues a ele.
Os dados nunca são sobrescritos 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.
A solicitação oficial para configurar seu projeto no Portal de suporte do Adobe.
Este conjunto de documentação cobre os requisitos funcionais e não funcionais, juntamente com os esforços estimados.
Certifique-se de que todas as funções necessárias para entrar no ar estejam com equipe e disponíveis.
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.
O Plano de Mitigação do Risco inclui a Avaliação do Risco. Juntos, eles cobrem:
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.
Especificação pormenorizada dos conceitos relativos às funções e direitos de acesso exigidos para a nova candidatura, incluindo uma descrição pormenorizada:
Revisão do conceito de Funções e Direitos para garantir que ele atenda às políticas de segurança.
Uma especificação detalhada baseada no Conceito de funções e direitos.
Recommendations relacionada à segurança para a arquitetura de software e hardware.
Essas diretrizes definem como o código de desenvolvimento deve ser feito, com base em requisitos de segurança como:
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 de pós-implantação no runbook.
Defina e documento os detalhes da configuração de segurança necessária para o aplicativo, a arquitetura e a infraestrutura.
Um resumo de alto nível cobrindo a configuração de segurança do:
Todas as questões de segurança da solução listadas e avaliadas; incluindo estimativas do esforço.
Faça logoff das partes interessadas para garantir que a implementação da segurança esteja em conformidade com as políticas e expectativas.
Defina os processos de suporte necessários.
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.
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.
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.
A estratégia de alto nível para a arquitetura do software; incluindo serviços, servlets, quadros e outras decisões de implementaçã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.
Instruções de instalação para a solução, juntamente com tarefas operacionais básicas a serem executadas na instalaçã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.
O conceito inicial para qualquer funcionalidade especial que seja considerada fora do escopo normal de desenvolvimento na plataforma AEM.
Detalhes de qualquer funcionalidade especial considerada fora do escopo normal de desenvolvimento na plataforma AEM.
Quaisquer diretrizes do cliente sobre como a especificação deve ser feita.
Deve ser implementado um processo claro para o cliente fazer logoff das especificações. Este processo garante a clareza e a firmeza do âmbito dos requisitos.
Equipe interna que precisará de treinamento para administrar a solução.
Equipe interna que precisará de treinamento para criar a solução.
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.
Confirmação de que todas as partes interessadas fora da equipe de implementação real estão cientes do seguinte:
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.
Os relatórios de status são uma ferramenta essencial de comunicação. O formato deve ser alinhado a quaisquer requisitos de relatórios do cliente.
O cliente, o patrocinador do projeto e o gerente ou consultor do projeto devem especificar:
São utilizados para garantir que os critérios de sucesso sejam cumpridos:
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, quando o relatórios causar problemas e para ajudar a validar os problemas em relação ao ambiente de teste.
O acesso ao Portal de suporte do Adobe é fundamental para enviar tíquetes sobre qualquer problema com base no produto que possa surgir durante a implementação.
O acesso deve ser alocado aos membros principais da equipe.
Uma proposta inicial e uma definição da arquitetura para todos os ambientes da solução.
Um documento detalhando a arquitetura do sistema; incluindo interfaces, localização de rede e integrações para todos os ambientes, entre outras informações.
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:
Todos os fatores de risco encontrados na avaliação do risco (ou noutras revisões) são identificados e avaliados:
Confirmação de que toda a equipe está ciente das definições e critérios de sucesso.
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.
Alinhamento com o projeto geral e as expectativas, tanto internas à equipe do projeto quanto ao cliente.
Esses requisitos são específicos para a implementação técnica de serviços que suportam a solução.
Identificar e verificar os potenciais riscos técnicos. Os riscos técnicos podem incluir:
A especificação técnica abrange (entre outras informações):
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.
Casos de teste específicos das etapas detalhadas necessárias para executar o teste funcional da solução.
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.
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 teste.
Relatórios que especifiquem os resultados dos ensaios; incluindo:
Note-se que:
Seleção do conjunto de automação e das ferramentas. Eles serão usados para automatizar testes, inclusive para casos de uso.
Conjunto de automação e ferramentas selecionados para automação de caso de uso e outras tarefas de execução de teste.
O conceito de ensaio é o quadro de testes de muito alto nível para o projeto; incluindo, controle de qualidade, UAT, desempenho, segurança e teste de integração.
Esses planos descrevem com mais detalhes a execução de testes para cada fase de desenvolvimento e são baseados na Estratégia de teste.
Esses requisitos são específicos para a implementação técnica de serviços que suportam a solução.
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 nível arquitetônico e de sistema para integração com sistemas de terceiros.
Detalhes dos requisitos (funcionais e não funcionais) para a funcionalidade suportada e integração de sistemas de terceiros.
Conceito para garantir a segurança de integrações de terceiros. Deve estar em conformidade com as políticas de segurança apropriadas.
Verifique se todos os sistemas de terceiros estão disponíveis, com a documentação apropriada, para a implementação da integração.
Direitos de acesso obrigatórios concedidos às respectivas funções utilizadas em conjunto com sistemas de terceiros.
Define:
Define os valores principais para pontos de monitoramento no sistema.
Por exemplo:
Isso deve definir os prazos do projeto e os marcos contratuais a serem usados para:
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 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.
A pessoa adequada deve confirmar que entende completamente:
Seu conceito de tratamento de URL deve abranger AEM funcionalidades específicas de URL, incluindo:
O conceito deve também abranger:
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.
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.
Os Guias do Usuário fornecem informações e assistência para os usuários da solução:
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órios do orçamento.
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.
Com base no conceito de Workflows, 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):
Workflows permitem automatizar AEM atividades. O conceito de Workflows descreve: