Esta página proporciona más detalles para detallar y/o aumentar los documentos y principios que abarca la Administración de proyectos - Lista de comprobación de optimizaciones.
Las listas que figuran en esta subsección no son exhaustivas, sino que tienen por objeto ser una introducción.
Al implementar AEM (especialmente por primera vez), deberá revisar las capacidades y flujos de trabajo de AEM para asegurarse de qué áreas desea o necesita.
Considere las características de AEM que utilizará y el impacto en su diseño; por ejemplo:
Además, consulte las Notas de la versión para ver las distintas versiones de AEM, para ver cuándo se agregaron nuevas funciones.
AEM puede integrarse con otros productos de Adobe y/o servicios de terceros. Esto puede aumentar la potencia y la funcionalidad a su disposición.
Consulte Integración de soluciones para obtener información completa.
Una consideración importante es si desea:
Al pasar de una versión anterior a la versión actual, hay dos opciones:
Al igual que con cualquier proyecto, es fundamental establecer normas básicas lo antes posible. Entre estas características se incluyen:
Estos puntos son genéricos, la lista de comprobación de optimizaciones trata los detalles específicos en relación con AEM.
Funciones
Estos deben estar claramente definidos y ser conocidos por todos los participantes en el proyecto. Además, es aconsejable destacar:
Responsabilidades
Participación
Al hacer participar a las partes interesadas lo antes posible, puede alentarlas a convertirse en partes interesadas en el proyecto, aumentando así su compromiso con el éxito del proyecto.
Rutas de comunicación
Procesos
Los procesos que se definirán dependerán del proyecto individual. Intenta de nuevo mantener estas opciones sencillas, teniendo en cuenta:
Herramientas de seguimiento
Hay muchas herramientas disponibles para rastrear información sobre errores, tareas y otros aspectos de su proyecto; consulte Visión general de las herramientas posibles para obtener más detalles.
Ámbito
Definir claramente qué es lo que debe cubrir el proyecto a varios niveles:
Informes
Defina claramente qué información informará, en qué forma, con qué frecuencia y a quién.
Terminología
Suposiciones
Esta información puede definirse en un Manual del proyecto; el uso de una Wiki también puede ayudar a asegurar que los cambios en curso se manejen eficientemente. En todos los casos en que se definen, los factores clave son los siguientes:
Las organizaciones utilizan indicadores de rendimiento clave (KPI) para evaluar su éxito a la hora de alcanzar destinatarios. Estos indicadores son valores mensurables que pueden utilizarse para demostrar la eficacia con que se cumplen los objetivos específicos.
Estos indicadores pueden ser:
Negocios:
Actuación:
Algunos indicadores, pero no todos, se pueden basar en las métricas de destinatario que usted identifica y define.
Las métricas se utilizan para definir mediciones cuantitativas de la calidad de su sitio Web; son básicamente una definición de los objetivos de rendimiento que desea alcanzar y se pueden utilizar para definir los KPI (Indicadores de rendimiento clave).
Se pueden definir muchas métricas, pero a menudo las que defina cubren sus objetivos de rendimiento y concurrencia. En particular, factores que pueden ser difíciles de cuantificar y que a menudo son propensos a la evaluación emocional:
"nuestro sitio Web es demasiado lento hoy" - ¿cuándo lento califica?
"todo se paraliza cuando mi colega inicia sesión": ¿cuántos usuarios simultáneos pueden admitir el sistema?
"cuando busco, el sistema se paraliza " - ¿qué tipo de solicitudes de búsqueda afectan al sistema?
"Se necesita páginas para descargar el archivo" - ¿cuáles son los tiempos de descarga aceptables (bajo condiciones de red normales)?
Las métricas de destinatario se definen en el inicio de un proyecto para:
Como siempre se debe tener cuidado al definir las métricas de destinatario:
Durante el desarrollo del proyecto pueden actualizarse y sintonizarse según corresponda. Una vez que el proyecto se haya implementado correctamente, se pueden utilizar para ayudarle a controlar la instalación y supervisar/mantener los niveles de servicio necesarios para el funcionamiento continuo.
Cuando se utilizan correctamente, estas métricas pueden proporcionar una herramienta útil; cuando se utilizan irresponsablemente, pueden ser una distracción que desperdicia tiempo. Como siempre, se necesita entender lo que se mide, cómo se mide y por qué.
En esta sección se tratarán los principios básicos y las cuestiones que deben examinarse. Cada instalación es diferente, por lo que los valores reales que se medirán diferirán.
Todas las métricas que se medirán se verán afectadas, de alguna manera, por el diseño del proyecto. Por el contrario, muchos problemas se resolverán mejor con los cambios de diseño.
Por lo tanto, debe definir las métricas de destinatario antes de decidir el diseño. Esto le permite optimizar el diseño en función de estos factores. Una vez que el proyecto se haya desarrollado, será difícil realizar cambios en los principios básicos de diseño.
Cuando cree la estructura para el sitio web, siga la estructura recomendada para AEM sitios web. Asegúrese de comprender los siguientes problemas y/o principios:
Si cree que el diseño no sigue las directrices o no está seguro de algunas de las implicaciones, aclare estos problemas antes de realizar el inicio en la fase de programación o de rellenar el contenido.
Para definir o evaluar la infraestructura, ayudará a definir valores de destinatario como:
Según su situación y la importancia estratégica del sitio web, esto le ayudará a evaluar y elegir su infraestructura:
Existen varios factores de rendimiento que se pueden evaluar:
tiempos de respuesta para páginas individuales, teniendo en cuenta:
tiempos de respuesta para solicitudes de búsqueda
Esta sección se puede leer junto con Optimización del rendimiento que amplía los detalles técnicos para medir el rendimiento.
Un problema clave es el tiempo que tarda el sitio web en responder a las solicitudes de visitante.
Aunque este valor variará para cada solicitud, se puede definir un valor de destinatario promedio. Una vez que se ha demostrado que este valor es alcanzable y sostenible, puede utilizarse para monitorear el rendimiento del sitio web e indicar el desarrollo de posibles problemas
Diferentes destinatarios en los entornos de creación y publicación
Los tiempos de respuesta que va a buscar serán diferentes en los entornos de creación y publicación, lo que refleja la audiencia de destinatario:
Entorno de creación
Este entorno lo utilizan los autores que introducen y actualizan contenido, por lo que debe:
Entorno de publicación
Este entorno contiene el contenido que pone a disposición de los usuarios:
la velocidad sigue siendo vital, pero a menudo es más lenta que el entorno del autor
a menudo se aplican mecanismos adicionales de mejora del rendimiento:
Entonces, ¿cómo puede decidir los tiempos de respuesta alcanzables (promedio)? A menudo se trata de una cuestión de experiencia:
Sin embargo, en circunstancias controladas pueden aplicarse las siguientes directrices:
Los números anteriores asumen las siguientes condiciones:
Existen varios mecanismos que puede utilizar para supervisar los tiempos de respuesta:
Monitoreo de los tiempos de respuesta con AEM request.log
Un buen punto de partida para la análisis del rendimiento es el registro de solicitudes. Entre otra información, puede utilizarla para ver los tiempos de respuesta de solicitudes individuales. Consulte Optimización del rendimiento para obtener más detalles.
Supervisión de los tiempos de respuesta con comentarios 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
Las solicitudes de búsqueda pueden tener un impacto significativo en el sitio web, en términos de:
Tiempo de respuesta de la búsqueda real
Impacto en el rendimiento general
La configuración de destinatarios para solicitudes de búsqueda es, nuevamente, una cuestión de experiencia según:
Estos deben planificarse e integrarse desde el inicio mismo de su proyecto. Entre los mecanismos disponibles para la vigilancia figuran los siguientes:
Monitoreo de los tiempos de respuesta de búsqueda con AEM request.log
Nuevamente, request.log puede utilizarse para monitorear los tiempos de respuesta de las solicitudes de búsqueda; consulte Optimización del rendimiento para obtener más detalles.
Mecanismos programados para medir los tiempos de respuesta de búsqueda
Para personalizar la información que recopila sobre las solicitudes de búsqueda y su rendimiento, se recomienda incluir la recopilación de información en el código fuente del proyecto; consulte Optimización del rendimiento para obtener más detalles.
El sitio web estará disponible para varios usuarios/visitantes, tanto en los entornos de autor como de publicación. Los números suelen ser más de los que se usaban al realizar pruebas, pero también fluctúan y son difíciles de predecir. El sitio web deberá estar diseñado para un número promedio de usuarios/visitantes simultáneos sin que se observe un impacto negativo en el rendimiento. Nuevamente, el request.log
puede utilizarse para realizar pruebas de concurrencia; consulte Optimización del rendimiento para obtener más detalles.
Los destinatarios para el número de usuarios simultáneos dependen del tipo de entorno:
Entorno de creación
Entorno de publicación
Antes de analizar las métricas relacionadas, una definición rápida de los términos:
Volumen
Capacidad
Capacidad y volumen
Qué / Dónde | Capacidad | Volumen |
---|---|---|
Cliente | Potencia computacional del equipo del usuario. | Complejidad del diseño de página. |
Red | Ancho de banda de la red. | Tamaño de la página (código, imágenes, etc.). |
Caché de despachante | Memoria del servidor del servidor Web (memoria principal y disco duro). | Servidor web (memoria principal y disco duro). Número y tamaño de las páginas en caché. |
Caché de salida | Memoria del servidor del servidor AEM (memoria principal y unidad de disco duro). | Número y tamaño de las páginas en la caché de salida, número de dependencias por página. La caché del despachante disminuye este volumen. |
Servidor web | Potencia computacional del servidor Web. | Cantidad de solicitudes. El almacenamiento en caché reduce este volumen. |
Plantilla | Potencia computacional del servidor Web. | Complejidad de las plantillas. |
Repositorio | Rendimiento del repositorio. | Número de páginas cargadas desde el repositorio. |
Las secciones anteriores detallan las principales métricas que se van a definir.
Según sus requisitos específicos, puede resultar útil definir métricas adicionales, ya sea de forma aislada o teniendo en cuenta las clasificaciones anteriores.
Sin embargo, es preferible tener un pequeño conjunto de métricas principales precisas que funcionen de manera fácil y confiable, en lugar de intentar medir y definir cada aspecto del sitio web. Por su propia naturaleza, su sitio web tendrá el inicio de cambiar y evolucionar tan pronto como se entregue a sus usuarios.
La seguridad es crucial y un desafío cada vez mayor. Debe considerarse y planificarse desde las primeras etapas del proyecto.
La lista de comprobación de seguridad detalla los pasos que debe seguir para garantizar que la instalación de AEM sea segura cuando se implemente. Otros aspectos de seguridad se tratan en Seguridad (al desarrollar) y Administración y seguridad del usuario.
Lo siguiente:
Para una nueva implementación de un proyecto de AEM estándar, deberá considerar tareas como:
Se recomienda utilizar un enfoque iterativo en todos los aspectos:
Divida el lanzamiento del proyecto en Lanzamiento(s) en pantalla (disponibilidad reducida, varias iteraciones) y Inicio en disco (disponibilidad completa - Activo) para permitir el ajuste, la optimización y la capacitación del usuario en condiciones realistas en el entorno de producción.
Consulte la lista de comprobación del proyecto para ver ejemplos de tareas que debe realizar (o evaluar) durante el ciclo de vida del proyecto.
Algunos puntos a tener en cuenta para cada categoría son:
Desarrollo
Defina primero la arquitectura base.
Utilice varias iteraciones (sprints) para el desarrollo:
Planee la eventualidad de una actualización de la versión de AEM disponible durante el proyecto.
Planifique pruebas y optimización durante las copias.
Planee las fases de estabilización y optimización.
Cree un registro de los elementos que se planearán para futuras versiones.
Planee la participación y entrega de socios.
Infraestructura
Defina primero la arquitectura base:
Utilizar varias iteraciones; para el primer sprint y la configuración inicial prepare:
Planifique varias pruebas de carga.
Planifique pruebas y optimización durante las copias.
Planee una fase de estabilización y optimización.
Implemente en el entorno de producción lo antes posible (permita que el equipo de operaciones configure el sistema para obtener experiencia).
Utilice los usuarios con nombre y las funciones definidas lo antes posible.
Planee la formación (por ejemplo, formación de administrador).
Planifique la transferencia a las operaciones.
Contenido
En función de la lista de tarea resultante, puede realizar estimaciones iniciales de tiempo y esfuerzo para las definiciones de tarea (de alto nivel). Esto debe incluir una indicación de quién (cliente o socio) hará qué y cuándo.
La siguiente lista muestra las aproximaciones estándar y las interrelaciones de esfuerzo implicadas, y por lo tanto los costos:
Estas cifras sólo pueden utilizarse para las estimaciones iniciales. Un desarrollador AEM experimentado debe realizar la análisis detallada.
Fase | Esfuerzo |
---|---|
Desarrollo | Una estimación aproximada de 2 a 4 horas para cada nodo de componente cubrirá todos los requisitos de desarrollo. |
Prueba de desarrollador | 15% del desarrollo |
Seguimiento | 10% del desarrollo |
Documentación | 15% del desarrollo |
Documentación de JavaDoc | 10% del desarrollo |
Corrección de errores | 15% del desarrollo |
Administración de proyectos | 20% de los costos de los proyectos para la gestión y gestión de proyectos en curso |
La planificación detallada puede relacionar los recursos disponibles o necesarios con los plazos y los costos.
La arquitectura de referencia se proporciona para proporcionar una solución de plantilla para la arquitectura AEM. La arquitectura de referencia aborda los problemas que se suelen encontrar en los sistemas empresariales, como la escala, la fiabilidad y la seguridad.
Se deben definir las siguientes métricas del sitio:
Clasificación | Definición |
---|---|
Número de sitios de Internet | |
Número de sitios de intranet | |
Número de bases de código (por ejemplo, si Internet e intranet difieren) | |
Número de páginas individuales | |
Número de visitas al sitio / día | |
Número de vistas de página / día | |
Volumen (en GB) de transferencia de datos / día | |
Número de usuarios simultáneos (grupo de usuarios cerrado) | |
Número de visitantes simultáneos (publicación) | |
Número de autores simultáneos | |
Número de autores registrados | |
Número de activaciones de página / día laborable | |
Número de activaciones de página durante la implementación |
Se proporciona la siguiente lista para informarle de las herramientas que se pueden utilizar. Está pensada como una introducción, no como una lista extensiva de recomendaciones, y ciertamente no debería disuadirle de utilizar otras herramientas que prefiera.
Producto | Descripción |
AEM | El propio AEM proporciona una serie de mecanismos que le ayudan a supervisar, probar, investigar y depurar su aplicación; incluyendo: |
Selenio | Seleniumis una herramienta de prueba de código abierto. Las pruebas se ejecutan directamente en el explorador, emulando el funcionamiento de los usuarios. |
Microsoft Project | Una herramienta de gestión de proyectos de uso común. |
Jira | Jirais es una herramienta de código abierto para rastrear y administrar detalles de los errores de software. Se pueden imponer flujos de trabajo a los detalles del error según sea necesario. |
Git | Gitis un software de control de revisión. |
Eclipse | Eclipse es un IDE de código abierto, compuesto por varios proyectos. Se centran en la creación de una plataforma de desarrollo abierta compuesta de marcos, herramientas y tiempos de ejecución ampliables para la creación, implementación y administración de software durante todo el ciclo de vida. Consulte Cómo desarrollar proyectos AEM usando Eclipse para obtener más información. |
IntelliJ | Un IDE profesional (y, por lo tanto, responsable de los costes de licencia) que ofrece una amplia gama de características. Consulte Cómo desarrollar proyectos AEM usando IntelliJ IDEA para obtener más información. |
Maven | Mavenis es una herramienta de gestión y comprensión de proyectos de software que puede administrar el proceso de construcción de un proyecto (software y documentación). |
Además, las siguientes secciones son de particular interés:
Adobe proporciona otras optimizaciones para todas las fases y audiencias: