Glosario glossary

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

Aceptación de las partes interesadas empresariales acceptance-from-business-stakeholders

La aceptación de las partes interesadas empresariales confirma que, como partes interesadas clave, están de acuerdo 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 acceptance-tests

Las pruebas de aceptación se realizan cuando una aplicación está lista para la producción. Las pruebas las lleva a cabo un grupo que representa los distintos tipos de usuarios finales y utilizan escenarios reales.

Las pruebas de aceptación sirven para confirmar lo siguiente:

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 (funcionales y de rendimiento).

Acceso al sistema de pruebas coordinado access-to-test-system-coordinated

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 adobe-security-checklist

La lista de comprobación de seguridad de Adobe es la lista de comprobación oficial proporcionada para garantizar que Adobe Experience Manager (AEM) sea seguro durante la instalación. Contiene las medidas de seguridad y verificación que debe seguir para garantizar la integridad de la instancia.

Configuración del proyecto del Portal de asistencia de Adobe adobe-support-portal-project-set-up

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

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

Formación de administrador de AEM aem-administrator-training

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

Formación de autor de AEM aem-author-training

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

Examen de certificación de AEM aem-certification-exam

Asegúrese de que los perfiles adecuados estén registradas para realizar los exámenes de certificación relevantes.

Certificación de AEM aem-certified

Asegúrese de que el perfil apropiado haya pasado los exámenes de certificación relevantes.

Formación técnica de AEM aem-technical-training

Proporcionar formación técnica a los perfiles adecuados; por ejemplo, desarrolladores, arquitectos, ingenieros y profesionales del negocio.

Acuerdo sobre los KPI definidos como objetivos para el proyecto agreement-on-kpis-defined-as-goals-for-the-project

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

Alineación de KPI empresariales y de rendimiento align-business-and-performance-kpis

La alineación de los indicadores clave de rendimiento (KPI) y empresariales 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 planteado.

Alineación de la arquitectura de contenido con los KPI alignment-of-content-architecture-with-kpis

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 alignment-of-the-customer-roadmap-with-project-timeline

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 supervisar todos los riesgos potenciales o posibles desviaciones.

Definición de arquitectura de aplicación application-architecture-definition

La arquitectura de la aplicación debe definir con claridad el comportamiento de las aplicaciones propuestas.

Se centra en lo siguiente:

Tareas de mantenimiento específicas de la aplicación definidas application-specific-maintenance-tasks-defined

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 appropriately-trained-staff

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

Diagrama de arquitectura architecture-diagram

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

Borrador de arquitectura architecture-draft

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.

Aprobación del consejo de revisión de la arquitectura architecture-review-board-sign-off

El consejo de revisión de la arquitectura es un organismo interorganizacional encargado de lo siguiente:

El consejo de revisión debe ser representativo de todas las partes interesadas clave relacionadas con la arquitectura. Por lo general, está compuesto 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 comparados con los KPI automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

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

Estrategia de pruebas automatizadas automated-testing-strategy

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

Estrategia de pruebas automatizadas validadas con una carga realista y esperada automated-testing-strategy-validated-against-realistic-and-expected-load

La estrategia de pruebas automatizadas debe validarse y ajustarse según el contenido y la carga esperada que tendrá la solución.

Estrategia de automatización automation-strategy

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:

Conocimiento del plan de comunicación aware-of-communication-plan

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

Conocimiento de las definiciones y los criterios de éxito aware-of-success-definitions-and-criteria

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

Concepto de copia de seguridad y restauración backup-and-restore-concept

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.

Pruebas de copia de seguridad y restauración backup-and-restore-tested

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

Casos empresariales business-case-s

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, estar basados en hechos concretos (siempre que sea posible/pertinente) y destacar tanto los beneficios como los riesgos para todos los casos.

Un documento de caso empresarial debe ser una definición clara de todas las opciones y concluir con un argumento convincente para la implementación de la solución propuesta.

Analista empresarial con entendimiento del ámbito del proyecto y las expectativas business-analyst-understands-scope-of-project-and-expectations

El analista empresarial debe confirmar que comprende a la perfección lo siguiente:

KPI empresariales business-kpis

Las organizaciones utilizan indicadores clave de rendimiento (KPI) para evaluar su éxito en la consecución de los objetivos.

Los KPI empresariales definen valores mensurables que demuestran la eficacia con la que una compañía logra objetivos empresariales 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 business-requirements-documentation

Un documento de requisitos empresariales (BRD, por sus siglas en inglés) detalla la solución empresarial para un proyecto, al tiempo que proporciona una especificación clara de las necesidades y expectativas empresariales del cliente. El BRD también distingue entre la solución empresarial y la solución técnica.

Al examinar la solución empresarial, el BRD debe responder a la pregunta:
“¿Qué quiere hacer el negocio?”

Aprobación empresarial de cualquier ajuste necesario en la solución o arquitectura identificado y alineado con las expectativas de ROI y KPI business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

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 que resulte de estos procesos debe someterse a revisión y aprobación por parte de la empresa y evaluarse en función de los objetivos generales.

Estrategia de almacenamiento en caché caching-strategy

La estrategia de almacenamiento en caché describe lo que se almacenará en caché para el usuario final. Debe cumplir 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 programación coding-guidelines

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

Comunicación del manual de operaciones communicate-operations-manual

Asegúrese de que todos los perfiles o funciones pertinentes hayan recibido el manual de operaciones.

Comunicación del informe de pruebas de rendimiento communicate-performance-test-report

Asegúrese de que todos los perfiles o funciones pertinentes hayan recibido el informe de pruebas de rendimiento.

Comunicación de las notas de la versión communicate-release-notes

Asegúrese de que todos los perfiles o funciones pertinentes hayan recibido las notas de la versión.

Comunicación del ámbito y las expectativas al equipo communicate-scope-and-expectations-to-team

Asegúrese de que el equipo del proyecto conozca a la perfección el ámbito del proyecto y las expectativas de entrega, y que se ajuste a ellos.

Comunicación de los materiales de formación y las guías del usuario communicate-training-materials-and-user-guides

Asegúrese de que todos los perfiles o funciones pertinentes hayan recibido los materiales de formación y las guías del usuario.

Cumplimiento de los requisitos de seguridad del cliente compliance-with-customer-security-requirements

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

Cumplimiento del concepto de seguridad compliance-with-security-concept

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

Concepto de relación de componentes y plantillas components-and-templates-relationship-concept

El esquema de las plantillas y los componentes que se utilizan en la nueva aplicación. Incluye detalles como las reglas de herencia, los permisos y las relaciones, entre otros.

Especificación de relación de componentes y plantillas components-and-templates-relationship-specification

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

Especificación de componentes components-specification

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

Concepto para maquetas de interfaces externas concept-for-mock-ups-of-external-interfaces

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

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

Documento de arquitectura de contenido content-architecture-document

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

Contenido validado para la migración content-validated-for-migration

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

Borrador del contrato contract-draft

Un borrador inicial del contrato legal.

Estructura y formato del contenido actual current-content-structure-and-format

Documentación de la arquitectura y el formato del contenido actual. Se usa para generar la futura arquitectura de contenido. También se utilizará para el concepto de migración.

Directiva de restauración y copia de seguridad del cliente customer-backup-and-restore-policy

Directivas del cliente relativas a lo siguiente:

Directrices de programación del cliente customer-coding-guidelines

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

Directivas de implementaciones/versiones del cliente customer-deployment-release-policies

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

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

Directivas o requisitos de monitorización del cliente customer-monitoring-policies-or-requirements

Directivas y requisitos del cliente sobre lo que se debe monitorizar. Estos se suman a las recomendaciones especificadas en el concepto de monitorización.

Programación de versiones de producción del cliente customer-production-release-schedule

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

Directivas y requisitos de creación de informes del cliente customer-reporting-policies-and-requirements

Cualquier directiva, requisito o ambos que el cliente tenga en relación con la creación de informes. Estos pueden incluir lo siguiente:

Hoja de ruta del cliente customer-roadmap

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

Directivas de seguridad del cliente customer-security-policies

El cliente (empresa y TI) tendrá directivas que definen los niveles de seguridad necesarios para la solución. Estos pueden incluir lo siguiente:

Directrices de especificación del cliente customer-specification-guidelines

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

Informes de pruebas del cliente customer-test-reports

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

Personalizaciones y revisiones que afectan a las actualizaciones documentadas customizations-and-hotfixes-that-affect-upgrades-documented

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

Informe de pruebas de aceptación del usuario diarias daily-user-acceptance-test-report

Informes o reuniones resultantes de las pruebas de aceptación del usuario (UAT). Deberían detallar lo siguiente:

Seguridad predeterminada habilitada default-security-enabled

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

Directivas y procesos de implementación/versión deployment-release-policies-and-processes

Directivas formalizadas que abarcan tanto la implementación como las versiones del proyecto. Estos pueden incluir lo siguiente:

Cadencia de implementación establecida deployment-cadence-established

Defina la frecuencia necesaria de implementaciones entre entornos.

Metodología de desarrollo development-methodology

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 la función de desarrollo development-role-definition

Defina qué desarrollador o función ejecuta pruebas de TI (rendimiento u otras) o de unidad dentro de la solución.

Entorno de desarrollo listo development-environment-ready

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 con entendimiento del ámbito del proyecto y las expectativas development-team-understands-scope-of-project-and-expectations

El equipo de desarrollo debe confirmar que comprende a la perfección lo siguiente:

Especificación de cuadros de diálogo dialogs-specification

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

Documento de configuración del entorno de desarrollo document-development-environment-setup

Documentación del entorno de desarrollo.

Documento de configuración del entorno de producción document-production-environment-setup

Documentación del entorno de producción.

Documento de configuración del entorno de pruebas document-test-environment-setup

Documentación del entorno de pruebas.

Prueba de durabilidad durability-test

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 durability-test-executed

Ejecución de las pruebas de durabilidad.

Concepto de gestión de errores error-handling-concept

La gestión 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 error-handling-documentation

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

Procesos de escalación escalation-processes

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

Establecimiento de sesiones regulares de revisión de calidad establish-regular-quality-review-sessions

Establezca reuniones periódicas de revisión de la calidad con los integrantes del equipo pertinentes.

Estructura de permisos existente existing-permissions-structure

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

Mapa de sistemas existentes existing-systems-map

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

Definiciones y criterios de éxito esperados expected-success-definitions-and-criteria

El patrocinador del proyecto recopila las expectativas empresariales relacionadas con el éxito del proyecto. Es importante tener el conjunto completo de expectativas disponible 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 lo siguiente:

Requisitos de diseño de la experiencia experience-designs-requirements

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 experiencia experience-specifications

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

Sistema externo y dependencias del usuario/contexto del sistema external-system-and-user-dependencies-system-context

Un 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 fallback-system-and-procedure

Definición del sistema de reserva:

Procedimiento y sistema de reserva probados fallback-system-and-procedure-tested

Prueba de extremo a extremo del sistema de reserva.

Aprobación del sistema de reserva de las partes interesadas empresariales fallback-system-sign-off-from-business-stakeholders

Aprobación, de las partes interesadas empresariales, de que el sistema de reserva y los procedimientos relacionados garantizan las funcionalidades críticas del negocio.

Confirmación de viabilidad sobre KPI feasibility-confirmation-on-kpis

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

Contrato finalizado finalized-contract

Se necesita un contrato finalizado y firmado antes de continuar con el proyecto. Esto se basa en el borrador del contrato.

Funcionalidad de la solución aceptada por las partes interesadas functionality-of-the-solution-accepted-by-stakeholders

Confirmación de que las partes interesadas aceptan por completo lo siguiente:

Programación de lanzamiento go-live-schedule

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

Caminos ideales definidos happy-paths-defined

Un camino ideal 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 hardware-estimates

Estimaciones iniciales de lo siguiente:

Hardware disponible para cumplir los requisitos hardware-will-be-available-to-fulfill-requirements

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

Requisitos de alto nivel high-level-requirements

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

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

Diseño de soluciones de alto nivel high-level-solution-design

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

Mapa del sistema de alto nivel high-level-system-map

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 historical-content-structure

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

Rendimiento histórico y KPI de rendimiento histórico historical-performance-and-historical-performance-kpis

Recopile y documente estadísticas de rendimiento y KPI de rendimiento del sistema heredado. Después, sirven como punto de referencia y para realizar pruebas comparativas con la nueva solución.

Identificación de las soluciones o funcionalidades clave identify-critical-key-solutions-functionalities

Una lista de las funcionalidades críticas para la empresa.

Implementación: cambios según los resultados de las pruebas de penetración implementation-changes-based-on-penetration-test-results

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

Implementación: estrategia de pruebas automatizadas implementation-automated-testing-strategy

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

Implementación: estrategia de automatización implementation-automation-strategy

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

Implementación: arquitectura de contenido implementation-content-architecture

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

Implementación: diseño de la experiencia implementation-experience-design

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

Implementación: procedimientos y sistema de reserva implementation-fallback-system-and-procedures

Implementación del sistema de reserva y procedimientos relacionados.

Implementación: integración implementation-integration

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

Implementación: estrategia de migración implementation-migration-strategy

La migración junto con la validación de contenido y otros artefactos para la nueva solución.

Implementación: funciones y derechos implementation-roles-and-rights

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

Implementación: concepto de seguridad implementation-security-concept

Implementación de todas las medidas de seguridad, incluidos los valores predeterminados de AEM.

Implementación: software de seguridad implementation-security-software

Implementación de la seguridad de la aplicación de software.

Implementación: concepto de seguridad de arquitectura del sistema implementation-system-architecture-security-concept

Implementación de la seguridad del sistema.

Implementación: gestión de URL implementation-url-handling

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

Implementación: flujos de trabajo implementation-workflows

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

Concepto de implementación implementation-concept

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

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

Información al servicio de asistencia de Adobe sobre la programación de lanzamiento inform-adobe-support-about-the-go-live-schedule

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

Diseños de la experiencia iniciales initial-experience-designs

Conceptos preliminares para el diseño de las experiencias.

Pruebas de integración integration-testing

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 issue-tracking-process

En los procesos claros se registran todos los problemas encontrados y se hace un seguimiento de las actividades en curso con el fin de asegurar que se aborden todos.

Sistema y procesos de seguimiento de problemas issue-tracking-system-and-processes

Un sistema de seguimiento, junto con los procesos necesarios, para registrar todos los problemas encontrados y hacer un seguimiento de las actividades en curso con el fin de asegurar que se aborden todos.

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

Algunos ejemplos son Atlassian JIRA y HP Quality Center.

Proceso del sistema de seguimiento de problemas configurado e integrado issue-tracking-system-process-is-set-up-and-integrated

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

Sistema heredado legacy-system

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 list-of-development-tools-to-be-used

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

Lista de usuarios que necesitan acceso al Portal de asistencia de Adobe list-of-users-that-require-access-to-adobe-support-portal

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 del archivo de registro log-file-analysis

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

Tareas de mantenimiento (específicas de AEM) probadas y habilitadas maintenance-tasks-aem-specific-tested-and-enabled

Prueba y habilitación de tareas de mantenimiento de AEM como las siguientes:

Plan de migración migration-plan

Documente la migración; incluyendo lo siguiente:

Estrategia de migración migration-strategy

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

