Este glosario lista (alfabéticamente) detalles de todos los documentos de entrega de la lista de comprobación del proyecto.
La aceptación por parte de las partes interesadas del negocio confirma que, como partes interesadas clave, están alineadas con la solución y han dado su aprobación en cuanto a la manera en que los requerimientos del negocio cumplen con los argumentos comerciales.
La prueba de aceptación se realiza cuando una aplicación está lista para la producción. Las pruebas las realiza un grupo que representa los distintos tipos de usuarios finales, utilizando escenarios de la vida real.
Las pruebas de aceptación se utilizan para confirmar que:
Cuanto antes planifique y diseñe las pruebas de aceptación, más fácil será la implementación final. Deben definirse junto con el cliente y su equipo de garantía de calidad.
Aunque es posible que no pueda definir todos los detalles en el inicio mismo del proyecto, las definiciones iniciales deben discutirse y acordarse. Las pruebas de aceptación se basarán probablemente en los requisitos fundamentales (funcional y de rendimiento).
Asegurarse de que los niveles requeridos de acceso al sistema se hayan concedido a todas las funciones.
La lista de comprobación de seguridad de Adobe es la lista de comprobación oficial proporcionada para garantizar que AEM es segura durante la instalación. Contiene las medidas de seguridad y los pasos de verificación que debe realizar para garantizar la integridad de su instancia.
El Portal de asistencia técnica de Adobe permite a los socios y clientes de implementación configurar la implementación de AEM como un proyecto en el Portal de asistencia técnica.
Pueden registrarse los detalles; por ejemplo, acerca de las tecnologías y versiones implementadas. Esto proporciona transparencia entre el cliente y el Adobe.
Formación del personal administrativo de la solución. Consulte los Servicios de capacitación de Adobe para obtener más información.
Formación para el personal que va a producir (crear) contenido para la solución. Consulte los Servicios de capacitación de Adobe para obtener más información.
Asegúrese de que se ha registrado a la persona adecuada para realizar los exámenes de certificación correspondientes.
Asegúrese de que la persona adecuada ha aprobado los exámenes de certificación relevantes.
Proporcionar formación técnica a la persona adecuada; por ejemplo, desarrolladores, arquitectos, ingenieros y profesionales del negocio.
Los indicadores de rendimiento clave (KPI) ayudan a una organización a definir y medir el progreso hacia los objetivos y metas de la organización. Una vez que una organización ha analizado su misión y definido sus objetivos, debe medir los progresos hacia el logro de esos objetivos. Los KPI proporcionan un mecanismo para la medición.
La alineación de su negocio y los indicadores de rendimiento clave (KPI) ayuda a reunir a todas las personas y procesos involucrados desde la organización. Esto, a su vez, ayuda a reducir la cantidad de tiempo y esfuerzo necesarios para alcanzar los objetivos comerciales y cumplir el propósito propuesto.
Asegúrese de que la arquitectura de contenido propuesta esté alineada con los indicadores de rendimiento clave (KPI) relevantes.
La Hoja de ruta del cliente está compuesta de hitos de alto nivel y objetivos comerciales. El cronograma del proyecto debe adherirse a esta estrategia y ajustarse a ella, de modo que se deben resaltar y rastrear los posibles riesgos y/o posibles desviaciones.
La arquitectura de aplicaciones debe definir claramente el comportamiento de las aplicaciones propuestas.
Se centra en:
Aparte de las tareas de mantenimiento estándar de Adobe Experience Manager (AEM), debe definir cualquier otra tarea operativa que deba ejecutarse para el mantenimiento continuo de la solución.
Asegúrese de que su equipo esté formado por personal con la formación adecuada. Para los equipos de proyecto, la recomendación es que tengan todas las siguientes características:
al menos un desarrollador líder AEM certificado
al menos un arquitecto AEM certificado
al menos el 75 % de los desarrolladores AEM certificados;
esto permite a los desarrolladores certificados asesorar a los desarrolladores junior y garantiza el intercambio de conocimientos y la transparencia
El diagrama de arquitectura es una representación gráfica de la arquitectura. Incluye la representación de:
Esto proporciona una vista de alto nivel de la arquitectura del sistema y la solución. En esta etapa se trata de un proyecto que será revisado y perfeccionado en etapas posteriores.
El Consejo de Revisión de la Arquitectura es un órgano interinstitucional que:
La junta de examen debería ser representativa de todos los principales interesados que participan en la arquitectura. Generalmente estarán formadas por un grupo de ejecutivos encargados de la revisión y el mantenimiento de la arquitectura general.
Secuencias de comandos de automatización y casos de uso automatizados básicos:
Esta estrategia define un marco para secuencias de comandos automatizadas reutilizables, junto con el enfoque planeado por el equipo de garantía de calidad (QA). Describe el plan general de pruebas de automatización para garantizar:
La estrategia de prueba automatizada debe validarse y ajustarse según el contenido y la carga esperada que habrá en la solución.
La automatización de las implementaciones garantiza implementaciones más rápidas y coherentes. La estrategia de automatización describe la configuración de dichos mecanismos de automatización; incluyendo:
Todo el equipo del proyecto y todas las partes interesadas deben confirmar que conocen:
Todo el equipo del proyecto y todas las partes interesadas deben confirmar que conocen:
El concepto de copia de seguridad y restauración describe la funcionalidad técnica que se implementará en la solución. La política de restauración y copia de seguridad de la Compañía lo requiere.
Prueba completa end-to-end basada en el concepto de backup y restore.
Un documento de caso empresarial presenta los argumentos relacionados con la acción, la adopción de medidas alternativas (si están disponibles) o la no adopción de ninguna medida. Los argumentos deben ser equilibrados, basarse en hechos concretos (siempre que sea posible/pertinente) y destacar tanto los beneficios como los riesgos en todos los casos.
Un documento de caso empresarial debería ser una definición clara de todas las opciones, concluyendo con un argumento convincente para la aplicación de la solución propuesta.
Business Analyst debe confirmar que comprende perfectamente:
Las organizaciones utilizan indicadores de rendimiento clave (KPI) para evaluar su éxito a la hora de alcanzar destinatarios.
Los KPI comerciales definen valores mensurables que muestran la eficacia con la que una compañía está alcanzando los objetivos comerciales clave. Es importante elegir KPI adecuados para su negocio o escenario con definiciones claras de cuáles son, cómo se medirán, cómo se utilizarán y quién los usará.
Un documento de requerimientos comerciales (BRD) detalla la solución comercial para un proyecto, proporcionando una clara especificación de las necesidades y expectativas comerciales del cliente. El BRD también distingue entre la solución comercial y la solución técnica.
Al examinar la solución comercial, el BRD debería responder a la pregunta: "¿Qué quiere hacer el negocio?"
Los procesos de evaluación del riesgo y los ensayos de penetración pueden producir problemas y resultados que deben abordarse en la arquitectura o el desarrollo de la solución.
Cualquier ajuste resultante de estos procesos debe ser revisado y aprobado por la empresa y comparado con los objetivos generales.
La estrategia de almacenamiento en caché describe lo que se almacenará en caché para el usuario final. Debe cumplir con los KPI de rendimiento.
Por ejemplo, elementos como imágenes, javascript y otros archivos de servidor se pueden almacenar en caché para mejorar el rendimiento de una solución.
Las Directrices de codificación definen los principios básicos a los que deben atenerse los desarrolladores al desarrollar la solución. Pueden incluir, entre otros:
Asegúrese de que todas las funciones y personas pertinentes han recibido el Manual de operaciones.
Asegúrese de que todas las funciones y personas pertinentes han recibido el informe Prueba de rendimiento.
Asegúrese de que todas las funciones y personas pertinentes han recibido las Notas de la versión.
Asegurar que el equipo del proyecto esté plenamente al tanto del alcance del proyecto y de las expectativas de envío, y esté en consonancia con él.
Asegúrese de que todas las funciones y personas pertinentes reciben el material de formación y las guías del usuario.
Asegúrese de que todos los requisitos de seguridad del cliente están implementados.
Asegúrese de que el Concepto de seguridad esté establecido.
Esquema de las plantillas y los componentes que se utilizarán en la nueva aplicación. Incluye detalles como reglas de herencia, permisos y relaciones, entre otros.
Detalles del concepto de relación de componentes y plantillas.
Detalles de especificación para cada uno de los componentes que se implementarán.
Concepto de cómo desarrollar y probar cualquier interfaz externa que no esté abierta o disponible para los entornos de desarrollo o ensayo.
Planifique e implemente modelos de estas interfaces para garantizar que las pruebas se acerquen lo más posible al comportamiento de producción.
Documentación de la arquitectura propuesta del contenido. Los detalles deberían incluir, entre otros:
El contenido heredado del sistema se revisa y el contenido seleccionado se valida para la migración a la nueva solución.
Proyecto inicial del contrato jurídico.
Documentación de la arquitectura y el formato de contenido actuales. Esto se utilizará para generar la futura arquitectura de contenido. También se utilizará para el concepto de migración.
Políticas del cliente relativas a:
Cualquier guía o requisito del cliente sobre cómo se debe realizar el desarrollo.
Políticas del cliente que definen cómo y cuándo se pueden realizar implementaciones/lanzamientos.
A menudo incluyen cronogramas, programaciones y requisitos de cierre de sesión.
Políticas y requisitos del cliente sobre lo que debe monitorearse. Éstas se suman a las recomendaciones especificadas en el Concepto de supervisión.
Programa definido por el cliente para las versiones de los entornos de producción.
Cualquier política o requisito que el cliente tenga en relación con el sistema de informes. Pueden incluir:
Formular una hoja de ruta de los principales hitos que se deben implementar, tanto tecnológicos como comerciales. Esta hoja de ruta se comunica entonces al cliente.
El cliente (comercial y de TI) tendrá políticas que definen los niveles de seguridad requeridos para la solución. Pueden incluir:
Cualquier guía que el cliente tenga en relación con el formato, el envío y la firma de las especificaciones.
Informes del cliente al posible cliente durante el período de prueba de aceptación del usuario (UAT).
Todas las personalizaciones y/o revisiones aplicadas deben documentarse, ya que pueden afectar a futuras actualizaciones:
AEM puede ser muy personalizado para adaptarse a las necesidades comerciales. Todas las personalizaciones que puedan afectar a la actualización deben estar completamente documentadas. Por ejemplo, cualquier cambio importante en la interfaz de usuario (IU) de AEM.
Todas las actualizaciones necesarias para la solución actual deben estar plenamente documentadas; pueden incluir:
Informes o reuniones resultantes de la prueba de aceptación del usuario (UAT). Deberían detallar:
Asegúrese de que la configuración de seguridad predeterminada para AEM se haya habilitado o implementado.
Directivas formalizadas que cubren tanto la implementación como las versiones del proyecto. Pueden incluir:
Defina la frecuencia necesaria de las implementaciones entre entornos.
Una metodología de desarrollo de software implica dividir todo el proceso de trabajo de desarrollo de software en diferentes fases (o etapas), cada una con distintas actividades. El objetivo es mejorar la planificación y la gestión.
Al definir la metodología, debe predefinir los productos y artefactos específicos creados y completados por el equipo del proyecto para desarrollar o mantener la aplicación.
Defina qué desarrollador y/o función ejecuta pruebas de TI (rendimiento u otros) y/o unidades dentro de la solución.
Asegúrese de que el entorno de desarrollo esté configurado con las herramientas integradas necesarias para la automatización de las implementaciones.
El Equipo de Desarrollo debería confirmar que comprende plenamente:
Detalles sobre los diálogos necesarios para la solución.
Documentación del entorno de desarrollo.
Documentación del entorno de producción.
Documentación del entorno de ensayo.
La prueba de durabilidad muestra el rendimiento de la solución bajo una carga específica. Las pruebas miden cuánto tiempo sobrevive la solución cuando se envía a la carga de umbral y a qué niveles de rendimiento.
Ejecución de las pruebas de durabilidad.
El manejo de errores se refiere a la anticipación, detección y resolución de errores de programación, aplicación y comunicación.
Documentación detallada de la gestión de errores propuesta, basada en el concepto de gestión de errores.
Definición de todos los procesos de escalación. Habrá procesos separados para cada nivel de proyecto:
Establecer reuniones periódicas de examen de calidad con los miembros del equipo correspondientes.
Documentación del conjunto existente de permisos y grupos definidos para la solución heredada o dentro de la organización.
Un diagrama (o conjunto de diagramas) de los sistemas y dependencias existentes.
El Patrocinador del Proyecto reúne las expectativas comerciales relacionadas con el éxito del proyecto. Es importante contar con todo el conjunto de expectativas disponibles en el inicio de un proyecto, ya que éstas deberían influir en todas las decisiones adoptadas durante la ejecución.
Las expectativas pueden incluir:
Requisitos para toda la experiencia de la solución. Esto abarca factores como la personalización, la persistencia entre dispositivos y la experiencia del usuario, entre otros.
Detalles de los requisitos de diseño de experiencia.
Un diagrama (o conjunto de diagramas) que describe todo el ecosistema de la solución. Esto debería incluir elementos como integraciones externas, interfaces, dependencias y redes.
Definición del sistema de reserva:
Prueba completa del sistema de reserva.
Firme, por parte de los interesados del negocio, que el sistema de reserva y los procedimientos relacionados garantizarán las funcionalidades críticas del negocio.
Resultados de un estudio de viabilidad tanto para el diseño de la solución de AEM como de alto nivel. Éstos deben medirse con respecto a los KPI para garantizar que se puedan cumplir.
Antes de continuar con el proyecto se necesita un contrato firmado y finalizado. Esto se basa en el Borrador del contrato.
Confirmación de que los interesados aceptan plenamente:
Cronología y programación de las actividades necesarias para:
Una ruta feliz es un escenario predeterminado que no presenta condiciones excepcionales o de error. Se compone de la secuencia de actividades ejecutadas cuando todo va según lo esperado.
Estimaciones iniciales de:
Confirmación de que todos los entornos tendrán el hardware mínimo requerido.
La definición de los requisitos de alto nivel ofrece un desglose generalizado de los requisitos del sistema, que abarca aspectos como:
Normalmente se conocen los detalles básicos sobre estas funciones, por lo que este documento no debe ser una estimación.
El diseño de la solución de alto nivel explica la arquitectura que se utilizará para desarrollar la solución. El diagrama de arquitectura ofrece una visión general de todo el sistema, identificando los principales componentes que se desarrollarán para el producto y sus interfaces.
Este mapa del sistema debería proporcionar un diagrama de nivel muy alto del sistema. Difiere del contexto de solución en que es un mapa generalizado de todos los sistemas involucrados, no hay interfaces en este diagrama.
Definición de la estructura de contenido del sistema heredado. Esto se utiliza como referencia y también al preparar la estrategia de migración.
Debe recopilar y documento estadísticas de rendimiento y KPI de rendimiento del sistema heredado. A continuación, se utilizan como punto de referencia y como referencia para la nueva solución.
Una lista de las funcionalidades críticas del negocio.
Implementación de todos los cambios requeridos (que se han firmado) en la solución en base a los resultados de las pruebas de penetración.
Configuración de herramientas y procesos necesarios para admitir pruebas automatizadas.
Configuración del conjunto de herramientas y los procesos necesarios para admitir la automatización.
Implementación de la arquitectura de contenido, etiquetado de conceptos y reutilización de contenido.
Implementación de los requisitos para admitir el diseño de experiencias.
Aplicación del sistema de reserva y procedimientos conexos.
Implementación de integraciones con todos los sistemas externos requeridos.
Migración junto con la validación del contenido y otros artefactos para la nueva solución.
Implementación de funciones y derechos, usuarios y grupos.
Implementación de todas las medidas de seguridad, incluyendo los AEM incumplimientos.
Implementación de la seguridad de las aplicaciones de software.
Implementación de la seguridad del sistema.
Implementación del concepto de administración de direcciones URL.
Implementación de los flujos de trabajo diseñados.
El concepto de aplicación proporciona los principios rectores para toda la aplicación. Debe tener en cuenta:
Este concepto también puede esbozar los marcos, bibliotecas y otros artefactos que se utilizan en la solución.
Póngase en contacto con el servicio de asistencia técnica de Adobe para asegurarse de que cualquier soporte que se necesite se puede activar durante el lanzamiento.
Conceptos preliminares para el diseño de las experiencias.
Prueba y la confirmación resultante de todas las integraciones, tanto internas como externas.
Esto debe automatizarse y ejecutarse con frecuencia para garantizar la estabilidad del sistema.
Los procesos claros registran todos los problemas encontrados y hacen un seguimiento de las actividades en curso con el fin de garantizar que se aborden todas las cuestiones.
Un sistema de seguimiento, junto con los procesos necesarios, para registrar todos los problemas encontrados y seguir de cerca las actividades en curso con el fin de asegurar que se aborden todos los problemas.
Todas las partes interesadas en el proyecto deben tener acceso para facilitar la transparencia del estado del proyecto.
Algunos ejemplos son JIRA y Centro de calidad HP de Atlassian.
La herramienta seleccionada está totalmente integrada y se concede acceso a todas las funciones necesarias.
Para su proyecto, el sistema heredado es la tecnología, el sistema informático o el programa de aplicaciones existentes que se reemplazarán con la nueva solución.
Los detalles del sistema heredado deben recopilarse para que sepa qué puede retirarse, cuándo y el impacto en cualquier otro sistema.
a) Un esbozo de los instrumentos que se utilizarán en la aplicación; las herramientas deben incluir:
Una lista de todos los usuarios y funciones que necesitarán acceso al Portal de asistencia técnica de Adobe.
La lista suele estar compuesta por el arquitecto de soluciones y/o el personal de TI del cliente.
Una análisis, junto con las recomendaciones resultantes, que define lo que debe registrarse para monitorear la solución:
Probar y habilitar tareas de mantenimiento AEM como:
Documento de la migración; incluir
Una descripción completa del contenido existente, la arquitectura de contenido y los formatos asignados a la nueva solución. Debería abarcar:
También debería recomendar cómo mantener el contenido actualizado (o lo más actualizado posible) durante el período entre la migración y la puesta en marcha efectiva del nuevo sistema. Esto podría significar congelar el contenido, publicar dobles o mantener un sistema alfa.
Monitoreo del uso de la CPU del sistema por parte de la solución:
Monitoreo de las velocidades de entrada y salida del disco de la solución:
Monitoreo del uso del espacio en disco por parte de la solución:
Debe supervisar el uso mediante:
Monitoree las conexiones entre la solución y los sistemas externos:
Monitoree el uso del ancho de banda de la red por parte de la solución:
Monitorear las solicitudes realizadas a la solución.
Monitorear en los puntos de seguridad definidos.
Supervisar el sistema en general; por ejemplo:
Control del umbral definido de la solución junto con la implementación de pasos de intervención para reducir la carga.
Los conceptos de supervisión que se aplicarán a la solución; incorporando:
Deben identificarse y definirse los puntos específicos que podrían ser susceptibles de fracaso. También deben definirse todas las tareas de vigilancia relacionadas con ellas.
Algunos ejemplos son (entre otros):
Asegurarse de que los ingenieros y el personal de operaciones del sistema conozcan y comprendan las políticas de supervisión.
Definir:
Todas las tareas operacionales documentadas, con su frecuencia definida.
Manual que proporciona toda la información necesaria para el correcto funcionamiento y mantenimiento de la solución:
También debe detallar los conceptos de implementación para:
Paquete de software creado y entregado listo para la implementación.
Una prueba de penetración (conocida informalmente como prueba de pluma) es un ataque a un sistema informático que busca debilidades de seguridad, y potencialmente obtiene acceso a las características y datos del equipo.
Se aprueban todos los criterios necesarios.
Informes creados para la empresa que explican los resultados de la prueba de penetración.
Documento conceptual sobre cómo garantizar que la implementación cumpla los KPI de rendimiento y cómo escalar la solución para que siga satisfaciendo esos KPI.
El indicador de rendimiento se utiliza para definir pruebas de rendimiento, pruebas de durabilidad y monitoreo. Para ello, evalúa las características de rendimiento de la solución y del hardware del sistema.
Definen los Indicadores de rendimiento clave (KPI) necesarios para medir el rendimiento del sistema. Algunos ejemplos incluyen el tiempo de carga de la página, el tiempo de respuesta del servidor y el rendimiento de la consulta de la base de datos.
Informes creados para la empresa, que detallan los resultados de las pruebas de rendimiento.
Los resultados deben coincidir con los KPI definidos y con las expectativas de rendimiento.
Las pruebas basadas en personalidades son un método basado en las distintas personalidades descritas en los diseños de experiencia. También prueba las cuentas y sus niveles de permisos relacionados.
Esto se utiliza a menudo en la prueba de aceptación del usuario (UAT).
La Prueba de Concepto (POC) se compara con los requisitos para garantizar que ambos estén alineados.
Una lista de comprobación para definir la serie de comprobaciones y tareas que se deben realizar después de cada implementación.
Una lista de comprobación para definir la serie de comprobaciones y tareas que se deben realizar antes de cada implementación.
Es habitual ejecutar una prueba de línea de base en una instalación estándar de AEM. A continuación, se utiliza como punto de referencia para probar la implementación y el hardware.
Confirme que el entorno de producción está listo, con implementaciones automatizadas implementadas.
Antes de entrar en directo en el entorno de producción, debe concederse Production Sign-off (PSO). Esto es el resultado de una revisión de la versión que se publicará en producción, junto con cualquier problema conocido. La desactivación se proporciona como parte de la programación Go Live.
La política y el proceso necesarios para obtener la firma de producción antes de mover el paquete al entorno de producción.
Defina el plan de comunicación tanto para las partes interesadas del negocio como para el equipo del proyecto.
Las estimaciones iniciales eran de alto nivel y se hacían de acuerdo con los requisitos de alto nivel para la implementación.
Ahora se examinan, perfeccionan y amplían para proporcionar las estimaciones finales. Las estimaciones deben ser proporcionadas por cada jefe de proyecto apropiado, incluida la gestión de proyectos, la consultoría, la arquitectura, los ensayos y el desarrollo.
Estas estimaciones se utilizan para financiar y presupuestar recursos.
Las estimaciones iniciales son de alto nivel y se realizan de conformidad con las elevadas necesidades de ejecución. Esto se examinará y perfeccionará en etapas posteriores.
La documentación necesaria para esbozar la organización y la estructura de sistema de informes del proyecto y el equipo.
A menudo toma la forma, o incluye, un gráfico para presentar una visión general visual de las líneas de tiempo y responsabilidades. Hay muchas herramientas disponibles para ayudarle con esto.
El documento del ámbito del proyecto requiere que identifique y documento una lista de:
Abarca lo que debe lograrse, junto con el trabajo que debe realizarse, para ejecutar el proyecto
Los informes sobre el estado del proyecto se entregan según el calendario acordado y con el formato requerido.
La Prueba de Concepto (POC) implementa una gama limitada de funciones para la solución.
El objetivo debe ser demostrar la viabilidad de la solución, comprobar que puede cumplir el objetivo requerido y demostrar que existe el potencial de su utilización.
AEM mantiene varias versiones de recursos y contenido. Las reglas de depuración están diseñadas y configuradas para eliminar periódicamente las versiones anteriores a fin de mantener el estado y el tamaño del repositorio.
Defina el contenido y el formato requeridos para el informe de calidad, junto con la frecuencia con la que debe entregarse.
El administrador de proyectos coordina todas las funciones necesarias para la versión a producción.
Las notas de la versión forman parte de la documentación de la versión. Las notas de la versión deberían cubrir:
Se utiliza con Runbook para ejecutar pasos y comprobaciones previos y posteriores a la instalación.
Para ver un ejemplo, consulte las Notas de la versión de AEM.
Lanzamiento de la versión final y activo en producción.
Debe destacar las condiciones contractuales específicas que son relevantes para la implementación del proyecto; como hitos contractuales, períodos de factura o requisitos de personal.
Junto con el cliente, defina la frecuencia de los informes que se les envían.
Los datos nunca se sobrescriben en un archivo tar, el uso del disco aumenta incluso cuando solo se actualizan los datos existentes.
Para contrarrestar el tamaño cada vez mayor del repositorio, se ha establecido una estrategia de optimización para eliminar datos obsoletos.
Solicitud oficial para configurar su proyecto en el portal de asistencia técnica de Adobe.
Este conjunto de documentos abarca las necesidades funcionales y no funcionales, junto con las actividades estimadas.
Asegúrese de que todas las funciones necesarias para la puesta en marcha estén dotadas de personal y disponibles.
La evaluación de riesgos es ejecutada por los departamentos de TI y/o seguridad del cliente.
Evalúa los riesgos técnicos y comerciales del proyecto. La evaluación es necesaria para que la solución garantice el cumplimiento de las políticas de seguridad.
El Plan de Mitigación de Riesgos incluye la Evaluación de Riesgos. Juntos cubren:
Defina las expectativas de retorno de la inversión (ROI) que están vinculadas a la solución.
Su objetivo es indicar la eficacia de la solución en términos económicos, definiendo los beneficios/beneficios esperados en relación con la inversión estimada.
Especificación detallada de los conceptos relativos a las funciones y los derechos de acceso necesarios para la nueva aplicación, incluida una descripción general de alto nivel de:
Revisión del concepto de funciones y derechos para garantizar que cumple las políticas de seguridad.
Una especificación detallada basada en el concepto de funciones y derechos.
Recommendations está relacionado con la seguridad para la arquitectura de software y hardware.
Estas directrices definen la forma en que se debe hacer la codificación de desarrollo, basándose en requisitos de seguridad como:
Lista de comprobación específica del proyecto de elementos, basada en el Concepto de seguridad junto con cualquier política adicional necesaria para garantizar el cumplimiento de la solución.
A menudo, esto también se incluye como parte de los pasos posteriores al despliegue en el runbook.
Defina y documento los detalles de la configuración de seguridad necesaria para la aplicación, la arquitectura y la infraestructura.
Un esquema de alto nivel que abarca la configuración de seguridad de:
Todos los problemas de seguridad de la solución enumerados y evaluados; incluyendo estimaciones de esfuerzo.
Firme con los interesados para asegurarse de que la implementación de seguridad cumple con las políticas y expectativas.
Establezca los procesos de soporte requeridos.
Asegurarse de que los Acuerdos de Nivel de Servicio (SLA) estén disponibles y se comuniquen a los equipos de desarrollo y operaciones para su uso durante la implementación y el soporte.
Las pruebas de humo consisten en un conjunto de pasos definidos que prueban las funcionalidades clave de la solución para garantizar las operaciones básicas y la funcionalidad de la solución.
Se ejecutan, en cualquier entorno, después de la instalación o la implementación.
Las pruebas de humo deben ejecutarse en todos los sistemas para garantizar el correcto funcionamiento de la funcionalidad básica de la solución durante la instalación o la implementación en cualquier entorno.
Estrategia de alto nivel para la arquitectura del software; incluyendo servicios, servlets, marcos y otras decisiones de implementación.
La Junta de Revisión de Soluciones suele estar compuesta por partes interesadas del cliente.
La junta celebra reuniones periódicas para examinar de manera permanente los requisitos y las especificaciones pertinentes actualmente establecidos. El objetivo es asegurar la armonización con la definición y los criterios de éxito y también contribuir al desarrollo de los requisitos.
Instrucciones de instalación para la solución, junto con tareas operativas básicas que deben ejecutarse durante la instalación.
El proceso de firma y aceptación describe los criterios que deben cumplirse antes de que la solución pueda liberarse en un entorno productivo.
También puede servir de hito contractual.
El concepto inicial para cualquier funcionalidad especial que se considere fuera del alcance normal de desarrollo en la plataforma AEM.
Detalles de cualquier funcionalidad especial que se considere fuera del ámbito normal de desarrollo en la plataforma AEM.
Cualquier guía del cliente sobre cómo se debe realizar la especificación.
Debe establecerse un proceso claro para la firma de las especificaciones por parte del cliente. Este proceso garantiza la claridad y la firmeza del ámbito de aplicación de los requisitos.
Personal interno que necesitará capacitación para administrar la solución.
Personal interno que necesitará formación para crear la solución.
Las partes interesadas son las personas y/o funciones clave que tienen un interés significativo en el proyecto. Algunos contribuirán al presupuesto del proyecto.
Las partes interesadas pueden ser internas o externas.
Confirmación de que todos los interesados fuera del equipo de implementación real son conscientes de lo siguiente:
Confirmación de que todas las partes interesadas fuera del equipo de implementación real están en consonancia con el proyecto y las expectativas generales, tanto internas del equipo del proyecto como del cliente.
Los informes de estado son un instrumento clave de comunicación. El formato debe estar alineado con los requisitos de sistema de informes del cliente.
El cliente, el patrocinador del proyecto y el director o consultor del proyecto deben especificar:
Se utilizan para garantizar que se cumplen los criterios de éxito:
Parte de las responsabilidades del líder de calidad son garantizar que haya recursos disponibles para apoyar a cualquier usuario durante las pruebas. Por ejemplo, para ayudar al usuario cuando realice pruebas, cuando se produzca un sistema de informes y para ayudar a validar los problemas con el entorno de prueba.
El acceso al portal de asistencia técnica de Adobe es crucial para enviar tickets sobre cualquier problema relacionado con el producto que pueda surgir durante la implementación.
El acceso debe asignarse a los miembros clave del equipo.
Una propuesta inicial y una definición de la estructura para todos los entornos de la solución.
Un documento que detalle la arquitectura del sistema; incluyendo interfaces, ubicación de red e integraciones para todos los entornos, entre otra información.
Esquema de alto nivel sobre cómo hacer que la arquitectura del sistema sea compatible con cualquier política de seguridad. Esto puede abarcar:
Se identifican y evalúan todos los factores de riesgo que se encuentran en la evaluación del riesgo (u otros exámenes):
Confirmación de que todo el equipo es consciente de las definiciones y los criterios de éxito.
Confirmación de que todos los miembros del equipo son conscientes de quién debe comunicarse con el cliente, junto con detalles de cómo y cuándo.
Alineación con el proyecto general y las expectativas, tanto internas del equipo del proyecto como del cliente.
Estos requisitos son específicos de la implementación técnica de los servicios que admiten la solución.
Identificar y verificar los riesgos técnicos potenciales. Los riesgos técnicos pueden incluir:
La especificación técnica abarca (entre otros datos):
Especificaciones de las plantillas requeridas. Estos deberían abarcar detalles como parsys, blueprint y la asignación de herencia, entre otros.
Las especificaciones se basan en los requisitos comerciales y los requisitos de experiencia.
Casos de prueba específicos de los pasos detallados necesarios para ejecutar pruebas funcionales de la solución.
El contenido de la prueba debe estar lo más cerca posible del contenido de producción. Debe tener una selección lo suficientemente amplia como para permitir probar todos los escenarios.
Asegúrese de que el entorno de prueba está listo, con implementaciones automatizadas implementadas para garantizar que todo el código de candidato a la versión esté actualizado para la prueba.
Informes en los que se detallan los resultados de las pruebas; incluyendo:
Cabe señalar que:
Selección del grupo de automatización y la herramienta. Se utilizarán para automatizar las pruebas, incluidas las que se utilizan en casos de uso.
Conjunto de automatización y herramientas seleccionadas para la automatización de casos de uso y otras tareas de ejecución de pruebas.
El concepto de prueba es el esquema de alto nivel de las pruebas para el proyecto; incluidas las pruebas de control de calidad, UAT, rendimiento, seguridad e integración.
Estos planes describen en bueno detalle la ejecución de pruebas para cada fase de desarrollo y se basan en la Estrategia de pruebas.
Estos requisitos son específicos de la implementación técnica de los servicios que admiten la solución.
La estrategia de prueba describe la estrategia de alto nivel para la garantía de calidad y las pruebas de aceptación del usuario. Esto incluye cronogramas, cadencia de sistema de informes y ejecución.
Concepto arquitectónico y de nivel de sistema para la integración con sistemas de terceros.
Detalles de los requisitos (funcionales y no funcionales) para la funcionalidad y la integración admitidas de los sistemas de terceros.
Concepto para garantizar la seguridad de las integraciones de terceros. Debe cumplir con las políticas de seguridad adecuadas.
Asegúrese de que todos los sistemas de terceros estén disponibles, con la documentación adecuada, para la implementación de la integración.
Derechos de acceso requeridos concedidos a las funciones respectivas utilizadas junto con sistemas de terceros.
Define:
Define los valores clave para los puntos de supervisión del sistema.
Por ejemplo:
Esto debería definir los plazos del proyecto y los hitos contractuales que se utilizarán para:
Deberían consolidarse todas las estimaciones de esfuerzo, de cada uno de los posibles clientes del proyecto; incluidos los gastos generales, el desarrollo, la ingeniería de sistemas, la arquitectura y las pruebas.
Si el acuerdo incluye un nivel de apoyo, también se deberían incluir las actividades de apoyo y operaciones.
Materiales que se utilizarán en las sesiones de formación. Los materiales deben ser creados específicamente para la solución y diseñados para ser usados junto con las Guías del Usuario.
La persona adecuada debe confirmar que comprende plenamente:
El concepto de administración de direcciones URL debe abarcar AEM funciones URL específicas, entre las que se incluyen:
El concepto también debería abarcar:
Un caso de uso es la lista de acciones o pasos de evento necesarios para alcanzar un objetivo. Generalmente definen las interacciones entre una función y la solución. La función puede ser un usuario o un sistema externo.
Los escenarios de prueba se basan en los casos de uso técnico y comercial. Se utilizan para comprobar que el comportamiento de la solución es el esperado.
Las guías del usuario proporcionan información y asistencia a los usuarios de la solución:
Todos los interesados deben revisar y validar el plan presupuestario. Necesitan comprobar los detalles, como la facturación, los importes y los métodos/plazos de sistema de informes del presupuesto.
La prueba de cuadro blanco es un método que prueba las estructuras internas o el funcionamiento de una aplicación, a diferencia de su funcionalidad. La prueba de caja blanca se puede aplicar en los niveles de unidad, integración y sistema del proceso de prueba de software.
Según el concepto de Flujos de trabajo, estas especificaciones deben definir en detalle los pasos que permitirán crear el flujo de trabajo completo.
La especificación de cada flujo de trabajo debe incluir (como mínimo):
Los flujos de trabajo le permiten automatizar actividades AEM. El Concepto de Flujos de trabajo describe: