Glosario

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

Aceptación de partes interesadas empresariales

La aceptación por parte de las partes interesadas empresariales confirma que, como partes interesadas clave, están alineadas con la solución y han dado su aprobación sobre cómo los requisitos empresariales cumplen con el caso empresarial.

Pruebas de aceptación

Las pruebas de aceptación se realizan 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 reales.

Las pruebas de aceptación se utilizan para confirmar que:

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

Cuanto antes planifique y diseñe sus pruebas de aceptación, más fácil será la implementación final. Deben definirse junto con el cliente y su equipo de control de calidad.

Aunque es posible que no pueda definir todos los detalles al principio del proyecto, las definiciones iniciales deben discutirse y acordarse. Las pruebas de aceptación probablemente se basarán en los requisitos fundamentales (funcional y de rendimiento).

Acceso coordinado al sistema de pruebas

Asegúrese de que se han concedido los niveles requeridos de acceso al sistema a todas las funciones.

Lista de comprobación de seguridad de Adobe

El Lista de comprobación de seguridad de Adobe es la lista de comprobación oficial que se proporciona para garantizar que Adobe Experience Manager AEM () sea seguro durante la instalación. Contiene las medidas de seguridad y verificación que debe realizar para garantizar la integridad de la instancia.

Configuración del proyecto del portal de soporte de Adobe

El Portal de soporte de Adobe AEM permite a los socios y clientes de implementación configurar la implementación de la implementación de la como un proyecto en el Portal de soporte.

Se pueden registrar detalles; por ejemplo, sobre las tecnologías y versiones implementadas. Proporcionan transparencia entre el cliente y el Adobe.

AEM Formación de administrador de

Formación del personal administrativo de la solución. Consulte la Servicios de formación de Adobe para obtener más información.

AEM Formación de autor de

Formación del personal que producirá (creará) el contenido de la solución. Consulte la Servicios de formación de Adobe para obtener más información.

AEM Examen de certificación de

Asegúrese de que las personas adecuadas estén registradas para tomar las exámenes de certificación.

AEM Certificación de

Asegúrese de que la persona adecuada haya pasado el valor correspondiente exámenes de certificación.

AEM Formación técnica de

Proporcionar formación técnica al usuario adecuado; por ejemplo, desarrolladores, arquitectos, ingenieros y profesionales del negocio.

Acuerdo sobre los KPI definidos como objetivos para el proyecto

Los indicadores clave de rendimiento (KPI) ayudan a una organización a definir y medir el progreso hacia los objetivos de la organización. Una vez que una organización ha analizado su misión y definido sus objetivos, debe medir el progreso hacia esos objetivos. Los KPI proporcionan un mecanismo para la medición.

Alinear KPI empresariales y de rendimiento

La alineación de los indicadores clave de rendimiento (KPI) y del negocio 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 lograr los objetivos empresariales y cumplir el propósito propuesto.

Alineación de la arquitectura de contenido con los KPI

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

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

La hoja de ruta del cliente consta de hitos de alto nivel y objetivos empresariales. La cronología del proyecto debe adherirse a esta estrategia y alinearse con ella, de modo que se deben destacar y rastrear todos los riesgos potenciales y/o posibles desviaciones.

Definición de arquitectura de aplicación

El arquitectura de aplicación debería definir claramente el comportamiento de las aplicaciones propuestas.

Se centra en:

• Cómo interactúan entre sí y con los usuarios.
• Los datos que deben consumir y producir 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 Formado

Asegúrese de que su equipo esté formado por personal con la formación adecuada. Para los equipos de proyecto, la recomendación es tener lo siguiente:

• AEM al menos un desarrollador principal certificado por el administrador de la
• AEM al menos un arquitecto certificado por el equipo de
• AEM al menos el 75% de sus desarrolladores certificados; esto permite que los desarrolladores certificados asesoren a 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 de la solución. En esta etapa se trata de un proyecto que se revisará y perfeccionará en etapas posteriores.

Firma del panel de revisión de arquitectura

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

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

El comité de revisión debe ser representativo de todas las partes interesadas clave relacionadas con la arquitectura. Normalmente están compuestos por un grupo de ejecutivos responsables de la revisión y el mantenimiento de la arquitectura general.

Grupo de pruebas automatizadas adaptado para contenido real y resultados comparado con KPI

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

• adaptado para el contenido de producción
• comparado con los KPI

Estrategia de pruebas automatizadas

Esta estrategia define un marco para scripts automatizados reutilizables, junto con el enfoque planificado por el equipo de control de calidad. Describe el plan general para las pruebas de automatización a fin de garantizar lo siguiente:

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

Estrategia de prueba automatizada validada con una carga realista y esperada

La estrategia de pruebas automatizadas debe validarse y ajustarse según el contenido y la carga esperada que haya 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, incluidos los siguientes:

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

Conocimiento del plan de comunicación

Todo el equipo del proyecto y todas las partes interesadas deben confirmar que son conscientes de lo siguiente:

• estructura informes
• cadencia de los informes
• canales de comunicación

Conocimiento de las definiciones y criterios de éxito

Todo el equipo del proyecto y todas las partes interesadas deben confirmar que son conscientes de lo siguiente:

• definiciones de éxito
• criterios de éxito

Concepto de copia de seguridad y restauración

El concepto de copia de seguridad y restauración describe la funcionalidad técnica que se implementará en la solución. La directiva de copia de seguridad y restauración de la compañía lo requiere.

Copia de seguridad y restauración probadas

Una prueba completa de extremo a extremo basada en el concepto de backup y restauración.

Casos comerciales

Un documento de caso empresarial presenta los argumentos relacionados con la realización de la acción, la realización de una acción alternativa (si está disponible) o la no realización de ninguna acción. Los argumentos deben ser equilibrados, basados en hechos concretos (siempre que sea posible/pertinente) y poner de relieve tanto los beneficios como los riesgos para todos los casos.

Un documento comercial debe ser una definición clara de todas las opciones, concluyendo con un argumento convincente para la implementación de la solución propuesta.

Analista empresarial entiende el alcance del proyecto y las expectativas

El analista empresarial debe confirmar que comprende perfectamente lo siguiente:

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

KPI empresariales

Las organizaciones utilizan indicadores de rendimiento clave (KPI) para evaluar su éxito a la hora de alcanzar los objetivos.

Los KPI empresariales definen valores mensurables que demuestran la eficacia con la que una empresa logra objetivos comerciales clave. Es importante elegir los KPI adecuados para su negocio/escenario con definiciones claras de cuáles son, cómo se miden, cómo se utilizan y quién los utiliza.

Documentación de requisitos empresariales

Un documento de requisitos empresariales (BRD, por sus siglas en inglés) detalla la solución empresarial para un proyecto, proporcionando una especificación clara 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 empresarial, el BERD debe responder a la pregunta: "¿Qué quiere hacer la empresa?"

Aprobación empresarial de cualquier ajuste necesario en la solución o arquitectura identificada y alineada con las expectativas de ROI y KPI

Los procesos de evaluación de riesgos y pruebas 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 medido con respecto a 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 ser compatible con los KPI de rendimiento.

Por ejemplo, se pueden almacenar en caché elementos como imágenes, JavaScript y otros archivos de servidor para mejorar el rendimiento de una solución.

Directrices de codificación

Las Directrices de codificación definen los principios básicos que los desarrolladores deben cumplir al desarrollar la solución. Estos pueden incluir, entre otros:

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

Comunicar manual de operaciones

Asegúrese de que todas las personas o funciones adecuadas hayan recibido el Manual de operaciones.

Comunicar informe de prueba de rendimiento

Asegúrese de que todas las personas o funciones adecuadas hayan recibido el informe de prueba de rendimiento.

Comunicar notas de la versión

Asegúrese de que todas las personas o funciones adecuadas hayan recibido las notas de la versión.

Comunicar el ámbito y las expectativas al equipo

Asegúrese de que el equipo del proyecto conozca y se ajuste completamente al ámbito del proyecto y a las expectativas de entrega.

Comunicar materiales de formación y guías del usuario

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

Cumplimiento de los requisitos de seguridad del cliente

Asegúrese de que se cumplen todos los requisitos de seguridad del cliente.

Cumplimiento del concepto de seguridad

Asegúrese de que el concepto de seguridad esté implementado.

Concepto de relación de componentes y plantillas

Esquema de las plantillas y los componentes que se utilizan 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 van a implementar.

Concepto para maquetas de interfaces externas

Concepto de cómo desarrollar y probar interfaces externas que pueden no estar abiertas o disponibles para los entornos de desarrollo o prueba.

Planifique e implemente maquetas de estas interfaces para garantizar que las pruebas se aproximen lo más posible al comportamiento de producción.

Documento de arquitectura de contenido

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

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

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

Un borrador inicial del contrato legal.

Estructura y formato del contenido actual

Documentación de la arquitectura y el formato de contenido actuales. Se utiliza para generar la futura arquitectura de contenido. También se utilizará para el Concepto de migración.