También debería recomendar cómo mantener el contenido actualizado (o lo más actualizado posible) durante el período comprendido entre la migración y el propio lanzamiento del nuevo sistema. Esto podría implicar una congelación del contenido, una publicación doble o el mantenimiento de un sistema alfa.

Monitorización: CPU monitoring-cpu

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

Monitorización: E/S de disco monitoring-disk-i-o

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

Monitorización: espacio en disco monitoring-disk-space

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

Debe monitorizar el uso mediante lo siguiente:

Monitorización: sistemas externos monitoring-external-system-s

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

Monitorización: ancho de banda de red monitoring-network-bandwidth

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

Monitorización: solicitudes monitoring-requests

Monitorice las solicitudes hechas a la solución.

Monitorización: puntos de seguridad monitoring-security-points

Monitorice los puntos de seguridad definidos.

Monitorización: sistema monitoring-system

Monitorice el sistema en general; por ejemplo:

Monitorización: umbral e intervención monitoring-threshold-and-intervention

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 monitoring-concept

Los conceptos de monitorización que se aplicarán a su solución. Incorporan lo siguiente:

Monitorización de puntos débiles potenciales monitoring-potential-weak-points

Deben identificarse y definirse los puntos específicos que podrían ser susceptibles de fracaso. También debe definirse cualquier tarea de monitorización relacionada con estos.

Algunos ejemplos incluyen (entre otros):

Directiva de monitorización comunicada al ingeniero de sistemas monitoring-policy-communicated-to-system-engineer

Asegúrese de que los ingenieros del sistema y el personal de operaciones conozcan y comprendan todas las directivas de monitorización.

Monitorización de informes: estructura establecida monitoring-reports-structure-in-place

Defina lo siguiente:

Documentación de tareas operativas operational-tasks-documentation

Todas las tareas operativas documentadas, con su frecuencia definida.

Manual de operaciones operations-manual

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

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

Paquete preparado package-prepared

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

Pruebas de accesos penetration-tests

Una prueba de penetración (conocida informalmente como “pen test”) es un ataque a un sistema informático que busca puntos débiles de seguridad, con el fin de acceder a las funciones y datos del ordenador.

Pruebas de penetración: superadas penetration-tests-passed

Se superan todos los criterios requeridos.

Pruebas de penetración: resultados penetration-tests-results

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

Concepto de rendimiento y escalabilidad performance-and-scalability-concept

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 performance-benchmark

La referencia de rendimiento sirve 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 performance-kpis

Definen los indicadores clave de rendimiento (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 performance-tests-report

Los 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 performance-tests-results-match-performance-kpis

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

Concepto de pruebas basadas en perfiles persona-based-testing-concept

Las pruebas basadas en perfiles son un método basado en los diferentes perfiles descritos en los diseños de experiencia. También evalúan las cuentas y sus niveles de permisos relacionados.

Esto se utiliza a menudo en las pruebas de aceptación del usuario (UAT).

POC probada y verificada con la documentación de requisitos poc-tested-and-verified-against-requirement-documentation

La prueba de concepto (POC) se mide en función de los requisitos para garantizar que coinciden.

Lista de comprobación posterior a la implementación post-deployment-checklist

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 pre-deployment-checklist

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 del entorno de producción production-environment-baseline-performance-tests

Es habitual ejecutar una prueba de línea de base en una instalación estándar de AEM. Después, sirve como referencia para probar la implementación y el hardware.

Entorno de producción listo production-environment-ready

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

Aprobación de producción de las partes interesadas empresariales production-sign-off-from-business-stakeholders

Antes del lanzamiento en el entorno de producción, se debe conceder la aprobación 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 aprobación se proporciona como parte de la programación de lanzamiento.

Proceso y directiva de aprobación de producción production-sign-off-process-and-policy

La directiva y el proceso necesarios para obtener la aprobación de producción antes de mover el paquete al entorno de producción.

Plan de comunicación del proyecto project-communication-plan

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

Esfuerzos del proyecto: estimaciones finales project-efforts-final-estimates

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

Ahora se revisan, refinan y amplían para proporcionar las estimaciones finales. Cada responsable de proyecto correspondiente deberá presentar sus estimaciones, que incluirán la administración del proyecto, la consultoría, la arquitectura, las pruebas y el desarrollo.

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

Esfuerzos del proyecto: estimaciones iniciales project-efforts-initial-estimates

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

Organización del proyecto project-organization

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

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

Documento de ámbito del proyecto project-scope-document

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

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 project-status-reports-within-a-defined-cadence

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) proof-of-concept-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 purge-rules

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

Formato y cadencia del informe de calidad quality-report-format-and-cadence

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

Versión coordinada release-coordinated

El administrador del proyecto coordina todas las funciones necesarias para que la versión pase a producción.

Notas de la versión release-notes

Las notas de la versión forman parte de la documentación de la versión. Las notas de la versión deben abarcar lo siguiente:

Se utiliza con 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 release-running-on-production-environment

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

Condiciones del contrato relevantes relevant-contract-terms

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

Cadencia de creación de informes reporting-cadence

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

Optimización del repositorio repository-optimization

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 quitar los datos obsoletos.

Solicitud para configurar la sección del proyecto en el Portal de asistencia de Adobe request-for-setting-up-project-section-in-adobe-support-portal

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

Documentación de requisitos requirements-documentation

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

Recursos disponibles para la asistencia del lanzamiento resources-available-to-support-go-live

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

Evaluación de riesgos risk-assessment

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 directivas de seguridad.

Plan de mitigación de riesgos risk-mitigation-plan

El plan de mitigación de riesgos incluye la evaluación de riesgos. En conjunto, abarcan lo siguiente:

expectativas de ROI roi-expectations

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/ganancias esperados en relación con la inversión estimada.

Concepto de funciones y derechos roles-and-rights-concept

Especificación detallada de los conceptos relativos a las funciones y los derechos de acceso requeridos para la nueva aplicación, incluido un esquema de alto nivel de lo siguiente:

Concepto de funciones y derechos conforme a las directrices de seguridad roles-and-rights-concept-meets-security-guidelines

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

Especificación de funciones y derechos roles-and-rights-specification

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

Recomendaciones de arquitectura de seguridad security-architecture-recommendations

Recomendaciones relacionadas con la seguridad de la arquitectura de software y hardware.

Directrices de programación basada en la seguridad security-based-coding-guidelines

Estas directrices definen cómo debe efectuarse la programación del desarrollo, en función de requisitos de seguridad como los siguientes:

Lista de comprobación de seguridad security-checklist

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

Concepto de seguridad security-concept

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

Borrador del concepto de seguridad security-concept-draft

Un esquema de alto nivel que abarque la configuración de seguridad de lo siguiente:

Problemas de seguridad enumerados y evaluados security-issues-listed-and-assessed

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

Aprobación de seguridad de las partes interesadas empresariales security-sign-off-from-business-stakeholders

Aprobación de las partes interesadas para garantizar que la implementación de seguridad cumpla las directivas y expectativas.

Configuración de procesos de asistencia set-up-support-processes

Configure los procesos de soporte necesarios.

SLA para sistemas de terceros slas-for-third-party-systems

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 pruebas de humo smoke-test-concept

Las pruebas de humo consisten en un conjunto de pasos definidos que prueban las funcionalidades clave de la solución para garantizar sus operaciones y funcionalidad básicas.

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

Pruebas de humo ejecutadas para la validación del sistema smoke-tests-executed-for-system-validation

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 software-architecture-strategy

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

Constitución del consejo de revisión de la solución y determinación de la cadencia de las reuniones solution-review-board-established-and-meeting-cadence-set

El consejo de revisión de la solución está compuesto por las partes interesadas del cliente.

El consejo celebra reuniones periódicas para examinar de forma continua los requisitos definidos en la actualidad y las especificaciones pertinentes. El objetivo es garantizar que la definición y los criterios de éxito coincidan, así como aportar información para elaborar los requisitos.

Runbook de la solución solution-runbook

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 aceptación de la solución solution-sign-off-and-acceptance-process

El proceso de aprobación 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 special-functionality-concept

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

Especificación de funcionalidad especial special-functionality-specification

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

Directrices de especificación specification-guidelines

Cualquier directriz del cliente sobre cómo se debe realizar la especificación.

Definición y comunicación del proceso de revisión y aprobación de especificaciones specification-review-and-approval-process-defined-and-communicated

Debe establecerse un proceso claro para la aprobación de especificaciones por parte del cliente. Este proceso garantiza la claridad y la solidez del ámbito de los requisitos.

Personal seleccionado para la formación de administradores de AEM staff-selected-for-aem-administrator-training

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

Personal seleccionado para la formación de autores y usuarios finales staff-selected-for-author-and-end-user-training

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

Partes interesadas stakeholders

Las partes interesadas son las personas o funciones clave que tienen un interés significativo en el proyecto. Algunas contribuirán al presupuesto del proyecto.

Las partes interesadas pueden ser internas o externas.

Conocimiento de las definiciones y los criterios de éxito por las partes interesadas stakeholders-are-aware-of-success-definitions-and-criteria

Confirmación de que todas las partes interesadas fuera del propio equipo de implementación conocen lo siguiente:

Conocimiento del proyecto y las expectativas por las partes interesadas stakeholders-understand-project-and-expectations

Confirmación de que todas las partes interesadas fuera del propio equipo de implementación están de acuerdo con el proyecto y las expectativas generales, tanto internas del equipo del proyecto como del cliente.

Definición del formato del informe de estado status-report-format-definition

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

Criterios y definición de éxito success-criteria-and-definition

El cliente, el patrocinador del proyecto y el administrador o consultor del proyecto deben especificar lo siguiente:

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

Asistencia en la validación de problemas notificados support-in-validation-of-reported-issues

Parte de las competencias del responsable de calidad es garantizar que haya recursos disponibles para asistir a cualquier usuario durante las pruebas. Por ejemplo, para ayudar al usuario con las pruebas, la notificación de problemas y la validación de los problemas con el entorno de pruebas.

Procesos de asistencia y acceso al Portal de asistencia de Adobe support-processes-and-access-to-adobe-support-portal

El acceso al Portal de asistencia de Adobe es crucial para enviar vales sobre cualquier problema relacionado con los productos que pueda surgir durante la implementación.

El acceso debe asignarse a los miembros clave del equipo.

Definición de arquitectura del sistema system-architecture-definition

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

Documentación de la arquitectura del sistema system-architecture-documentation

Un 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 del sistema system-architecture-security-concept

Un esquema de alto nivel sobre cómo hacer que la arquitectura del sistema sea compatible con las directivas de seguridad. Esto puede abarcar lo siguiente:

Identificación y verificación de factores de riesgo del sistema system-risk-factors-identified-and-verified

Se identifican y evalúan todos los factores de riesgo encontrados en la evaluación del riesgo (u otras revisiones):

Conocimiento del equipo de las definiciones y los criterios de éxito team-is-aware-of-success-definitions-and-criteria

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

Conocimiento del equipo del plan de comunicación team-is-aware-of-the-communication-plan

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.

Conocimiento del equipo del proyecto y las expectativas team-understands-project-and-expectations

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

Requisitos técnicos technical-requirements

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

Verificación de factores de riesgo técnicos technical-risk-factors-verified

Identifique y verifique los riesgos técnicos potenciales. Los riesgos técnicos pueden incluir lo siguiente:

Especificación técnica technical-specification

La especificación técnica abarca (entre otra información) lo siguiente:

Especificación de plantilla template-specification

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

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

Casos de prueba test-cases

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

Contenido de prueba test-content

El contenido de prueba debe ser lo más parecido posible al contenido de producción. La selección debe ser lo bastante amplia como para permitir probar todos los escenarios.

Entorno de pruebas listo test-environment-ready

Asegúrese de que el entorno de pruebas esté listo, con implementaciones automatizadas para garantizar que todo el código candidato a la versión esté actualizado para las pruebas.

Informes de pruebas test-reports

Los informes que detallan los resultados de las pruebas; incluye lo siguiente:

Cabe señalar lo siguiente:

Grupo de pruebas test-suite

Selección del grupo de automatización y las herramientas. Se utilizan para automatizar las pruebas, incluidas las de casos de uso.

Selección del grupo de herramientas de prueba test-tooling-suite-selected

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

Concepto de pruebas testing-concept

El concepto de prueba es la descripción de alto nivel de las pruebas del proyecto; incluye pruebas de QA, UAT, rendimiento, seguridad e integración.

Planes de pruebas testing-plans

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

Ámbito de pruebas testing-scope

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

Estrategia de pruebas testing-strategy

La estrategia de pruebas describe la estrategia de alto nivel para el control de calidad y las pruebas de aceptación del usuario. Esto incluye los plazos, la cadencia de creación de informes y la ejecución.

Concepto de integración de terceros third-party-integration-concept

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

Especificación de integración de terceros third-party-integration-specification

Los detalles de los requisitos (tanto funcionales como no funcionales) para la funcionalidad admitida y la integración de sistemas de terceros.

Concepto de seguridad de terceros third-party-security-concept

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 third-party-system-for-integration

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 third-party-systems-access-enabled

Se han concedido los derechos de acceso requeridos a las funciones respectivas utilizadas con los sistemas de terceros.

Concepto de pruebas de terceros third-party-testing-concept

Define lo siguiente:

Definición de umbral threshold-definition

Define los valores clave para monitorizar los puntos del sistema.

Por ejemplo:

Cronología e hitos timeline-and-milestones

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

Esfuerzos totales del proyecto total-project-efforts

Todas las estimaciones de esfuerzo, de cada uno de los responsables del proyecto, deben consolidarse; esto incluye gastos generales, desarrollo, ingeniería de sistemas, arquitectura y esfuerzos de pruebas.

Si el acuerdo incluye un nivel de asistencia, también deben incluirse los esfuerzos de asistencia y operaciones.

Materiales de formación training-materials

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

Conocimiento del ámbito del proyecto y las expectativas understands-scope-of-project-and-expectations

El perfil adecuado debe confirmar que comprende a la perfección lo siguiente:

Concepto de gestión de URL url-handling-concept

El concepto de gestión de URL debe cubrir las funcionalidades de URL específicas de AEM, incluido lo siguiente:

El concepto también debería abarcar lo siguiente:

Casos de uso use-cases

Un caso de uso es la lista de acciones o pasos de evento necesarios para lograr un objetivo. Por lo general, 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 use-cases-converted-into-test-scenarios

Los escenarios de prueba se basan en los casos de uso técnicos y empresariales. Se utilizan para probar que el comportamiento de la solución es el esperado.

Guías de usuario user-guides

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

Plan presupuestario validado validated-budget-plan

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 la creación de informes de presupuesto.

Resultados de la prueba de caja blanca white-box-test-results

La prueba de caja blanca 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 caja blanca se puede aplicar en los niveles de unidad, integración y sistema del proceso de pruebas de software.

Especificaciones del flujo de trabajo workflow-specifications

Basadas en el concepto de flujos de trabajo, estas especificaciones deben definir, en detalle, los pasos que conforman el flujo de trabajo completo.

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

Concepto de flujos de trabajo workflows-concept

Los flujos de trabajo permiten automatizar las actividades de AEM. El concepto de flujos de trabajo describe lo siguiente: