Glosario

Este glosario lista (alfabéticamente) detalles de todos los documentos de entrega de la lista de comprobación del proyecto.

Aceptación de partes interesadas del negocio

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.

Pruebas de aceptación

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:

• Project cumple los requisitos del cliente.
• La solución es apta para el propósito.
• Los usuarios aceptan la solución y pueden pensar en trabajar con ella.
• El cliente acepta el proyecto.

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).

Acceso al sistema de pruebas coordinado

Asegurarse de que los niveles requeridos de acceso al sistema se hayan concedido a todas las funciones.

Lista de comprobación de seguridad de Adobe

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.

Configuración del proyecto del portal de soporte técnico de Adobe

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.

Capacitación del administrador de AEM

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 de autor de AEM

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.

AEM examen de certificación

Asegúrese de que se ha registrado a la persona adecuada para realizar los exámenes de certificación correspondientes.

Certificado por AEM

Asegúrese de que la persona adecuada ha aprobado los exámenes de certificación relevantes.

Capacitación técnica de AEM

Proporcionar formación técnica a la persona adecuada; por ejemplo, desarrolladores, arquitectos, ingenieros y profesionales del negocio.

Acuerdo sobre KPI definidos como objetivos para el proyecto

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.

Alinear KPI de rendimiento y negocios

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.

Alineación de la Arquitectura de contenido con KPI

Asegúrese de que la arquitectura de contenido propuesta esté alineada con los indicadores de rendimiento clave (KPI) relevantes.

Alineación de la hoja de ruta del cliente con la cronología del proyecto

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.

Definición de la Arquitectura de Aplicaciones

La arquitectura de aplicaciones debe definir claramente el comportamiento de las aplicaciones propuestas.

Se centra en:

• Cómo interactuarán entre sí y con los usuarios.
• Los datos que deben ser consumidos y producidos por las aplicaciones, en lugar de su estructura interna.

Tareas de mantenimiento específicas de la aplicación definidas

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.

Personal debidamente capacitado

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

Diagrama de arquitectura

El diagrama de arquitectura es una representación gráfica de la arquitectura. Incluye la representación de:

• los conceptos
• sus principios
• elementos y componentes que forman parte de la arquitectura

Borrador de arquitectura

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.

Inicio de sesión del tablero de revisión de arquitectura

El Consejo de Revisión de la Arquitectura es un órgano interinstitucional que:

• supervisa la aplicación de una estrategia coherente
• garantiza la conformidad en los sistemas

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.

Grupo de pruebas automatizado adaptado para contenido real y resultados en comparación con KPI

Secuencias de comandos de automatización y casos de uso automatizados básicos:

• adaptado al contenido de producción
• comprobados con los KPI

Estrategia de prueba automatizada

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:

• un mayor retorno de la inversión (ROI)
• más cobertura de pruebas
• mayor fiabilidad de la prueba con repetición de calidad

Estrategia de prueba automatizada validada frente a carga realista y esperada

La estrategia de prueba automatizada debe validarse y ajustarse según el contenido y la carga esperada que habrá en la solución.

Estrategia de automatizació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:

• frecuencia
• herramientas que se utilizarán
• entornos que se implementarán en

Consciente del plan de comunicación

Todo el equipo del proyecto y todas las partes interesadas deben confirmar que conocen:

• Estructura del sistema de informes
• cadencia de sistema de informes
• canales de comunicación

Consciente de los criterios y definiciones de éxito

Todo el equipo del proyecto y todas las partes interesadas deben confirmar que conocen:

• definiciones de éxito
• criterios para el éxito

Concepto de backup y restore

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 de backup y restore

Prueba completa end-to-end basada en el concepto de backup y restore.

Casos comerciales

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 Comprende el alcance del proyecto y las expectativas

Business Analyst debe confirmar que comprende perfectamente:

• ámbito del proyecto
• todas las expectativas de los clientes
• que esta es la base de todas las decisiones tomadas por persona, por fase en el proyecto

KPI comerciales

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á.

Documentación de requerimientos del negocio

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?"

Inicio de sesión de negocios en cualquier ajuste necesario de la solución o arquitectura identificado y alineado con las expectativas de ROI y KPI

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.

Estrategia de almacenamiento en caché

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.

Directrices de codificació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:

• convenciones de nomenclatura
• uso del servicio
• uso de biblioteca

Manual de operaciones de comunicación

Asegúrese de que todas las funciones y personas pertinentes han recibido el Manual de operaciones.

Comunicar informe de prueba de rendimiento

Asegúrese de que todas las funciones y personas pertinentes han recibido el informe Prueba de rendimiento.

Comunicar notas de revisión

Asegúrese de que todas las funciones y personas pertinentes han recibido las Notas de la versión.

Comunicar el ámbito y las expectativas al equipo

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.

Comunicar el material de capacitación y las guías del usuario

Asegúrese de que todas las funciones y personas pertinentes reciben el material de formación y las guías del usuario.

Cumplimiento de los Requerimientos de Seguridad del Cliente

Asegúrese de que todos los requisitos de seguridad del cliente están implementados.

Cumplimiento del concepto de seguridad

Asegúrese de que el Concepto de seguridad esté establecido.

Concepto de relación de componentes y plantillas

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.

Especificación de relación de componentes y plantillas

Detalles del concepto de relación de componentes y plantillas.

Especificación de componentes

Detalles de especificación para cada uno de los componentes que se implementarán.

Concepto de mboxes de interfaces externas

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.

Documento de la Arquitectura de Contenido

Documentación de la arquitectura propuesta del contenido. Los detalles deberían incluir, entre otros:

• árbol de contenido
• etiquetado de conceptos
• estrategias para la reutilización del contenido

Contenido validado para la migración

El contenido heredado del sistema se revisa y el contenido seleccionado se valida para la migración a la nueva solución.

Borrador de contrato

Proyecto inicial del contrato jurídico.

Formato y estructura de contenido actuales

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ítica de Backup y Restore del Cliente

Políticas del cliente relativas a:

• procesos de backup tanto para los datos como para la solución
• almacenamiento del backup
• confirmación de que la copia de seguridad está funcionando según lo esperado
• restauración, en caso de fallo

Directrices para la codificación del cliente

Cualquier guía o requisito del cliente sobre cómo se debe realizar el desarrollo.

Directivas de implementación/versión del cliente

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.

Requisitos o directivas de monitoreo del cliente

Políticas y requisitos del cliente sobre lo que debe monitorearse. Éstas se suman a las recomendaciones especificadas en el Concepto de supervisión.

Programación de versiones de producción de clientes

Programa definido por el cliente para las versiones de los entornos de producción.

Requisitos y políticas de Sistema de informes del cliente

Cualquier política o requisito que el cliente tenga en relación con el sistema de informes. Pueden incluir:

• la frecuencia con la que deben entregarse los informes específicos
• el formato para informes específicos
• requisitos especiales

Hoja de ruta del cliente

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.

Directivas de seguridad del cliente

El cliente (comercial y de TI) tendrá políticas que definen los niveles de seguridad requeridos para la solución. Pueden incluir:

• Requisitos para aprobar una evaluación del riesgo.
• Requisitos para superar las pruebas de penetración.
• Cualquier requisito de seguridad específico; como el escape de todos los campos de entrada, el uso de cifrado (SSL), los certificados y la autenticación y la sesión.

Directrices de especificación del cliente

Cualquier guía que el cliente tenga en relación con el formato, el envío y la firma de las especificaciones.

Informes de prueba del cliente

Informes del cliente al posible cliente durante el período de prueba de aceptación del usuario (UAT).

Personalizaciones y revisiones que afectan a las actualizaciones documentadas

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:

  • paquetes de correcciones acumulativas (CFP)
  • Service Packs (SP)
  • revisiones
  • actualizaciones

Informe de prueba de aceptación diaria del usuario

Informes o reuniones resultantes de la prueba de aceptación del usuario (UAT). Deberían detallar:

• los problemas notificados
• priorización de estas cuestiones

Seguridad predeterminada habilitada

Asegúrese de que la configuración de seguridad predeterminada para AEM se haya habilitado o implementado.

Políticas y procesos de implementación/lanzamiento

Directivas formalizadas que cubren tanto la implementación como las versiones del proyecto. Pueden incluir:

• tiempo para versiones
• planificación de vacaciones
• frecuencia
• y puede depender del entorno en cuestión

Se ha establecido la cadencia de implementación

Defina la frecuencia necesaria de las implementaciones entre entornos.

Metodología de desarrollo

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.

Definición de la función de desarrollo

Defina qué desarrollador y/o función ejecuta pruebas de TI (rendimiento u otros) y/o unidades dentro de la solución.

Entorno de desarrollo listo

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 comprende el alcance del proyecto y las expectativas

El Equipo de Desarrollo debería confirmar que comprende plenamente:

• ámbito del proyecto
• todas las expectativas de los clientes
• que esta es la base de todas las decisiones tomadas por persona, por fase en el proyecto

Especificación de diálogos

Detalles sobre los diálogos necesarios para la solución.

Configuración del Entorno de desarrollo de documento

Documentación del entorno de desarrollo.

Configuración de documento Production Entorno

Documentación del entorno de producción.

Configuración del Entorno de prueba de documento

Documentación del entorno de ensayo.

Prueba de durabilidad

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.

Prueba de durabilidad ejecutada

Ejecución de las pruebas de durabilidad.

Concepto de administración de errores

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.

Administración de errores de la documentación

Documentación detallada de la gestión de errores propuesta, basada en el concepto de gestión de errores.

Procesos de escalación

Definición de todos los procesos de escalación. Habrá procesos separados para cada nivel de proyecto:

• Equipo del proyecto
• Cliente
• Adobe

Establecer sesiones regulares de revisión de la calidad

Establecer reuniones periódicas de examen de calidad con los miembros del equipo correspondientes.

Estructura de permisos existente

Documentación del conjunto existente de permisos y grupos definidos para la solución heredada o dentro de la organización.

Mapa de sistemas existente

Un diagrama (o conjunto de diagramas) de los sistemas y dependencias existentes.

Definiciones y criterios de éxito esperados

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:

• KPI específicos, como el aumento de porcentaje en las páginas servidas
• menor tiempo para publicar contenido
• objetivos de nivel superior, como una interfaz fácil de usar

Requisitos de diseños de experiencia

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.

Especificaciones de la experiencia

Detalles de los requisitos de diseño de experiencia.

Dependencias del sistema externo y del usuario/Contexto del sistema

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.

Sistema y procedimiento de reserva

Definición del sistema de reserva:

• las funcionalidades críticas para el negocio que deben seguir funcionando en caso de una falla crítica
• los procesos necesarios en caso de reserva

Sistema de reserva y procedimiento probados

Prueba completa del sistema de reserva.

Cierre de sesión del sistema de reserva de los accionistas del negocio

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.

Confirmación de viabilidad en KPI

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.

Contrato finalizado

Antes de continuar con el proyecto se necesita un contrato firmado y finalizado. Esto se basa en el Borrador del contrato.

Funcionalidad de la solución aceptada por las partes interesadas

Confirmación de que los interesados aceptan plenamente:

• funcionalidad de la solución
• cualquier problema conocido en la solución

Programación en directo

Cronología y programación de las actividades necesarias para:

• preparación para la puesta en marcha
• el lanzamiento real

Rutas felices definidas

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 de hardware

Estimaciones iniciales de:

• el hardware necesario para la instalación AEM básica
• cualquier requerimiento adicional, según el diseño de la solución de alto nivel

El hardware estará disponible para cumplir los requisitos

Confirmación de que todos los entornos tendrán el hardware mínimo requerido.

Requisitos de alto nivel

La definición de los requisitos de alto nivel ofrece un desglose generalizado de los requisitos del sistema, que abarca aspectos como:

• Procesos empresariales
• Principales funciones del sistema

Normalmente se conocen los detalles básicos sobre estas funciones, por lo que este documento no debe ser una estimación.

Diseño de soluciones de alto nivel

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.

Mapa del sistema de alto nivel

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.

Estructura de contenido histórico

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.

KPI históricos de rendimiento y rendimiento histórico

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.

Identifique las funcionalidades/soluciones clave críticas

Una lista de las funcionalidades críticas del negocio.

Implementación: Cambios basados en los resultados de la prueba de penetración

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.

Implementación: Estrategia de prueba automatizada

Configuración de herramientas y procesos necesarios para admitir pruebas automatizadas.

Implementación: estrategia de automatización

Configuración del conjunto de herramientas y los procesos necesarios para admitir la automatización.

Implementación: Arquitectura de contenido

Implementación de la arquitectura de contenido, etiquetado de conceptos y reutilización de contenido.

Implementación: diseño de experiencia

Implementación de los requisitos para admitir el diseño de experiencias.

Implementación: sistema y procedimientos de reserva

Aplicación del sistema de reserva y procedimientos conexos.

Implementación: integración

Implementación de integraciones con todos los sistemas externos requeridos.

Implementación - Estrategia de migración

Migración junto con la validación del contenido y otros artefactos para la nueva solución.

Implementación: funciones y derechos

Implementación de funciones y derechos, usuarios y grupos.

Implementación: concepto de seguridad

Implementación de todas las medidas de seguridad, incluyendo los AEM incumplimientos.

Implementación: Software de seguridad

Implementación de la seguridad de las aplicaciones de software.

Implementación: Concepto de seguridad de la arquitectura del sistema

Implementación de la seguridad del sistema.

Implementación: administración de direcciones URL

Implementación del concepto de administración de direcciones URL.

Implementación: Flujos de trabajo

Implementación de los flujos de trabajo diseñados.

Concepto de implementación

El concepto de aplicación proporciona los principios rectores para toda la aplicación. Debe tener en cuenta:

• Operaciones
• Mantenimiento
• Responsabilidad
• Reutilización
• Seguridad
• Escalabilidad

Este concepto también puede esbozar los marcos, bibliotecas y otros artefactos que se utilizan en la solución.

Informar a la asistencia técnica de Adobe sobre la programación de lanzamiento

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.

Diseños de experiencias iniciales

Conceptos preliminares para el diseño de las experiencias.

Prueba de integración

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.

Proceso de seguimiento de problemas

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.

Sistema y procesos de seguimiento de problemas

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.

El proceso del sistema de seguimiento de problemas está configurado e integrado

La herramienta seleccionada está totalmente integrada y se concede acceso a todas las funciones necesarias.

Sistema heredado

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.

Lista de las herramientas de desarrollo que se utilizarán

a) Un esbozo de los instrumentos que se utilizarán en la aplicación; las herramientas deben incluir:

• herramientas de documentación
• herramientas de seguimiento de problemas
• herramientas de implementación
• crear herramientas

Lista de usuarios que requieren acceso al portal de soporte de Adobe

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.

Análisis del archivo de registro

Una análisis, junto con las recomendaciones resultantes, que define lo que debe registrarse para monitorear la solución:

• actividades que se van a registrar
• nivel de granularidad
• información registrada para cada actividad

Tareas de mantenimiento (AEM específicas) probadas y habilitadas

Probar y habilitar tareas de mantenimiento AEM como:

• compactación
• limpieza del sistema
• depuración de flujo de trabajo

Plan de migración

Documento de la migración; incluir

• línea de tiempo para la migración
• plan de mantenimiento de contenido, según la estrategia de migración

Estrategia de migración

Una descripción completa del contenido existente, la arquitectura de contenido y los formatos asignados a la nueva solución. Debería abarcar:

• detalles técnicos de la migración automatizada si es posible
• pruebas de humo que se deben realizar después de la migración para validar el contenido migrado

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: CPU

Monitoreo del uso de la CPU del sistema por parte de la solución:

• media
• picos

Monitoreo: E/S de disco

Monitoreo de las velocidades de entrada y salida del disco de la solución:

• media
• picos

Monitoreo - Espacio en disco

Monitoreo del uso del espacio en disco por parte de la solución:

• media
• crecimiento con el tiempo

Debe supervisar el uso mediante:

• el repositorio
• archivos de registro

Monitoreo - Sistema(s) externo(s)

Monitoree las conexiones entre la solución y los sistemas externos:

• tasa de tráfico
• picos
• estabilidad

Monitoreo: Ancho de banda de red

Monitoree el uso del ancho de banda de la red por parte de la solución:

• tasa media de tráfico
• picos
• estabilidad

Monitoreo - Solicitudes

Monitorear las solicitudes realizadas a la solución.

Monitoreo - Puntos de seguridad

Monitorear en los puntos de seguridad definidos.

Monitoreo - Sistema

Supervisar el sistema en general; por ejemplo:

• disponibilidad
• rendimiento promedio
• picos de rendimiento
• alertas

Monitoreo: Umbral e Intervención

Control del umbral definido de la solución junto con la implementación de pasos de intervención para reducir la carga.

Concepto de monitoreo

Los conceptos de supervisión que se aplicarán a la solución; incorporando:

• AEM supervisión estándar
• supervisión del sistema
• requisitos de supervisión específicos del cliente

Monitoreo de los puntos débiles potenciales

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):

• flujos de trabajo clave
• procesamiento de transacciones
• puntos de integración

Política de monitoreo comunicada al ingeniero de sistemas

Asegurarse de que los ingenieros y el personal de operaciones del sistema conozcan y comprendan las políticas de supervisión.

Informes de monitoreo: estructura

Definir:

• cuándo deben generarse los informes de supervisión
• a quién deben entregarse

Documentación de Tareas operacionales

Todas las tareas operacionales documentadas, con su frecuencia definida.

Manual de operaciones

Manual que proporciona toda la información necesaria para el correcto funcionamiento y mantenimiento de la solución:

• todas las tareas operativas
• contactos clave
• planes de implementación
• listas de comprobación previas o posteriores a la implementación
• cualquier otra tarea crítica

También debe detallar los conceptos de implementación para:

• cumplimiento de los KPI de rendimiento
• escalar la solución para seguir satisfaciendo esos KPI

Paquete preparado

Paquete de software creado y entregado listo para la implementación.

Pruebas de penetració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.

Pruebas de penetración - Pasadas

Se aprueban todos los criterios necesarios.

Pruebas de penetración - Resultados

Informes creados para la empresa que explican los resultados de la prueba de penetración.

Concepto de performance y escalabilidad

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.

Prueba comparativa de rendimiento

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.

KPI de rendimiento

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.

Pruebas de rendimiento: informe

Informes creados para la empresa, que detallan los resultados de las pruebas de rendimiento.

Pruebas de rendimiento: KPI de rendimiento de coincidencia de resultados

Los resultados deben coincidir con los KPI definidos y con las expectativas de rendimiento.

Concepto de prueba basada en personal

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).

Documentación de requisitos probada y verificada para POC

La Prueba de Concepto (POC) se compara con los requisitos para garantizar que ambos estén alineados.

Lista de comprobación posterior a la implementación

Una lista de comprobación para definir la serie de comprobaciones y tareas que se deben realizar después de cada implementación.

Lista de comprobación previa a la implementación

Una lista de comprobación para definir la serie de comprobaciones y tareas que se deben realizar antes de cada implementación.

Pruebas de rendimiento de línea de base de Entorno de producció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.

Entorno de producción listo

Confirme que el entorno de producción está listo, con implementaciones automatizadas implementadas.

Cierre de sesión de producción de los accionistas del negocio

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.

Proceso y directiva de cierre de sesión de producción

La política y el proceso necesarios para obtener la firma de producción antes de mover el paquete al entorno de producción.

Plan de comunicación del proyecto

Defina el plan de comunicación tanto para las partes interesadas del negocio como para el equipo del proyecto.

Esfuerzos del proyecto - Estimaciones finales

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.

Esfuerzos del proyecto - Estimaciones iniciales

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.

Organización del proyecto

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.

Documento del ámbito del proyecto

El documento del ámbito del proyecto requiere que identifique y documento una lista de:

• Objetivos específicos del proyecto
• Elementos que entregar
• Características
• Funciones
• Tareas
• Plazos
• Esfuerzo planificado

Abarca lo que debe lograrse, junto con el trabajo que debe realizarse, para ejecutar el proyecto

Informes de estado del proyecto dentro de una secuencia definida

Los informes sobre el estado del proyecto se entregan según el calendario acordado y con el formato requerido.

Prueba del concepto (POC)

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.

Purgar reglas

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.

Formato y jerarquía del informe de calidad

Defina el contenido y el formato requeridos para el informe de calidad, junto con la frecuencia con la que debe entregarse.

Liberar coordinado

El administrador de proyectos coordina todas las funciones necesarias para la versión a producción.

Notas de la versió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:

• requisitos previos
• requisitos incluidos
• problemas resueltos
• problemas conocidos de la versión

Se utiliza con Runbook para ejecutar pasos y comprobaciones previos y posteriores a la instalación.

Lanzamiento en ejecución en el Entorno de producción

Lanzamiento de la versión final y activo en producción.

Condiciones del contrato relevantes

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.

Sistema de informes Cadence

Junto con el cliente, defina la frecuencia de los informes que se les envían.

Optimización del repositorio

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 de configuración de la sección Proyecto en el portal de soporte de Adobe

Solicitud oficial para configurar su proyecto en el portal de asistencia técnica de Adobe.

Documentación de requisitos

Este conjunto de documentos abarca las necesidades funcionales y no funcionales, junto con las actividades estimadas.

Recursos disponibles para admitir Go Live

Asegúrese de que todas las funciones necesarias para la puesta en marcha estén dotadas de personal y disponibles.

Evaluación de riesgos

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.

Plan de Mitigación de Riesgos

El Plan de Mitigación de Riesgos incluye la Evaluación de Riesgos. Juntos cubren:

• riesgos identificados
• posibles soluciones a esos riesgos en caso de que surjan en la aplicación

Expectativas de ROI

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.

Concepto de funciones y derechos

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:

• roles
• grupos
• usuarios
• permissions
• así como la administración y el aprovisionamiento de usuarios

El concepto de roles y derechos cumple las directrices de seguridad

Revisión del concepto de funciones y derechos para garantizar que cumple las políticas de seguridad.

Especificación de funciones y derechos

Una especificación detallada basada en el concepto de funciones y derechos.

Arquitectura de seguridad Recommendations

Recommendations está relacionado con la seguridad para la arquitectura de software y hardware.

Pautas de codificación basadas en la seguridad

Estas directrices definen la forma en que se debe hacer la codificación de desarrollo, basándose en requisitos de seguridad como:

• convenciones de nomenclatura
• bibliotecas
• directrices para marcos
• Uso de API

Lista de comprobación de seguridad

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.

Concepto de seguridad

Defina y documento los detalles de la configuración de seguridad necesaria para la aplicación, la arquitectura y la infraestructura.

Borrador de concepto de seguridad

Un esquema de alto nivel que abarca la configuración de seguridad de:

• aplicación
• arquitectura
• infraestructura

Problemas de seguridad enumerados y evaluados

Todos los problemas de seguridad de la solución enumerados y evaluados; incluyendo estimaciones de esfuerzo.

Cierre de sesión de seguridad de los agentes del negocio

Firme con los interesados para asegurarse de que la implementación de seguridad cumple con las políticas y expectativas.

Configure los procesos de soporte

Establezca los procesos de soporte requeridos.

SLA para sistemas de terceros

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.

Concepto de prueba de humo

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.

Se ejecutaron pruebas de humo para la validación del sistema

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 arquitectura de software

Estrategia de alto nivel para la arquitectura del software; incluyendo servicios, servlets, marcos y otras decisiones de implementación.

Establecimiento de la Junta de Revisión de la Solución y Conjunto de Cadenas de Reunió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.

Runbook de solución

Instrucciones de instalación para la solución, junto con tareas operativas básicas que deben ejecutarse durante la instalación.

Proceso de aceptación y desactivación de la solució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.

Concepto de funcionalidad especial

El concepto inicial para cualquier funcionalidad especial que se considere fuera del alcance normal de desarrollo en la plataforma AEM.

Especificación de funcionalidad especial

Detalles de cualquier funcionalidad especial que se considere fuera del ámbito normal de desarrollo en la plataforma AEM.

Directrices de especificación

Cualquier guía del cliente sobre cómo se debe realizar la especificación.

Proceso de Revisión y Aprobación de Especificaciones Definido y Comunicado

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 seleccionado para AEM capacitación del administrador

Personal interno que necesitará capacitación para administrar la solución.

Personal seleccionado para la capacitación de autores y usuarios finales

Personal interno que necesitará formación para crear la solución.

Partes interesadas

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.

Los interesados son conscientes de las definiciones y criterios de éxito

Confirmación de que todos los interesados fuera del equipo de implementación real son conscientes de lo siguiente:

• definiciones de éxito
• criterios para el éxito

Los interesados comprenden el proyecto y las expectativas

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.

Definición de formato de informe de estado

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.

Criterios de éxito y definición

El cliente, el patrocinador del proyecto y el director o consultor del proyecto deben especificar:

• Qué define un resultado exitoso para el proyecto.
• Los criterios específicos necesarios para cumplir esa definición de éxito.

Se utilizan para garantizar que se cumplen los criterios de éxito:

• Como base para los KPI.
• Al tomar decisiones durante toda la implementación.

Compatibilidad con la validación de problemas notificados

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.

Procesos de soporte y acceso al portal de soporte de Adobe

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.

Definición de la arquitectura del sistema

Una propuesta inicial y una definición de la estructura para todos los entornos de la solución.

Documentación de la arquitectura del sistema

Un documento que detalle la arquitectura del sistema; incluyendo interfaces, ubicación de red e integraciones para todos los entornos, entre otra información.

Concepto de seguridad de la arquitectura del sistema

Esquema de alto nivel sobre cómo hacer que la arquitectura del sistema sea compatible con cualquier política de seguridad. Esto puede abarcar:

• cortafuegos y reglas de cortafuegos
• zonas de seguridad
• administradores de tráfico locales y generales
• servidores Web
• proxies y proxies inversos

Factores de riesgo del sistema identificados y verificados

Se identifican y evalúan todos los factores de riesgo que se encuentran en la evaluación del riesgo (u otros exámenes):

• el nivel de riesgo implícito en cada uno de ellos
• junto con el esfuerzo estimado para hacer frente a cualquier cambio en la aplicación.

El equipo es consciente de los criterios y definiciones de éxito

Confirmación de que todo el equipo es consciente de las definiciones y los criterios de éxito.

El equipo conoce el plan de comunicación

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.

El equipo comprende el proyecto y las expectativas

Alineación con el proyecto general y las expectativas, tanto internas del equipo del proyecto como del cliente.

Requisitos técnicos

Estos requisitos son específicos de la implementación técnica de los servicios que admiten la solución.

Factores de riesgo técnico verificados

Identificar y verificar los riesgos técnicos potenciales. Los riesgos técnicos pueden incluir:

• cross-site scripting
• campo de entrada de cara al usuario final
• infraestructura
• edad de la tecnología
• número de integraciones
• y dependencias

Especificación técnica

La especificación técnica abarca (entre otros datos):

• interfaces
• configuraciones
• API
• servicios que admiten los requisitos de la solución

Especificación de plantilla

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

Casos de prueba específicos de los pasos detallados necesarios para ejecutar pruebas funcionales de la solución.

Probar contenido

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.

Test Entorno Ready

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 de prueba

Informes en los que se detallan los resultados de las pruebas; incluyendo:

• defectos elevados
• estado de los casos de prueba ejecutados
• otros temas relacionados con la calidad

Cabe señalar que:

• Se debe permitir que cualquier equipo de prueba permanezca neutral y proporcione los resultados de la prueba.
• El director del proyecto tiene la responsabilidad de evaluar las consecuencias de los resultados y decidir las medidas apropiadas.

Test Suite

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.

Grupo de herramientas de prueba seleccionado

Conjunto de automatización y herramientas seleccionadas para la automatización de casos de uso y otras tareas de ejecución de pruebas.

Concepto de prueba

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.

Planes de prueba

Estos planes describen en bueno detalle la ejecución de pruebas para cada fase de desarrollo y se basan en la Estrategia de pruebas.

Alcance de la prueba

Estos requisitos son específicos de la implementación técnica de los servicios que admiten la solución.

Estrategia de prueba

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 de integración de terceros

Concepto arquitectónico y de nivel de sistema para la integración con sistemas de terceros.

Especificación de integración de terceros

Detalles de los requisitos (funcionales y no funcionales) para la funcionalidad y la integración admitidas de los sistemas de terceros.

Concepto de seguridad de terceros

Concepto para garantizar la seguridad de las integraciones de terceros. Debe cumplir con las políticas de seguridad adecuadas.

Sistema de terceros para la integración

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.

Acceso a sistemas de terceros habilitado

Derechos de acceso requeridos concedidos a las funciones respectivas utilizadas junto con sistemas de terceros.

Concepto de prueba de terceros

Define:

• casos de uso para probar las integraciones
• funcionalidad relacionada con cualquier aplicación de terceros

Definición de umbral

Define los valores clave para los puntos de supervisión del sistema.

Por ejemplo:

• cuántos kilobytes (KB) de registros no enviados generan una advertencia en la instancia del servidor principal
• el número de milisegundos de retraso promedio por transacción que se toleran antes de que se genere una advertencia en el servidor principal

Línea de tiempo e hitos

Esto debería definir los plazos del proyecto y los hitos contractuales que se utilizarán para:

• Facturación.
• Alineación con las definiciones de éxito, los criterios de éxito y los KPI.

Esfuerzos totales del proyecto

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 de capacitación

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.

Comprende el alcance del proyecto y las expectativas

La persona adecuada debe confirmar que comprende plenamente:

• ámbito del proyecto
• todas las expectativas de los clientes
• que esta es la base de todas las decisiones tomadas por persona, por fase en el proyecto

Concepto de administración de direcciones URL

El concepto de administración de direcciones URL debe abarcar AEM funciones URL específicas, entre las que se incluyen:

• URL de vanidad
• externalizar vínculo
• páginas de error
• asignación

El concepto también debería abarcar:

• cualquier regla de reescritura
• hosts virtuales en el servidor web
• Consideraciones de SEO, como robots.txt
• un mapa del sitio

Casos de uso

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.

Casos de uso convertidos en escenarios de prueba

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.

Guías del usuario

Las guías del usuario proporcionan información y asistencia a los usuarios de la solución:

• autores
• usuarios avanzados
• administradores

Plan presupuestario validado

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.

Resultados de la prueba de cuadro blanco

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.

Especificaciones del flujo de trabajo

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):

• caso de uso
• roles
• pasos
• resultados
• gestión de errores

Concepto de flujos de trabajo

Los flujos de trabajo le permiten automatizar actividades AEM. El Concepto de Flujos de trabajo describe:

• los procesos que necesitarán automatización
• los servicios y funciones de AEM que se verán afectados