Directiva de backup y restauración del cliente

Políticas del cliente relativas a:

• realizar copias de seguridad de procesos tanto para los datos como para la solución
• almacenamiento del backup
• confirmación de que la copia de seguridad funciona según lo esperado
• restauración, si se produce un error

Directrices de codificación de clientes

Cualquier directriz o requisito del cliente sobre cómo se debe realizar el desarrollo.

Políticas de implementación/lanzamiento del cliente

Directivas del cliente que definen cómo y cuándo se pueden realizar implementaciones/lanzamientos.

A menudo incluyen plazos, programación y requisitos de aprobación.

Políticas o requisitos de supervisión del cliente

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

Programación de versiones de producción del cliente

La programación definida por el cliente para las versiones en los entornos de producción.

Políticas y requisitos de los informes de clientes

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

• la frecuencia con la que se deben entregar los informes específicos
• el formato de informes específicos
• requisitos especiales

Guía del cliente

Formular una hoja de ruta de los principales hitos a implementar, tanto tecnológicos como empresariales. A continuación, esta hoja de ruta se comunica al cliente.

Políticas de seguridad del cliente

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

• Requisitos para aprobar una evaluación de riesgos.
• 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 creación de sesiones.

Directrices de especificación del cliente

Cualquier directriz que el cliente tenga relacionada con el formato, el envío y la firma de especificaciones.

Informes de prueba del cliente

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

Se han documentado las personalizaciones y revisiones que afectan a las actualizaciones

Las personalizaciones o revisiones aplicadas deben documentarse, ya que pueden afectar a futuras actualizaciones:

• AEM Las plantillas se pueden personalizar para adaptarse a las necesidades de la empresa. Cualquier personalización que pueda afectar a la actualización debe estar completamente documentada. AEM Por ejemplo, cualquier cambio importante en la interfaz de usuario (IU) de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de la interfaz de usuario de.

• Cualquier actualización necesaria para la solución actual debe estar completamente documentada; estas pueden incluir:

  • paquetes fijos acumulativos (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 estos problemas

Seguridad predeterminada habilitada

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

Políticas y procesos de implementación/versión

Políticas formalizadas que abarcan tanto la implementación como las versiones del proyecto. Pueden incluir:

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

Cadencia de implementación establecida

Defina la frecuencia necesaria de 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 distintas fases (o etapas), cada una con actividades distintas. El objetivo es mejorar la planificación y la gestión.

Al definir la metodología, debe predefinir los entregables y artefactos específicos que crea y completa el equipo del proyecto para desarrollar o mantener la aplicación.

Definición de rol de desarrollo

Defina qué desarrollador o función está ejecutando pruebas de TI (rendimiento u otras) y/o de unidad 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.

Equipo de desarrollo entiende el alcance del proyecto y las expectativas

El equipo de desarrollo debe confirmar que comprende perfectamente lo siguiente:

• el ámbito del proyecto
• todas las expectativas del cliente
• la base de todas las decisiones tomadas por persona, por fase del proyecto

Especificación de cuadros de diálogo

Detalles acerca de los cuadros de diálogo necesarios para la solución.

Configuración del entorno de desarrollo de documentos

Documentación del entorno de desarrollo.

Configuración del entorno de producción de documentos

Documentación del entorno de producción.

Configuración del entorno de prueba de documentos

Documentación del entorno de prueba.

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 umbral y a qué niveles de rendimiento.

Prueba de durabilidad ejecutada

Ejecución de las pruebas de durabilidad.

Concepto de gestión de errores

El control 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 de gestión de errores

Documentación detallada del tratamiento de errores propuesto, basada en el Concepto de tratamiento de errores.

Procesos de escalación

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

• Equipo del proyecto
• Cliente
• Adobe

Establecer sesiones regulares de revisión de calidad

Establezca reuniones periódicas de revisión de la 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 existentes

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

Definiciones y criterios de éxito esperados

El patrocinador del proyecto recopila las expectativas comerciales relacionadas con el éxito del proyecto. Es importante tener el conjunto completo de expectativas disponibles al comienzo de un proyecto, ya que estas deberían influir en todas las decisiones tomadas a lo largo de la implementación.

Las expectativas pueden incluir:

• KPI específicos, como el aumento porcentual en páginas servidas
• reducir el tiempo de publicación de contenido
• objetivos de mayor nivel, como una interfaz fácil de usar

Requisitos de Experience Designs

Requisitos para toda la experiencia de la solución. Esto cubre factores como la personalización, la persistencia entre dispositivos y la experiencia del usuario, entre otros.

Especificaciones de experiencia

Detalles de los requisitos de diseño de la experiencia.

Sistema externo y dependencias del usuario/contexto del sistema

Diagrama (o conjunto de diagramas) que describe el ecosistema completo de la solución. Esto debe incluir elementos como las integraciones externas, interfaces, dependencias y redes.

Procedimiento y sistema de reserva

Definición del sistema de reserva:

• las funcionalidades críticas para el negocio que deben seguir funcionando si se produce un error crítico
• los procesos necesarios si hay reserva

Sistema de reserva y procedimiento probado

Prueba de extremo a extremo del sistema de reserva.

Aprobación del sistema de reserva de las partes interesadas empresariales

Firme, de parte de las partes interesadas del negocio, que el sistema de reserva y los procedimientos relacionados garantizan las funcionalidades críticas del negocio.

Confirmación de viabilidad sobre KPI

AEM Resultados de un estudio de viabilidad tanto para el diseño de soluciones de alto nivel como para el diseño de soluciones de alto nivel. Se deben medir con los KPI para garantizar que se cumplan.

Contrato finalizado

Se necesita un contrato finalizado y firmado antes de continuar con el proyecto. Esto se basa en la variable Borrador de contrato.

Funcionalidad de la solución aceptada por las partes interesadas

Confirmación de que las partes interesadas aceptan plenamente:

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

Programación del lanzamiento

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

• preparación para el lanzamiento
• 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 marcha según lo esperado.

Estimaciones de hardware

Estimaciones iniciales de:

• AEM la tornillería necesaria para una instalación básica de la
• cualquier requisito adicional basado en el diseño de soluciones 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 las necesidades de alto nivel ofrece un desglose generalizado de las necesidades del sistema, que abarca aspectos como:

• Procesos empresariales
• Funciones principales del sistema

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

Diseño de soluciones de alto nivel

El diseño de soluciones de alto nivel explica la arquitectura que se utiliza para desarrollar la solución. El diagrama de arquitectura proporciona una visión general de todo el sistema e identifica los componentes principales desarrollados para el producto y sus interfaces.

Mapa del sistema de alto nivel

Este mapa del sistema debe proporcionar un diagrama de alto nivel del sistema. Se diferencia del contexto de la solución en que es un mapa generalizado de todos los sistemas involucrados, no hay interfaces en este diagrama.

Estructura de contenido histórica

Definición de la estructura de contenido del sistema heredado. Se utiliza como referencia y también para preparar la estrategia de migración.

KPI de rendimiento histórico y rendimiento histórico

Debe recopilar y documentar las estadísticas de rendimiento y los KPI de rendimiento del sistema heredado. A continuación, se utilizan como punto de referencia y para realizar pruebas comparativas con la nueva solución.

Identificar las soluciones y funcionalidades clave

Una lista de las funcionalidades críticas para el negocio.

Implementación: cambios basados en los resultados de las pruebas de penetración

Implementación de todos los cambios necesarios (que se han cerrado) en la solución en función de los resultados de las pruebas de penetración.

Implementación: estrategia de pruebas automatizadas

Configuración de las herramientas y los procesos necesarios para admitir las 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, conceptos de etiquetado y reutilización de contenido.

Implementación: diseño de experiencias

Implementación de los requisitos para admitir el Experience Design.

Implementación: sistema de reserva y procedimientos

Implementación del sistema de reserva y procedimientos relacionados.

Implementación: integración

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

Implementación: estrategia de migración

La migración junto con la validación de 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

AEM Aplicación de todas las medidas de seguridad, incluidos los incumplimientos de las normas de seguridad de la.

Implementación: software de seguridad

Implementación de la seguridad de aplicaciones de software.

Implementación: concepto de seguridad de arquitectura del sistema

Implementación de la seguridad del sistema.

Implementación: Administración de URL

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

Implementación: Flujos de trabajo

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

Concepto de implementación

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

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

Este concepto también describe los marcos, bibliotecas y otros artefactos utilizados en la solución.

Informar al servicio de asistencia al Adobe sobre el programa de lanzamiento

Póngase en contacto con el equipo de Asistencia de Adobe para asegurarse de que cualquier asistencia que se necesite se pueda habilitar durante el lanzamiento.

Diseños de experiencia inicial

Conceptos preliminares para el diseño de las experiencias.

Pruebas de integración

Pruebas 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

En los procesos claros se registran todas las cuestiones encontradas y se hace un seguimiento de las actividades en curso con el fin de asegurar que se aborden todas las cuestiones.

Sistema y procesos de seguimiento de problemas

Un sistema de seguimiento, junto con los procesos necesarios, para registrar todas las cuestiones encontradas y hacer un seguimiento de las actividades en curso con el fin de garantizar que se aborden todas las cuestiones.

Todas las partes interesadas en el proyecto deben tener acceso para facilitar la transparencia del estado del proyecto.

Algunos ejemplos son Atlassian JIRA y HP Quality Center.

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 aplicación existentes que se reemplazarán con la nueva solución.

Los detalles del sistema heredado deben recopilarse para que sepa qué se puede retirar, cuándo y el impacto en cualquier otro sistema.

Lista de herramientas de desarrollo que se utilizarán

Una descripción de las herramientas que se utilizan en la implementación; las herramientas deben incluir lo siguiente:

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

Lista de usuarios que requieren acceso al Portal de asistencia de Adobe

Una lista de todos los usuarios y funciones que necesitan acceder al Portal de asistencia de Adobe.

La lista suele estar compuesta por el arquitecto de soluciones o el personal de TI del cliente.

Análisis de archivos de registro

Un análisis, junto con las recomendaciones resultantes, que define lo que se debe registrar para monitorizar la solución:

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

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

AEM Prueba y activación de tareas de mantenimiento de la como:

• compactación
• sistema limpio
• depuración de flujo de trabajo

Plan de migración

Documente la migración; incluyendo

• cronología de 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. Debe cubrir:

• detalles técnicos de la migración automatizada, si es posible
• pruebas de humo que se realizarán 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 periodo entre la migración y el lanzamiento real del nuevo sistema. Esto podría implicar la congelación de contenido, la doble publicación o el mantenimiento de un sistema alfa.

Monitorización: CPU

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

• media
• picos

Monitorado: E/S de disco

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

• media
• picos

Monitorado: espacio en disco

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

• media
• crecimiento con el tiempo

Debe monitorizar el uso de:

• el repositorio
• archivos de registro

Monitorado - Sistemas externos

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

• tasa de tráfico
• picos
• estabilidad

Monitorado: Ancho de banda de red

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

• tasa media de tráfico
• picos
• estabilidad

Monitorización: solicitudes

Monitorice las solicitudes realizadas a la solución.

Monitorización: puntos de seguridad

Supervisar en los puntos de seguridad definidos.

Monitorización - Sistema

Monitorizar el sistema en general; por ejemplo:

• disponibilidad
• rendimiento medio
• picos de rendimiento
• alertas

Monitorización: umbral e intervención

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

Concepto de monitorización

Los conceptos de monitoreo que se aplicarán a su solución; incorporando:

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

Monitorización de puntos débiles potenciales

Deben identificarse y definirse los puntos específicos que podrían ser susceptibles de fracaso. También deben definirse las tareas de seguimiento relacionadas con estas.

Algunos ejemplos son (entre otros):

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

Directiva de supervisión comunicada al ingeniero de sistemas

Asegúrese de que los ingenieros del sistema y el personal de operaciones conozcan y comprendan cualquier política de monitorización.

Monitorización de informes: estructura in situ

Definir:

• cuándo se deben generar los informes de monitorización
• a quién deben entregarse

Documentación de tareas operativas

Todas las tareas operativas documentadas, con su frecuencia definida.

Manual de operaciones

Manual que proporciona toda la información necesaria para el éxito de las operaciones y el mantenimiento de la solución:

• todas las tareas operativas
• contactos clave
• planes de implementación
• listas de comprobación previas/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 cumpliendo con esos KPI

Paquete preparado

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

Pruebas de penetración

Una prueba de penetración (conocida informalmente como prueba de lápiz) es un ataque a un sistema informático que busca puntos débiles de seguridad y que puede obtener acceso a las características y los datos del equipo.

Pruebas de penetración: superadas

Se aprueban todos los criterios requeridos.

Pruebas de penetración: resultados

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

Concepto de rendimiento y escalabilidad

Documento conceptual sobre cómo garantizar que la implementación cumple los KPI de rendimiento y cómo escalar la solución para que siga cumpliendo esos KPI.

Referencia de rendimiento

La prueba de rendimiento se utiliza para definir las pruebas de rendimiento, las pruebas de durabilidad y la monitorización. 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 son el tiempo de carga de la página, el tiempo de respuesta del servidor y el rendimiento de las consultas de base de datos.

Pruebas de rendimiento: informe

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

Pruebas de rendimiento: los resultados coinciden con los KPI de rendimiento

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

Concepto de prueba basada en personas

Las pruebas basadas en personas son un método basado en las diferentes personas descritas en los diseños de experiencia. También prueba las cuentas y sus niveles de permisos relacionados.

Esto se utiliza a menudo en las Pruebas de aceptación de usuarios (UAT).

POC probado y verificado contra la documentación de requisitos

La Prueba de concepto (POC) se mide en función de 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 base del entorno de producción

AEM Es habitual ejecutar una prueba de línea de base en una instalación estándar de la. A continuación, se utiliza como referencia para probar la implementación y el hardware con.

Entorno de producción listo

Confirme que el entorno de producción está listo y que se han implementado implementaciones automatizadas.

Firma de producción por parte de las partes interesadas empresariales

Antes de entrar en funcionamiento en el entorno de producción, se debe conceder la firma de producción (PSO). Este es el resultado de una revisión de la versión que entrará en producción, junto con cualquier problema conocido. La firma se proporciona como parte de la programación de lanzamiento.

Proceso y política de desactivación de producción

La directiva 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 empresariales como para el equipo del proyecto.

Esfuerzos del proyecto - Estimaciones finales

El estimaciones iniciales fueron de alto nivel y se realizaron de acuerdo con los requerimientos de alto nivel para la implementación.

Ahora se revisan, refinan y amplían para proporcionar las estimaciones finales. Las estimaciones deben ser entregadas por cada jefe de proyecto apropiado, incluyendo la administración de proyectos, consultoría, arquitectura, pruebas y desarrollo.

Estas estimaciones se utilizan para la asignación de recursos y la presupuestación.

Esfuerzos del proyecto - Estimaciones iniciales

Las estimaciones iniciales son de alto nivel y se elaboran de acuerdo con las necesidades de alto nivel para la aplicación. Esto se revisará y perfeccionará en etapas posteriores.

Organización del proyecto

La documentación necesaria para esbozar la organización y la estructura de informes del proyecto y el equipo.

A menudo adopta la forma, o incluye, un gráfico para presentar una visión general visual de los plazos y las responsabilidades. Hay muchas herramientas disponibles para ayudarle con esto.

Documento de ámbito del proyecto

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

• Objetivos específicos del proyecto
• Entregables
• Características
• Funciones
• Tareas
• Plazos
• Esfuerzo planificado

Abarca lo que se debe lograr, junto con el trabajo que se debe hacer, para entregar el proyecto

Informes de estado del proyecto dentro de una cadencia definida

Los informes de estado del proyecto se entregarán de acuerdo con la programación acordada y con el formato requerido.

Prueba de concepto (POC)

La Prueba de concepto (POC) implementa una gama limitada de funciones para la solución.

Debe tener como objetivo demostrar la viabilidad de la solución, verificar que puede cumplir el propósito requerido y demostrar que existe el potencial de que se utilice.

Reglas de depuración

AEM mantiene varias versiones de recursos y contenido. Las reglas de purga están diseñadas y configuradas para eliminar periódicamente las versiones anteriores y mantener el estado y el tamaño del repositorio.

Formato y cadencia del informe de calidad

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

Versión coordinada

El administrador del proyecto coordina todas las funciones necesarias para la publicación en 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 deben cubrir:

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

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

Versión en ejecución en el entorno de producción

Versión final en ejecución y activa en producción.

Condiciones del contrato relevantes

Resalte las condiciones específicas del contrato que sean relevantes para la implementación del proyecto; como los hitos contractuales, los períodos de factura o los requisitos de personal.

Cadencia de informes

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

Optimización de repositorios

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 establece una estrategia de optimización para eliminar datos obsoletos.

Solicitud para configurar la sección del proyecto en el portal de soporte de Adobe

La solicitud oficial para configurar su proyecto en el Portal de soporte de Adobe.

Documentación de requisitos

Este conjunto de documentación abarca las necesidades funcionales y no funcionales, junto con los esfuerzos estimados.

Recursos disponibles para la asistencia del lanzamiento

Asegúrese de que todas las funciones requeridas para go live cuenten con personal y estén disponibles.

Evaluación de riesgos

La evaluación de riesgos está a cargo del departamento de TI del cliente, el departamento de seguridad o ambos.

Evalúa los riesgos técnicos y empresariales 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) asociadas a la solución.

Su objetivo es indicar la eficiencia 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 requeridos para la nueva solicitud, incluida una descripción de alto nivel de:

• funciones
• grupos
• usuarios
• permissions
• y administración y aprovisionamiento de usuarios

El concepto de funciones y derechos cumple las directrices de seguridad

Revisión del concepto de funciones y derechos para asegurarse de que cumple las directivas de seguridad.

Especificación de funciones y derechos

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

Arquitectura de seguridad Recommendations

Recommendations relacionado con la seguridad de la arquitectura de software y hardware.

Directrices de codificación basada en seguridad

Estas directrices definen cómo se debe realizar la codificación de desarrollo, en función de requisitos de seguridad como:

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

Lista de comprobación de seguridad

Lista de comprobación de elementos específica del proyecto, basada en el concepto de seguridad junto con cualquier directiva adicional necesaria para garantizar el cumplimiento de la solución.

A menudo, esto también se incluye como parte de los pasos posteriores a la implementación en el Runbook.

Concepto de seguridad

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

Borrador del concepto de seguridad

Una descripción de alto nivel que cubra la configuración de seguridad de:

• aplicación
• arquitectura
• infraestructura

Problemas de seguridad enumerados y evaluados

Se enumeran y evalúan todos los problemas de seguridad de la solución, incluidas las estimaciones de esfuerzo.

Cierre de seguridad de las partes interesadas empresariales

Firme con las partes interesadas para garantizar que la implementación de seguridad cumpla con las políticas y expectativas.

Configuración de procesos de asistencia

Establezca los procesos de soporte necesarios.

SLA para sistemas de terceros

Asegúrese 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 la asistencia.

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 y funcionalidades básicas de la solución.

Se ejecutan en cualquier entorno después de la instalación o implementación.

Pruebas de humo ejecutadas para la validación del sistema

Las pruebas de humo deben ejecutarse en todos los sistemas para garantizar el funcionamiento correcto de la funcionalidad básica de la solución en la instalación o implementación en cualquier entorno.

Estrategia de arquitectura de software

La estrategia de alto nivel para la arquitectura de software; incluidos servicios, servlets, marcos y otras decisiones de implementación.

Se estableció la Junta de Revisión de Soluciones y se estableció la cadencia de la reunión

El panel de revisión de soluciones está compuesto por partes interesadas del cliente.

La junta celebra reuniones periódicas para examinar de forma continua los requisitos actualmente previstos y las especificaciones pertinentes. El objetivo es garantizar la alineación con la definición y los criterios de éxito y también contribuir a la elaboración de los requisitos.

Runbook de soluciones

Instrucciones de instalación de la solución, junto con tareas operativas básicas que se ejecutarán durante la instalación.

Proceso de aprobación y desactivación de la solución

El proceso de firma y aceptación describe los criterios que deben cumplirse para que la solución pueda lanzarse a un entorno productivo.

También puede servir como hito contractual.

Concepto de funcionalidad especial

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

Especificación de funcionalidad especial

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

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 especificaciones por parte del cliente. Este proceso garantiza la claridad y la firmeza del ámbito de aplicación de los requisitos.

AEM Personal seleccionado para la formación de administradores de

Personal interno que necesita formación para administrar la solución.

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

Personal interno que necesita formación para crear la solución.

Partes interesadas

Las partes interesadas son las personas 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.

Las partes interesadas son conscientes de las definiciones y los criterios de éxito

Confirmación de que todas las partes interesadas fuera del equipo de implementación real son conscientes de lo siguiente:

• definiciones de éxito
• criterios de éxito

Las partes interesadas entienden el proyecto y las expectativas

Confirmación de que todas las partes interesadas fuera del equipo de implementación real están en alineación con el proyecto general y las expectativas, tanto internas del equipo del proyecto como del cliente.

Definición del formato del informe de estado

Los informes de estado son una herramienta clave de comunicación. El formato debe estar en consonancia con los requisitos de información del cliente.

Criterios y definición de éxito

El cliente, el patrocinador del proyecto y el administrador 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 a lo largo de la implementación.

Compatibilidad en la validación de problemas notificados

Parte de las responsabilidades del responsable de calidad es garantizar que haya recursos disponibles para apoyar a cualquier usuario durante las pruebas. Por ejemplo, para ayudar al usuario a realizar pruebas, notificar problemas y 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 de Adobe es crucial para enviar tickets acerca de cualquier problema basado en productos que pueda surgir durante la implementación.

El acceso debe asignarse a los miembros clave del equipo.

Definición de arquitectura del sistema

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

Documentación de arquitectura del sistema

Documento que detalla la arquitectura del sistema, incluidas las interfaces, la ubicación de red y las integraciones para todos los entornos, entre otra información.

Concepto de seguridad de arquitectura de sistemas

Descripción general de cómo hacer que la arquitectura del sistema sea compatible con las directivas de seguridad. Esto puede cubrir:

• cortafuegos y reglas de cortafuegos
• zonas de seguridad
• administradores de tráfico local y general
• servidores web
• proxies y proxies inversos

Factores de riesgo del sistema identificados y verificados

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

• el nivel de riesgo implícito en cada uno
• junto con el esfuerzo estimado para cualquier cambio en la implementación que sea necesario para solucionarlo.

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

Confirmación de que todo el equipo está al tanto de las definiciones y los criterios de éxito.

El equipo está al tanto del 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 entiende 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écnicos verificados

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

• ejecución de scripts en sitios múltiples
• campos de entrada para el usuario final
• infraestructura
• era tecnológica
• número de integraciones
• y dependencias

Especificaciones técnicas

La especificación técnica cubre (entre otra información):

• interfaces
• configuraciones
• API
• servicios compatibles con los requisitos de la solución

Especificación de plantilla

Las especificaciones para las plantillas requeridas. Estos deben cubrir detalles, incluidos parsys, modelo y asignación de herencia, entre otros.

Las especificaciones se basan en los requisitos empresariales y los requisitos de experiencia.

Casos de prueba

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

Contenido de prueba

El contenido de la prueba debe estar lo más cerca posible del contenido de producción. Debe ser de una selección lo suficientemente amplia como para permitir probar todos los escenarios.

Entorno de prueba listo

Asegúrese de que el entorno de prueba esté listo e implemente implementaciones automatizadas para garantizar que todo el código candidato a la versión esté actualizado para la prueba.

Informes de prueba

Informes que detallen los resultados de las pruebas; incluidos:

• defectos planteados
• 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 entregue los resultados de la prueba.
• Es responsabilidad del gestor del proyecto evaluar las implicaciones de los resultados y decidir las acciones apropiadas.

Grupo de pruebas

Selección del conjunto de automatización y las herramientas. Se utilizan para automatizar pruebas, incluidas las de 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 la descripción de alto nivel de las pruebas del proyecto; incluye pruebas de control de calidad, UAT, rendimiento, seguridad y pruebas de integración.

Planes de prueba

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

Ámbito de 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 pruebas describe la estrategia de alto nivel para el aseguramiento de la calidad y las pruebas de aceptación de los usuarios. Esto incluye líneas de tiempo, cadencia de creación 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 (tanto funcionales como no funcionales) para la funcionalidad admitida y la integración de los sistemas de terceros.

Concepto de seguridad de terceros

Concepto para garantizar la seguridad de cualquier integración de terceros. Debe cumplir las directivas 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

Se han concedido los derechos de acceso requeridos a las funciones respectivas utilizadas 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 monitorizar los puntos 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

Cronología 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

Todas las estimaciones de esfuerzo, de cada uno de los líderes del proyecto, deben consolidarse; incluyendo, gastos generales, desarrollo, ingeniería de sistemas, arquitectura y esfuerzos de prueba.

Si hay un nivel de apoyo incluido en el acuerdo, también deben incluirse los esfuerzos de apoyo y operaciones.

Materiales de formación

Materiales que se utilizarán en las sesiones de formación. Los materiales deben crearse específicamente para la solución y diseñarse para utilizarse con las guías del usuario.

Comprender el ámbito del proyecto y las expectativas

La persona adecuada debe confirmar que comprende perfectamente lo siguiente:

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

Concepto de administración de URL

AEM El concepto de administración de URL debe cubrir las funcionalidades de URL específicas de la, incluidas las siguientes:

• URL de vanidad
• externalización de vínculos
• 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 lograr un objetivo. Normalmente, 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écnicos y comerciales. Se utilizan para probar 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

Todas las partes interesadas deben revisar y validar el plan presupuestario. Deben comprobar detalles como la facturación, los importes y los métodos/plazos de los informes de presupuesto.

Resultados de la prueba de White Box

La prueba de los cuadros blancos es un método que prueba las estructuras internas o el funcionamiento de una aplicación, en contraposición a su funcionalidad. La prueba de la 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

Basándose en el Concepto de flujos de trabajo, estas especificaciones deben definir, en detalle, los pasos que crean el flujo de trabajo completo.

La especificación de cada flujo de trabajo debe incluir (como mínimo):

• caso de uso
• funciones
• pasos
• resultados
• tratamiento errores

Concepto de flujos de trabajo

AEM Los flujos de trabajo permiten automatizar las actividades de la. El concepto Flujos de trabajo describe:

• los procesos que necesitan automatización
• AEM los servicios y funciones en los que se verán afectados los servicios y las funciones de la