Esta página fornece mais detalhes para desenvolver e/ou aumentar os documentos e princípios cobertos pela Lista de verificação de gerenciamento de projetos - práticas recomendadas.
As listas desta subseção não são exaustivas, mas destinam-se a uma introdução.
Ao implementar o AEM (especialmente pela primeira vez), você precisará revisar os recursos e workflows do AEM para ter certeza de quais áreas deseja/precisa.
Considere os recursos do AEM que você usará e o impacto no seu design; por exemplo:
Além disso, verifique as Notas de versão, para obter as várias versões do AEM, para ver quando novos recursos foram adicionados.
AEM pode ser integrado a outros produtos de Adobe e/ou serviços de terceiros. Eles podem aumentar a potência e a funcionalidade à sua disposição.
Consulte Integração de soluções para obter informações completas.
Uma consideração importante é se você deseja:
Ao mover de uma versão anterior para a atual, há duas opções:
Tal como acontece com qualquer projeto, é fundamental estabelecer regras básicas o mais rapidamente possível. Dentre elas:
Esses pontos são genéricos, a Lista de verificação de práticas recomendadas trata de detalhes específicos relacionados à AEM.
Funções
Estas devem ser claramente definidas e divulgadas a todos os participantes no projeto. Além disso, é aconselhável destacar:
Responsabilidades
Participação
Ao envolver as partes interessadas o mais rapidamente possível, você pode incentivá-las a se tornarem partes interessadas no projeto, aumentando assim o seu compromisso com o seu sucesso.
Caminhos de comunicação
Processos
Os processos a serem definidos dependerão de seu projeto individual. Tente novamente manter esses itens simples, considerando:
Ferramentas de rastreamento
Há muitas ferramentas disponíveis para rastrear informações sobre bugs, tarefas e outros aspectos do seu projeto - consulte Visão geral das ferramentas potenciais para obter mais detalhes.
Escopo
Definir claramente o que deve ser abrangido pelo projeto a vários níveis:
Relatório
Defina claramente que informações você reportará, de que forma, com que frequência e para quem.
Terminologia
Pressupostos
Estas informações podem ser definidas no Manual do Projeto; o uso de um Wiki também pode ajudar a garantir que as mudanças em andamento sejam tratadas de forma eficiente. Sempre que forem definidos, os principais fatores são os seguintes:
As organizações usam os Indicadores-chave de desempenho (KPIs) para avaliar seu sucesso ao atingir públicos alvos. Estes indicadores são valores mensuráveis que podem ser utilizados para demonstrar a eficácia do cumprimento de objetivos específicos.
Esses indicadores podem ser:
Negócios:
Show:
Alguns indicadores, mas não todos, podem ser baseados nas métricas de público alvo que você identifica e define.
As métricas são usadas para definir medidas quantitativas para a qualidade de seu site - elas são basicamente uma definição das metas de desempenho que você deseja atingir e podem ser usadas para definir seus KPIs (Indicadores-chave de desempenho).
Muitas métricas podem ser definidas, mas muitas vezes as que você define cobrem suas metas de desempenho e simultaneidade. Em particular, fatores que podem ser difíceis de quantificar e que muitas vezes estão sujeitos à avaliação emocional:
"nosso site está muito lento hoje" - quando lento se qualifica?
"tudo fica parado quando meu colega faz logon" - quantos usuários simultâneos podem suportar o sistema?
"quando eu pesquisar, o sistema fica parado " - que tipo de solicitações de pesquisa estão afetando o sistema?
"é necessário ages para fazer o download do arquivo" - quais são os tempos de download aceitáveis (em condições normais de rede)?
As métricas de público alvo são definidas no start de um projeto para:
Como sempre, é necessário ter cuidado ao definir as métricas de público alvo:
Durante o desenvolvimento do projeto, podem ser atualizados e ajustados conforme adequado. Depois que o projeto for implementado com êxito, ele poderá ser usado para ajudá-lo a controlar sua instalação e monitorar/manter os níveis de serviço necessários para a operação contínua.
Quando usadas corretamente, essas métricas podem fornecer uma ferramenta útil; quando usados de forma irresponsável, podem ser uma distração que desperdiça tempo. Como sempre, você precisa entender o que está medindo, como está medindo e por quê.
A presente seção aborda os princípios básicos e as questões a considerar. Cada instalação é diferente, portanto os valores reais a serem medidos serão diferentes.
Todas as métricas a serem medidas serão, de alguma forma, afetadas pelo design do seu projeto. Por outro lado, muitas questões serão melhor resolvidas através de mudanças de design.
Portanto, você deve definir suas métricas de público alvo antes de decidir sobre seu design. Isso permite otimizar seu design com base nesses fatores. Uma vez desenvolvido o seu projeto, será difícil introduzir quaisquer alterações nos princípios básicos de concepção.
Ao criar a estrutura para o site, siga a estrutura recomendada para AEM sites. Certifique-se de compreender os seguintes problemas e/ou princípios:
Se você achar que seu design não segue as diretrizes, ou se não tiver certeza sobre algumas das implicações, esclareça essas questões antes de start da fase de programação ou do preenchimento do conteúdo.
Para definir ou avaliar a infraestrutura, ajudará a definir valores de público alvo, como:
Dependendo da sua situação e do significado estratégico do site, isso o ajudará a avaliar e escolher sua infraestrutura:
Há vários fatores de desempenho que podem ser avaliados:
tempos de resposta para páginas individuais, levando em conta:
tempos de resposta para solicitações de pesquisa
Esta seção pode ser lida em conjunto com Performance Otimization, que expande os detalhes técnicos da medição real do desempenho.
Um problema chave é o tempo que seu site leva para responder às solicitações do visitante.
Embora esse valor varie para cada solicitação, um valor médio de público alvo pode ser definido. Uma vez que este valor seja comprovadamente alcançável e sustentável, poderá ser utilizado para acompanhar o desempenho do website e indicar o desenvolvimento de potenciais problemas
Diferentes públicos alvos em ambientes de autor e publicação
Os tempos de resposta desejados serão diferentes nos ambientes do autor e publicação, refletindo a audiência do público alvo:
Ambiente de criação
Esse ambiente é usado pelos autores que inserem e atualizam o conteúdo, portanto, ele deve:
Ambiente de publicação
Este ambiente contém conteúdo que você disponibiliza para seus usuários:
a velocidade ainda é vital, mas muitas vezes é mais lenta do que um ambiente do autor
são frequentemente aplicados mecanismos adicionais de melhoria do desempenho:
Então, como você pode decidir sobre tempos de resposta alcançáveis (médios)? Isso é frequentemente uma questão de experiência:
No entanto, (em circunstâncias controladas) podem ser aplicadas as seguintes orientações:
Os números acima assumem as seguintes condições:
Existem vários mecanismos que você pode usar para monitorar os tempos de resposta:
Monitorando os tempos de resposta com o AEM request.log
Um bom ponto de partida para a análise de desempenho é o registro de solicitações. Entre outras informações, você pode usar isso para ver os tempos de resposta de solicitações individuais. Consulte Otimização de Desempenho para obter mais detalhes.
Monitoramento de tempos de resposta com comentários HTML
*HTML comments* can be used to include response time information within the source of each page:
</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests
As solicitações de pesquisa podem ter um impacto significativo em seu site, em termos de:
Tempo de resposta da pesquisa real
Impacto no desempenho geral
A definição de públicos alvos para solicitações de pesquisa é, novamente, uma questão de experiência, dependendo de:
Eles devem ser planejados e integrados a partir do próprio start do seu projeto. Os mecanismos disponíveis para acompanhamento incluem:
Monitorando tempos de resposta de pesquisa com AEM request.log
Novamente, o request.log pode ser usado para monitorar os tempos de resposta das solicitações de pesquisa; consulte Otimização de Desempenho para obter mais detalhes.
Mecanismos programados para medir tempos de resposta de pesquisa
Para personalizar as informações coletadas sobre solicitações de pesquisa e seu desempenho, é recomendável incluir a coleta de informações no código-fonte do projeto; consulte Otimização de Desempenho para obter mais detalhes.
Seu site será disponibilizado para vários usuários/visitantes, tanto no autor quanto nos ambientes de publicação. Os números são geralmente mais altos do que você usou ao testar, mas também flutuantes e difíceis de prever. Seu site precisará ser projetado para um número médio de usuários/visitantes simultâneos sem notar um impacto negativo no desempenho. Novamente, request.log
pode ser usado para fazer testes de simultaneidade; consulte Otimização de Desempenho para obter mais detalhes.
Públicos alvos para o número de usuários simultâneos dependem do tipo de ambiente:
Ambiente de criação
Ambiente de publicação
Antes de discutir as métricas relacionadas, uma definição rápida dos termos:
Volume
Capacidade
Capacidade e volume
O quê / Onde | Capacidade | Volume |
---|---|---|
Cliente | Poder computacional do computador do usuário. | Complexidade do layout da página. |
Rede | Largura de banda da rede. | Tamanho da página (código, imagens e assim por diante). |
Cache do Dispatcher | Memória do servidor da Web (memória principal e disco rígido). | Servidor Web (memória principal e disco rígido). Número e tamanho das páginas em cache. |
Cache de saída | Memória do servidor AEM (memória principal e disco rígido). | Número e tamanho das páginas no cache de saída, o número de dependências por página. O cache do dispatcher diminui esse volume. |
Servidor Web | Poder computacional do servidor Web. | Quantidade de solicitações. O cache diminui esse volume. |
Modelo | Poder computacional do servidor Web. | Complexidade dos modelos. |
Repositório | Desempenho do repositório. | Número de páginas carregadas do repositório. |
As seções anteriores detalham as principais métricas a serem definidas.
Dependendo das suas necessidades específicas, pode ser útil definir métricas adicionais, isoladas ou levando em conta as classificações acima.
No entanto, é preferível ter um pequeno conjunto de métricas principais e precisas que funcionam de forma fácil e confiável, em vez de tentar medir e definir cada aspecto do site. Pela sua natureza pura, o seu website terá a start de mudar e evoluir assim que for entregue aos seus usuários.
A segurança é crucial e um desafio cada vez maior. Ele deve ser considerado e planejado a partir dos estágios iniciais do seu projeto.
A Lista de verificação de segurança detalha as etapas que você deve seguir para garantir que sua instalação AEM esteja segura quando implantada. Outros aspectos de segurança estão cobertos em Security (ao desenvolver) e User Administration and Security.
O seguinte:
Para uma nova implementação de um projeto padrão de AEM, é necessário considerar tarefas como:
Para todos os aspectos, é recomendável usar uma abordagem iterativa:
Divida a inicialização do projeto em Inicialização(ões) suave(s) (disponibilidade reduzida, várias iterações) e Inicialização forçada (disponibilidade total - ao vivo) para permitir o ajuste, a otimização e o treinamento do usuário em condições realistas no ambiente de produção.
Consulte a Lista de verificação do projeto para obter exemplos de tarefas que você deve executar (ou avaliar) durante o ciclo de vida do seu projeto.
Alguns pontos a serem observados para cada categoria são:
Desenvolvimento
Defina a arquitetura básica primeiro.
Use várias iterações (sprints) para o desenvolvimento:
Plano para a eventualidade de uma atualização da versão AEM disponível durante o projeto.
Plano de testes e otimização durante as impressões.
Plano para as fases de estabilização e otimização.
Crie um log de itens a serem planejados para novas versões.
Plano de participação e entrega dos parceiros.
Infraestrutura
Defina a arquitetura básica primeiro:
Usar várias iterações; para a primeira impressão e configuração inicial, prepare:
Planejar vários testes de carga.
Plano de testes e otimização durante as impressões.
Plano para uma fase de estabilização e otimização.
Implante para o ambiente de produção o mais cedo possível (permita que a equipe de operações configure o sistema para obter experiência).
Use usuários nomeados e funções definidas o mais cedo possível.
Plano de treinamento (por exemplo, treinamento de administrador).
Planeje a entrega para operações.
Conteúdo
Dependendo da lista de tarefa resultante, você pode fazer estimativas iniciais de tempo e esforço para definições de tarefas (de alto nível). Eles devem incluir uma indicação de quem (cliente ou parceiro) fará o que e quando.
A lista a seguir mostra aproximações padrão e inter-relações de esforço envolvido e, portanto, custos:
Estes valores só podem ser utilizados para estimativas iniciais. Um desenvolvedor AEM experiente deve fazer a análise detalhada.
Fase | Esforço |
---|---|
Desenvolvimento | Uma estimativa aproximada de 2 a 4 horas para cada nó de componente cobrirá todos os requisitos de desenvolvimento. |
Teste do desenvolvedor | 15% de Desenvolvimento |
Acompanhamento | 10% de Desenvolvimento |
Documentação | 15% de Desenvolvimento |
Documentação do JavaDoc | 10% de Desenvolvimento |
Correção de erros | 15% de Desenvolvimento |
Gerenciamento de projeto | 20% dos custos do projeto para gerenciamento e governança de projetos em andamento |
O planeamento detalhado pode então relacionar os recursos disponíveis ou necessários com prazos e custos.
A arquitetura de referência é fornecida para fornecer uma solução modelo para a arquitetura AEM. A arquitetura de referência soluciona problemas comumente encontrados para sistemas corporativos, incluindo dimensionamento, confiabilidade e segurança.
As seguintes métricas do site devem ser definidas:
Classificação | Definição |
---|---|
Número de sítios Internet | |
Número de sites da intranet | |
Número de bases de código (por exemplo, se a Internet e a intranet forem diferentes) | |
Número de páginas individuais | |
Número de visitas/dia ao site | |
Número de visualizações de página/dia | |
Volume (em GB) de transferência de dados/dia | |
Número de usuários simultâneos (Grupo de usuários fechado) | |
Número de visitantes simultâneos (publicar) | |
Número de autores simultâneos | |
Número de autores registrados | |
Número de ativações de página/dia útil | |
Número de ativações de página durante a implantação |
A lista a seguir é fornecida para informá-lo sobre as ferramentas que podem ser usadas. Ela é uma introdução, não é uma lista de recomendação extensa, e certamente não deve impedir você de usar quaisquer outros instrumentos que você preferir.
Produto | Descrição |
AEM | AEM fornece uma variedade de mecanismos para ajudá-lo a monitorar, testar, investigar e depurar seu aplicativo; incluindo: |
Selênio | O Seleniumis é uma ferramenta de teste de código aberto. Os testes são executados diretamente no navegador - emulando como os usuários funcionam. |
Microsoft Project | Uma ferramenta de gerenciamento de projetos comumente usada. |
Jira | Jirais é uma ferramenta de código aberto para rastrear e gerenciar detalhes de bugs de software. Workflows podem ser impostos aos detalhes do bug, conforme necessário. |
Git | Gite um software de controle de revisão. |
Eclipse | O Eclipse é um IDE de código aberto, composto por vários projetos. Eles estão voltados para a criação de uma plataforma de desenvolvimento aberta, composta de estruturas, ferramentas e tempos de execução extensíveis para a criação, implantação e gerenciamento de software ao longo do ciclo de vida. Consulte Como desenvolver projetos AEM usando o Eclipse para obter mais informações. |
IntelliJ | Um IDE profissional (e, portanto, sujeito aos custos de licenciamento) que oferece uma ampla variedade de recursos. Consulte Como desenvolver projetos AEM usando o IntelliJ IDEA para obter mais informações. |
Maven | O Mavenis é uma ferramenta de gerenciamento e compreensão de projetos de software que pode gerenciar o processo de construção de um projeto (software e documentação). |
Além disso, as seções seguintes são de especial interesse:
O Adobe fornece mais Práticas recomendadas para todas as fases e audiências: