Glosario glossary
Este glosario enumera (alfabéticamente) los detalles de todos los documentos entregables de la Lista de comprobación de proyectos.
Aceptación de las partes interesadas acceptance-from-business-stakeholders
La aceptación por parte de las partes interesadas de la empresa confirma que, como partes interesadas clave, están alineadas con la solución y han dado su aprobación en cuanto a la forma en que los requisitos comerciales satisfacen el caso empresarial.
Pruebas de aceptación acceptance-tests
La prueba de aceptación se realiza cuando una aplicación está lista para la producción. Las pruebas las realiza un grupo que representa los distintos tipos de usuario final, utilizando escenarios de vida real.
Las pruebas de aceptación se utilizan para confirmar que:
- Project cumple los requisitos del cliente.
- La solución es adecuada para su uso.
- Los usuarios aceptan la solución y pueden pensar en trabajar con ella.
- El cliente acepta el proyecto.
Cuanto antes planifique y diseñe las pruebas de aceptación, más fácil será la implementación final. Deben definirse junto con el cliente y su equipo de garantía de calidad.
Aunque es posible que no pueda definir todos los detalles al inicio del proyecto, las definiciones iniciales deben discutirse y acordarse. Las pruebas de aceptación se basarán probablemente en los requisitos fundamentales (funcional y de rendimiento).
Acceso al sistema de prueba coordinado access-to-test-system-coordinated
Asegúrese de que los niveles requeridos de acceso al sistema se hayan concedido a todas las funciones.
Lista de comprobación de seguridad de Adobe adobe-security-checklist
La variable Lista de comprobación de seguridad de Adobe es la lista de comprobación oficial que se proporciona para garantizar que AEM es seguro en la instalación. Contiene las medidas de seguridad y los pasos de verificación que debe realizar para garantizar la integridad de su instancia.
Configuración del proyecto del portal de soporte de Adobe adobe-support-portal-project-set-up
El portal de soporte 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.
Pueden registrarse los detalles; por ejemplo, acerca de las tecnologías y versiones implementadas. Proporcionan transparencia entre el cliente y el Adobe.
Capacitación del administrador AEM aem-administrator-training
Capacitación para el personal administrativo de la solución. Consulte la Servicios de formación de Adobe para obtener más información.
Formación de autores de AEM aem-author-training
Capacitación para el personal que producirá (creará) contenido para la solución. Consulte la 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 la persona adecuada esté registrada para tomar el exámenes de certificación.
AEM certificado aem-certified
Asegúrese de que la persona adecuada haya pasado el exámenes de certificación.
AEM formación técnica aem-technical-training
Proporcionar formación técnica a la persona adecuada; 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 los objetivos y metas de la organización. Una vez que una organización ha analizado su misión y definido sus objetivos, debe medir los progresos en el logro de esos objetivos. Los KPI proporcionan un mecanismo de medición.
Alinear KPI de rendimiento y negocios align-business-and-performance-kpis
La alineación de los indicadores clave de rendimiento (KPI) clave de rendimiento (de su negocio y rendimiento) ayuda a unir todas las personas y procesos involucrados desde la organización. Esto a su vez ayuda a reducir la cantidad de tiempo y esfuerzo necesario para lograr los objetivos comerciales y cumplir el propósito propuesto.
Alineación de la arquitectura de contenido con KPI alignment-of-content-architecture-with-kpis
Asegúrese de que la arquitectura de contenido propuesta esté alineada con los indicadores de rendimiento clave (KPI) relevantes.
Alineación de la hoja de ruta del cliente con la línea de tiempo del proyecto alignment-of-the-customer-roadmap-with-project-timeline
La hoja de ruta del cliente consta de hitos de alto nivel y objetivos comerciales. El calendario del proyecto debe adherirse a esta estrategia y ajustarse a ella, por lo que se deben resaltar y rastrear todos los riesgos potenciales y/o las posibles desviaciones.
Definición de la arquitectura de las aplicaciones application-architecture-definition
La variable arquitectura de aplicaciones debe definir claramente el comportamiento de las solicitudes propuestas.
Se centra en:
- Cómo interactuarán entre ellos y con los usuarios.
- Los datos que deben ser consumidos y producidos por las aplicaciones, en lugar de su estructura interna.
Tareas de mantenimiento específicas de la aplicación definidas 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 necesite ejecutarse para el mantenimiento continuo de la solución.
Personal debidamente capacitado appropriately-trained-staff
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:
-
al menos un desarrollador de posibles clientes certificado AEM
-
al menos un arquitecto AEM certificado
-
al menos el 75 % de los desarrolladores AEM certificados;
esto permite a los desarrolladores certificados asesorar a los desarrolladores junior y garantiza el intercambio de conocimientos y la transparencia
Diagrama de arquitectura architecture-diagram
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 architecture-draft
Esto proporciona una visión de alto nivel de la arquitectura del sistema y de la solución. En esta etapa se trata de un proyecto que será revisado y perfeccionado en etapas posteriores.
Inicio de sesión de la tarjeta de revisión de arquitectura architecture-review-board-sign-off
La Junta de Revisión de la Arquitectura es un órgano interinstitucional que:
- supervisa la aplicación de una estrategia coherente
- garantiza el cumplimiento de normas en los sistemas
La junta de examen debería ser representativa de todos los principales interesados que participan en la arquitectura. Generalmente, se compondrán de un grupo de ejecutivos responsables de la revisión y el mantenimiento de la arquitectura general.
Grupo de pruebas automatizado adaptado para contenido real y resultados comparado con KPI automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis
Secuencias de comandos de automatización y casos de uso automatizados básicos:
- adaptado al contenido de producción
- comprobada con los KPI
Estrategia de pruebas automatizadas automated-testing-strategy
Esta estrategia define un marco para secuencias de comandos automatizadas reutilizables, junto con el enfoque planificado por el equipo de garantía de calidad (control de calidad). Describe el plan general de pruebas de automatización para garantizar:
- un mayor rendimiento de la inversión (ROI)
- más cobertura de prueba
- mayor fiabilidad de las pruebas con repetición de calidad
Estrategia de prueba automatizada validada frente a la 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 haya en 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; incluido:
- frecuencia
- herramientas que se van a utilizar
- entornos que se implementarán en
Consciente del Plan de Comunicación aware-of-communication-plan
Todo el equipo del proyecto y todas las partes interesadas deben confirmar que son conscientes de lo siguiente:
- estructura de informes
- cadencia de informes
- canales de comunicación
Conocimiento de los criterios y las definiciones de éxito aware-of-success-definitions-and-criteria
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 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 restauración y copia de seguridad de la empresa lo requiere.
Copia de seguridad y restauración probadas backup-and-restore-tested
Una prueba completa de extremo a extremo basada en el concepto de backup y restore.
Caso o empresarial business-case-s
Un documento de caso empresarial presenta los argumentos relacionados con la adopción de la acción, la adopción de una acción alternativa (si está disponible) o la no adopció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 en todos los casos.
Un documento de viabilidad debería ser una definición clara de todas las opciones, y concluir con un argumento convincente para la aplicación de la solución propuesta.
Business Analyst comprende el alcance del proyecto y las expectativas business-analyst-understands-scope-of-project-and-expectations
El analista empresarial debe confirmar que comprende plenamente:
- el ámbito del proyecto
- todas las expectativas de los clientes
- que esta es la base de todas las decisiones tomadas por persona, por fase en el proyecto
KPI empresariales business-kpis
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 empresariales clave. Es importante elegir los KPI adecuados para su negocio o escenario con definiciones claras de cuáles son, cómo se medirán, cómo se utilizarán y quién los usará.
Documentación de requisitos comerciales business-requirements-documentation
Un documento de requisitos comerciales (BRD) detalla la solución comercial para un proyecto, proporcionando una especificación clara de las necesidades y expectativas del negocio 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 BRD debería responder a la pregunta: "¿Qué quiere hacer el negocio?"
Inicio de sesión empresarial en cualquier ajuste necesario a 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 del riesgo y de pruebas de penetración pueden producir problemas y resultados que deben abordarse en la arquitectura o el desarrollo de la solución.
Los ajustes resultantes de estos procesos deben ser examinados y aprobados por la empresa y evaluados 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 ser compatible con los KPI de rendimiento.
Por ejemplo, elementos como imágenes, javascript y otros archivos de servidor se pueden almacenar en caché para mejorar el rendimiento de una solución.
Directrices de codificación coding-guidelines
Las Directrices de codificación definen los principios básicos a los que los desarrolladores deben adherirse al desarrollar la solución. Pueden incluir, entre otros:
- convenciones de nomenclatura
- uso del servicio
- uso de la biblioteca
Comunicar operaciones manualmente communicate-operations-manual
Asegúrese de que todas las personas o funciones apropiadas hayan recibido el Manual de operaciones.
Comunicar informe de prueba de rendimiento communicate-performance-test-report
Asegúrese de que todas las personas o funciones apropiadas hayan recibido el informe de prueba de rendimiento.
Comunicar notas de la versión communicate-release-notes
Asegúrese de que todas las personas o funciones apropiadas hayan recibido las Notas de la versión.
Comunicar ámbito y expectativas al equipo communicate-scope-and-expectations-to-team
Asegúrese de que el equipo del proyecto conoce plenamente el alcance del proyecto y las expectativas de su ejecución, y de que está alineado con él.
Comunicar materiales de formación y guías del usuario communicate-training-materials-and-user-guides
Asegúrese de que todas las personas o funciones apropiadas reciban el material 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 todos los requisitos de seguridad del cliente estén implementados.
Cumplimiento con el concepto de seguridad compliance-with-security-concept
Asegúrese de que el Concepto de seguridad esté establecido.
Concepto de relación de componentes y plantillas components-and-templates-relationship-concept
Esquema de las plantillas y los componentes que se utilizarán en la nueva aplicación. Incluye detalles como reglas de herencia, permisos y relaciones, entre otros.
Especificación de relación de componentes y plantillas 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 de maquetas de interfaces externas concept-for-mock-ups-of-external-interfaces
Concepto de cómo desarrollar y probar cualquier interfaz externa que pueda no estar abierta/disponible para los entornos de desarrollo o prueba.
Planifique/implemente maquetas de estas interfaces para garantizar que las pruebas estén lo más cerca posible del comportamiento similar a la producción.
Documento de arquitectura de contenido content-architecture-document
Documentación de la arquitectura propuesta del contenido. Los detalles deben incluir, entre otros:
- árbol de contenido
- etiquetado de conceptos
- estrategias para la reutilización de contenido
Contenido validado para migración content-validated-for-migration
El contenido del sistema heredado se revisa y el contenido seleccionado se valida para su migración a la nueva solución.
Borrador de contrato contract-draft
Proyecto inicial del contrato jurídico.
Estructura y formato del contenido actual current-content-structure-and-format
Documentación de la arquitectura de contenido y el formato actuales. Se utilizará para generar la arquitectura de contenido futura. También se utilizará para el concepto de migración.
Política de copia de seguridad y restauración del cliente customer-backup-and-restore-policy
Políticas del cliente relativas a:
- procesos de backup tanto para los datos como para la solución
- almacenamiento de la copia de seguridad
- confirmación de que la copia de seguridad está funcionando según lo esperado
- restauración, en caso de fallo
Directrices de codificación del cliente customer-coding-guidelines
Cualquier guía o requisito del cliente sobre cómo se debe realizar el desarrollo.
Políticas de implementación/versión del cliente customer-deployment-release-policies
Políticas del cliente que definen cómo y cuándo se pueden realizar implementaciones/versiones.
A menudo incluyen plazos, programación y requisitos de cierre de sesión.
Políticas o requisitos de supervisión del cliente customer-monitoring-policies-or-requirements
Políticas y requisitos del cliente sobre lo que debe monitorizarse. Se suman a las recomendaciones especificadas en el concepto de supervisión.
Programación de versiones de producción de clientes customer-production-release-schedule
La programación que define el cliente para las versiones en los entornos de producción.
Políticas y requisitos de informes del cliente customer-reporting-policies-and-requirements
Cualquier política o requisito que el cliente tenga con respecto a la creación de informes. Estas pueden incluir:
- la frecuencia con la que se deben enviar informes específicos
- el formato para informes específicos
- requisitos especiales
Hoja de ruta del cliente customer-roadmap
Formular una hoja de ruta de los principales hitos que deben implementarse, tanto tecnológicos como empresariales. Esta hoja de ruta se comunica al cliente.
Políticas de seguridad del cliente customer-security-policies
El cliente (el negocio y TI) tendrá políticas que definen los niveles de seguridad requeridos para la solución. Estas pueden incluir:
- Requisitos para aprobar una evaluación del riesgo.
- Requisitos para pasar pruebas de penetración.
- Cualquier requisito específico de seguridad; como la omisión de todos los campos de entrada, el uso del cifrado (SSL), los certificados y la autenticación y la sesión.
Directrices de especificación del cliente customer-specification-guidelines
Cualquier guía que tenga el cliente en relación con el formato, el envío y la firma de las especificaciones.
Informes de pruebas de cliente customer-test-reports
Informes del cliente al posible cliente durante la prueba 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:
-
AEM puede personalizarse para adaptarse a las necesidades del negocio. Cualquier personalización que pueda afectar a la actualización debe estar completamente documentada. Por ejemplo, cualquier cambio importante en la interfaz de usuario (IU) de AEM.
-
Las actualizaciones necesarias para la solución actual deben estar completamente documentadas; pueden incluir:
- paquetes fijos acumulativos (CFP)
- service packs (SP)
- correcciones
- actualizaciones
Informe de prueba de aceptación diaria de usuario daily-user-acceptance-test-report
Informes o reuniones resultantes de la prueba de aceptación del usuario (UAT). Deben detallar:
- los problemas notificados
- priorización de estas cuestiones
Seguridad predeterminada habilitada default-security-enabled
Asegúrese de que la configuración de seguridad predeterminada para AEM se haya habilitado o implementado.
Políticas y procesos de implementación/versión deployment-release-policies-and-processes
Políticas formalizadas que abarcan tanto la implementación como las versiones del proyecto. Estas pueden incluir:
- tiempo para versiones
- planificación de vacaciones
- frecuencia
- y pueden depender del entorno en cuestión
Nivel de implementación establecido deployment-cadence-established
Defina la frecuencia necesaria de implementaciones en todos los 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 fases (o etapas) distintas, cada una con actividades diferentes. 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 el equipo del proyecto crea y completa para desarrollar o mantener la aplicación.
Definición de función de desarrollo development-role-definition
Defina qué desarrollador y/o función está ejecutando pruebas de TI (rendimiento u otras) y/o unidades 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.
El equipo de desarrollo comprende el alcance del proyecto y las expectativas development-team-understands-scope-of-project-and-expectations
El equipo de desarrollo debería confirmar que comprende plenamente:
- el ámbito del proyecto
- todas las expectativas de los clientes
- que esta es la base de todas las decisiones tomadas por persona, por fase en el proyecto
Especificación de los cuadros de diálogo dialogs-specification
Detalles sobre los cuadros de diálogo necesarios para la solución.
Configuración del entorno de desarrollo de documentos document-development-environment-setup
Documentación del entorno de desarrollo.
Configuración del entorno de producción de documentos document-production-environment-setup
Documentación del entorno de producción.
Configuración del entorno de prueba de documento document-test-environment-setup
Documentación del entorno de prueba.
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 de umbral y a qué niveles de rendimiento.
Prueba de durabilidad ejecutada durability-test-executed
Ejecución de las pruebas de durabilidad.
Concepto de administració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 separados para cada nivel de proyecto:
- Equipo del proyecto
- Cliente
- Adobe
Establecer sesiones regulares de revisión de la calidad establish-regular-quality-review-sessions
Establecer reuniones periódicas de examen de la calidad con los miembros del equipo correspondientes.
Estructura de permisos existente existing-permissions-structure
Documentación del conjunto existente de permisos y grupos definidos para la solución heredada o dentro de la organización.
Mapa de sistemas existente existing-systems-map
Un diagrama (o conjunto de diagramas) de los sistemas y dependencias existentes.
Definiciones y criterios de éxito previstos expected-success-definitions-and-criteria
El patrocinador del proyecto recopila las expectativas empresariales relacionadas con el éxito del proyecto. Es importante contar con todo el conjunto de expectativas disponibles al comienzo de un proyecto, ya que éstas deberían influir en todas las decisiones adoptadas a lo largo de la ejecución.
Las expectativas pueden incluir:
- KPI específicos, como el aumento porcentual de páginas servidas
- menor tiempo para publicar contenido
- objetivos de nivel superior, como una interfaz fácil de usar
Requisitos de los diseños de experiencia experience-designs-requirements
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 la experiencia experience-specifications
Detalles de los requisitos de diseño de experiencias.
Sistema externo y dependencias de usuario/contexto del sistema external-system-and-user-dependencies-system-context
Diagrama (o conjunto de diagramas) que describe el ecosistema completo de la solución. Debe incluir elementos como integraciones externas, interfaces, dependencias y redes.
Sistema y procedimiento de reserva fallback-system-and-procedure
La definición del sistema de reserva:
- las funcionalidades críticas para el negocio que deben seguir funcionando en caso de un fallo crítico
- los procesos necesarios en caso de reserva
Sistema de reserva y procedimiento probados fallback-system-and-procedure-tested
Prueba completa del sistema de reserva.
Cierre de sesión en el sistema de reserva de las partes interesadas del negocio fallback-system-sign-off-from-business-stakeholders
Firme, por parte de las partes interesadas del negocio, que el sistema de reserva y los procedimientos relacionados garantizarán las funcionalidades críticas del negocio.
Confirmación de viabilidad en KPI 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 respecto a los KPI para garantizar que se puedan cumplir.
Contrato finalizado finalized-contract
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 functionality-of-the-solution-accepted-by-stakeholders
Confirmación de que las partes interesadas aceptan plenamente lo siguiente:
- funcionalidad de la solución
- cualquier problema conocido en la solución
Ir a la programación en directo go-live-schedule
Cronología y programación de las actividades necesarias para:
- preparación para go live
- el lanzamiento real
Rutas felices definidas happy-paths-defined
Una ruta feliz es un escenario predeterminado sin condiciones excepcionales o de error. Se compone de la secuencia de actividades ejecutadas cuando todo funciona según lo esperado.
Estimaciones de hardware hardware-estimates
Estimaciones iniciales de:
- el hardware necesario para la instalación AEM básica
- cualquier requisito adicional, basado en el diseño de la solución de alto nivel
El hardware estará 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 los requisitos de alto nivel ofrece un desglose generalizado de los requisitos del sistema, que abarca aspectos como:
- Procesos empresariales
- Principales funciones 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 high-level-solution-design
El diseño de la solución de alto nivel explica la arquitectura que se utilizará para desarrollar la solución. El diagrama de arquitectura ofrece una visión general de todo el sistema, identificando los principales componentes que se desarrollarán para el producto y sus interfaces.
Mapa del sistema de alto nivel high-level-system-map
Este mapa del sistema debe proporcionar un diagrama de nivel muy alto del sistema. Difiere del contexto de solución en que es un mapa generalizado de todos los sistemas involucrados, no hay interfaces en este diagrama.
Estructura de contenido histórico historical-content-structure
Definición de la estructura de contenido del sistema heredado. Esto se utiliza como referencia y también al preparar la estrategia de migración.
KPI históricos de rendimiento y rendimiento histórico historical-performance-and-historical-performance-kpis
Debe recopilar y documentar estadísticas de rendimiento y KPI de rendimiento del sistema heredado. A continuación, se utilizan como punto de referencia y para establecer referencias de la nueva solución.
Identificar soluciones y funcionalidades clave críticas identify-critical-key-solutions-functionalities
Una lista de las funcionalidades críticas para el negocio.
Implementación: cambios basados en los resultados de la prueba de penetración implementation-changes-based-on-penetration-test-results
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 prueba automatizada 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, etiquetado de conceptos y reutilización de contenido.
Implementación: diseño de experiencia implementation-experience-design
Implementación de los requisitos para admitir el diseño de Experience Cloud.
Implementación: sistema de reserva y procedimientos implementation-fallback-system-and-procedures
Aplicación del sistema de reserva y procedimientos conexos.
Implementación: integración implementation-integration
Implementación de integraciones con todos los sistemas externos necesarios.
Implementación - Estrategia de migración implementation-migration-strategy
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 las aplicaciones de software.
Implementación: Concepto de seguridad de la arquitectura del sistema implementation-system-architecture-security-concept
Implementación de la seguridad del sistema.
Implementación: administració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 aplicación proporciona los principios rectores para toda la aplicación. Debe tenerse en cuenta:
- Operaciones
- Mantenimiento
- Compatibilidad
- Reutilización
- Seguridad
- Escalabilidad
Este concepto también puede esbozar los marcos, bibliotecas y otros artefactos utilizados en la solución.
Informar al Adobe de asistencia sobre la programación Go Live inform-adobe-support-about-the-go-live-schedule
Póngase en contacto con el servicio de asistencia al Adobe para asegurarse de que cualquier asistencia que sea necesaria se pueda habilitar durante el lanzamiento.
Diseños de experiencias iniciales initial-experience-designs
Conceptos preliminares para el diseño de las experiencias.
Pruebas de integración integration-testing
Prueba y 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
Los procesos claros registran todas las cuestiones encontradas y hacen un seguimiento de las actividades en curso con el fin de garantizar que se aborden todas las cuestiones.
Sistema y procesos de seguimiento de problemas issue-tracking-system-and-processes
Un sistema de seguimiento, junto con los procesos necesarios, para registrar todas las cuestiones encontradas y realizar 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 issue-tracking-system-process-is-set-up-and-integrated
La herramienta seleccionada está totalmente integrada y el acceso se concede 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 aplicaciones 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 van a utilizar list-of-development-tools-to-be-used
a) Una descripción de los instrumentos que se utilizarán en la aplicación; las herramientas deben incluir:
- herramientas de documentación
- herramientas de seguimiento de problemas
- herramientas de implementación
- herramientas de creación
Lista de usuarios que requieren acceso al portal de soporte de Adobe list-of-users-that-require-access-to-adobe-support-portal
Una lista de todos los usuarios y funciones que necesitarán acceso al Portal de Soporte de Adobe.
La lista está formada normalmente por el arquitecto de soluciones y/o el personal de TI del cliente.
Análisis de archivos de registro log-file-analysis
Un análisis, junto con las recomendaciones resultantes, que define lo que debe registrarse para monitorizar la solución:
- actividades que se van a registrar
- nivel de granularidad
- información registrada para cada actividad
Tareas de mantenimiento (AEM específicas) probadas y habilitadas maintenance-tasks-aem-specific-tested-and-enabled
Pruebe y habilite AEM tareas de mantenimiento como:
- compactación
- sistema limpio
- depuración de flujo de trabajo
Plan de migración migration-plan
Documentar la migración; incluido
- cronología de la migración
- plan de mantenimiento de contenido, según la estrategia de migración
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:
- detalles técnicos de la migración automatizada si es posible
- pruebas de humo que se deben realizar después de la migración para validar el contenido migrado
También debería recomendar cómo mantener el contenido actualizado (o lo más actualizado posible) durante el periodo entre la migración y el lanzamiento real del nuevo sistema. Esto podría significar una congelación de contenido, una doble publicación o el mantenimiento de un sistema alfa.
Monitorización: CPU monitoring-cpu
Monitorización del uso de la CPU del sistema por parte de la solución:
- media
- picos
Monitorización: E/S de disco monitoring-disk-i-o
Monitorización de las tasas de entrada y salida de disco de la solución:
- media
- picos
Monitorización: espacio en disco monitoring-disk-space
Monitorización del uso del espacio en disco por parte de la solución:
- media
- crecimiento con el tiempo
Debe controlar el uso de:
- el repositorio
- archivos de registro
Monitorización - Sistema(s) externo(s) monitoring-external-system-s
Monitorice las conexiones entre la solución y los sistemas externos:
- tasa de tráfico
- picos
- estabilidad
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:
- tasa promedio de tráfico
- picos
- estabilidad
Monitorización: solicitudes monitoring-requests
Monitorice las solicitudes realizadas a la solución.
Supervisión: puntos de seguridad monitoring-security-points
Monitorizar en los puntos de seguridad definidos.
Monitorización - Sistema monitoring-system
Monitorizar el sistema general; por ejemplo:
- disponibilidad
- rendimiento promedio
- picos de rendimiento
- alertas
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; incorporando:
- AEM monitorización estándar
- supervisión del sistema
- requisitos de monitorización específicos del cliente
Monitorización de los puntos débiles potenciales monitoring-potential-weak-points
Se deben identificar y definir puntos específicos que podrían ser susceptibles de fracaso. También debe definirse cualquier tarea de supervisión relacionada con estas.
Algunos ejemplos son (entre otros):
- flujos de trabajo clave
- procesamiento de transacciones
- puntos de integración
Política de monitorización comunicada al ingeniero del sistema monitoring-policy-communicated-to-system-engineer
Garantizar que los ingenieros de sistemas y el personal de operaciones conozcan y comprendan cualquier política de supervisión.
Monitorización de informes: estructura implementada monitoring-reports-structure-in-place
Definir:
- cuándo se deben generar los informes de monitorización
- a los que deben entregarse
Documentación de tareas operativas operational-tasks-documentation
Todas las tareas operacionales documentadas, con su frecuencia definida.
Manual de operaciones operations-manual
Manual que proporciona toda la información necesaria para el correcto funcionamiento y mantenimiento de la solución:
- todas las tareas operativas
- contactos clave
- planes de implementación
- listas de comprobación previas/posteriores a la implementación
- cualquier otra tarea crítica
También debe detallar los conceptos de implementación para:
- cumplir los KPI de rendimiento
- escalar la solución para seguir cumpliendo estos KPI
Paquete preparado package-prepared
Paquete de software creado y entregado listo para la implementación.
Pruebas de penetración penetration-tests
Una prueba de penetración (conocida informalmente como prueba de pluma) es un ataque a un sistema informático que busca debilidades de seguridad y que potencialmente obtiene acceso a las características y datos del equipo.
Pruebas de penetración: aprobadas penetration-tests-passed
Se pasan todos los criterios necesarios.
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 performance y escalabilidad performance-and-scalability-concept
Documento conceptual sobre cómo garantizar que la implementación cumpla los KPI de rendimiento y cómo escalar la solución para que siga cumpliendo esos KPI.
Prueba comparativa de rendimiento performance-benchmark
El indicador de rendimiento se utiliza para definir pruebas de rendimiento, pruebas de durabilidad y 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 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 la consulta de la base de datos.
Pruebas de rendimiento: informe performance-tests-report
Informes creados para la empresa, que 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 prueba basada en el personal persona-based-testing-concept
Las pruebas basadas en personalidades son un método basado en las distintas personalidades que se describen en los diseños de experiencia. También prueba las cuentas y sus niveles de permisos relacionados.
Esto se utiliza a menudo en la prueba de aceptación de usuarios (UAT).
POC probado y verificado con respecto a la documentación de requisitos poc-tested-and-verified-against-requirement-documentation
La prueba de concepto (POC) se evalúa en función de los requisitos para garantizar que ambos se ajusten.
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. A continuación, se utiliza 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 en su lugar.
Cierre de producción de las partes interesadas del negocio production-sign-off-from-business-stakeholders
Antes de Go Live en el entorno de producción, se debe conceder la desactivació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 desactivación se proporciona como parte de la programación Go Live.
Proceso y política de cierre de sesión de producción production-sign-off-process-and-policy
La política y el proceso necesarios para obtener el inicio de sesió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 del negocio como para el equipo del proyecto.
Esfuerzos del proyecto: estimaciones finales project-efforts-final-estimates
La variable estimaciones iniciales fueron de alto nivel y se realizaron de acuerdo con los requisitos de alto nivel para la implementación.
Ahora se examinan, perfeccionan y amplían para proporcionar las estimaciones finales. Las estimaciones deben ser proporcionadas por cada jefe de proyecto apropiado, incluida la gestión de proyectos, la consultoría, la arquitectura, las pruebas y el desarrollo.
Estas estimaciones se utilizan para la asignación de recursos y la presupuestación.
Esfuerzos del proyecto: estimaciones iniciales project-efforts-initial-estimates
Las estimaciones iniciales son de alto nivel y se realizan de acuerdo con las necesidades de alto nivel para la aplicació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 estructura de informes del proyecto y el equipo.
A menudo adopta el formulario o incluye un gráfico para presentar una visión general de las líneas de tiempo y 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:
- Objetivos específicos del proyecto
- Deliverables
- Características
- Funciones
- Tareas
- Plazos
- Esfuerzo planificado
Abarca lo que debe lograrse, junto con la labor que debe realizarse, para ejecutar el proyecto
Informes de estado del proyecto dentro de una secuencia definida project-status-reports-within-a-defined-cadence
Los informes sobre el estado del proyecto se entregan de acuerdo con la programación acordada y con el formato requerido.
Prueba de concepto (POC) proof-of-concept-poc
La Proof of Concept (POC) implementa una gama limitada de funciones para la solución.
El objetivo debe ser demostrar la viabilidad de la solución, verificar que pueda cumplir el objetivo requerido y demostrar que existe el potencial de que se utilice.
Purgar reglas purge-rules
AEM mantiene varias versiones de recursos y contenido. Las reglas de depuración están diseñadas y configuradas para eliminar periódicamente las versiones anteriores con el fin de mantener el estado y el tamaño del repositorio.
Formato y jerarquía del informe de calidad quality-report-format-and-cadence
Defina el contenido y el formato requeridos para el informe de calidad, junto con la frecuencia con la que debe enviarse.
Versión coordinada release-coordinated
El administrador de proyectos coordina todas las funciones necesarias para la versión en 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 deberían cubrir:
- requisitos previos
- requisitos incluidos
- problemas resueltos
- problemas conocidos en la versión
Se utiliza con Runbook para ejecutar pasos y comprobaciones previos y posteriores a la instalación.
Versión ejecutándose en el entorno de producción release-running-on-production-environment
Lanzamiento final y activo en producción.
Condiciones del contrato pertinentes relevant-contract-terms
Debe destacar las condiciones contractuales específicas que son relevantes para la implementación del proyecto; como hitos contractuales, períodos de factura o requisitos de personal.
Cadenas de informes reporting-cadence
Junto con el cliente, defina la frecuencia de los informes que se les 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 ha establecido una estrategia de optimización para eliminar los datos obsoletos.
Solicitud de configuración de la sección Proyecto en el portal de soporte de Adobe request-for-setting-up-project-section-in-adobe-support-portal
La solicitud oficial para configurar su proyecto en el portal de soporte de Adobe.
Documentación de requisitos requirements-documentation
Este conjunto de documentación abarca las necesidades funcionales y no funcionales, junto con las actividades estimadas.
Recursos disponibles para la asistencia Go Live resources-available-to-support-go-live
Asegúrese de que todas las funciones necesarias para la puesta en marcha estén dotadas de personal y disponibles.
Evaluación de riesgos risk-assessment
La evaluación de riesgos es ejecutada por los departamentos de TI y/o Seguridad del cliente.
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 risk-mitigation-plan
El Plan de Mitigación de Riesgos incluye la Evaluación de Riesgos. Juntos cubren:
- riesgos identificados
- posibles soluciones a estos riesgos si surgen en la aplicación
Expectativas de ROI roi-expectations
Defina las expectativas de retorno de la inversión (ROI) que están vinculadas 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 roles-and-rights-concept
Especificación detallada de los conceptos relacionados con las funciones y los derechos de acceso necesarios para la nueva aplicación, incluida una descripción general de alto nivel de:
- roles
- grupos
- usuarios
- permissions
- así como la administración y el aprovisionamiento de usuarios
El concepto de funciones y derechos cumple las directrices de seguridad roles-and-rights-concept-meets-security-guidelines
Examen del concepto de funciones y derechos para garantizar que cumple las políticas de seguridad.
Especificación de funciones y derechos roles-and-rights-specification
Una especificación detallada basada en el concepto de funciones y derechos.
Arquitectura de seguridad Recommendations security-architecture-recommendations
Recommendations está relacionado con la seguridad para la arquitectura de software y hardware.
Directrices de codificación basadas en seguridad security-based-coding-guidelines
Estas directrices definen cómo se debe hacer 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 security-checklist
Lista de comprobación específica del proyecto de elementos, basada en el Concepto de seguridad junto con cualquier política adicional necesaria para garantizar el cumplimiento de la solución.
A menudo, esto también se incluye como parte de los pasos posteriores a la implementación en el runbook.
Concepto de seguridad security-concept
Defina y documente los detalles de la configuración de seguridad necesaria para la aplicación, la arquitectura y la infraestructura.
Borrador de concepto de seguridad security-concept-draft
Un esquema de alto nivel que cubre la configuración de seguridad del:
- aplicación
- arquitectura
- infraestructura
Problemas de seguridad enumerados y evaluados security-issues-listed-and-assessed
Todas las cuestiones de seguridad de la solución enumeradas y evaluadas; incluidas las estimaciones de esfuerzo.
Cierre de sesión de seguridad de las partes interesadas del negocio security-sign-off-from-business-stakeholders
Cierre la sesión de las partes interesadas para asegurarse de que la implementación de seguridad cumple con las políticas y expectativas.
Configuración de procesos de asistencia set-up-support-processes
Establezca los procesos de soporte requeridos en su lugar.
SLAs para sistemas de terceros slas-for-third-party-systems
Garantizar que los Acuerdos de nivel de servicio (SLA) estén disponibles y se comuniquen a los equipos de desarrollo y operaciones para su uso durante la implementación y el soporte.
Concepto de prueba de humo 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 las operaciones básicas y la funcionalidad 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 smoke-tests-executed-for-system-validation
Las pruebas de humo deben ejecutarse en todos los sistemas para garantizar el correcto funcionamiento de la funcionalidad básica de la solución durante la instalación o la implementación en cualquier entorno.
Estrategia de arquitectura de software software-architecture-strategy
La estrategia de alto nivel para la arquitectura del software; incluidos servicios, servlets, marcos y otras decisiones de implementación.
Establecimiento de la Junta de Revisión de Soluciones y Conjunto de Cadenas de Reunión solution-review-board-established-and-meeting-cadence-set
La Junta de Revisión de Soluciones suele estar compuesta por partes interesadas del cliente.
La junta celebra reuniones periódicas para examinar de forma continua los requisitos y especificaciones pertinentes actualmente previstos. El objetivo es asegurar la armonización con la definición y los criterios de éxito y también aportar contribuciones al desarrollo de los requisitos.
Runbook de soluciones solution-runbook
Instrucciones de instalación para la solución, junto con tareas operativas básicas que deben ejecutarse en la instalación.
Proceso de desactivación y aceptación de la solución solution-sign-off-and-acceptance-process
El proceso de firma y aceptación describe los criterios que deben cumplirse antes de que la solución pueda liberarse en un entorno productivo.
También puede servir de hito contractual.
Concepto de funcionalidad especial special-functionality-concept
El concepto inicial para cualquier funcionalidad especial que se considere fuera del alcance normal de desarrollo en la plataforma AEM.
Especificación de funcionalidad especial special-functionality-specification
Detalles de cualquier funcionalidad especial que se considere fuera del alcance normal de desarrollo en la plataforma AEM.
Directrices de especificación specification-guidelines
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 specification-review-and-approval-process-defined-and-communicated
Debe establecerse un proceso claro para la firma de las especificaciones por parte del cliente. Este proceso garantiza la claridad y la firmeza del ámbito de aplicación de los requisitos.
Personal seleccionado para AEM capacitación de administrador staff-selected-for-aem-administrator-training
Personal interno que necesitará capacitación para administrar la solución.
Personal seleccionado para formación de autor y usuario final staff-selected-for-author-and-end-user-training
Personal interno que necesitará capacitación para crear la solución.
Partes interesadas stakeholders
Las partes interesadas son las personas clave y/o las funciones 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 stakeholders-are-aware-of-success-definitions-and-criteria
Confirmación de que todos los interesados fuera del equipo de implementación real son conscientes de lo siguiente:
- definiciones de éxito
- criterios de éxito
Las partes interesadas comprenden el proyecto y las expectativas stakeholders-understand-project-and-expectations
Confirmación de que todas las partes interesadas fuera del equipo de implementación real están en armonía con el proyecto general y las expectativas, 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 clave de comunicación. El formato debe estar alineado con cualquier requisito de informe del cliente.
Criterios de éxito y definición success-criteria-and-definition
El cliente, el patrocinador del proyecto y el administrador o consultor del proyecto deben especificar:
- Lo que 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 cumplan los criterios de éxito:
- Como base para los KPI.
- Al tomar decisiones a lo largo de la implementación.
Compatibilidad con la validación de problemas notificados support-in-validation-of-reported-issues
Parte de las responsabilidades de los coordinadores de calidad son garantizar que haya recursos disponibles para apoyar a cualquier usuario en las pruebas. Por ejemplo, para ayudar al usuario a realizar pruebas, al crear informes de problemas y para ayudar a validar los problemas con el entorno de prueba.
Procesos de soporte y acceso al portal de soporte de Adobe support-processes-and-access-to-adobe-support-portal
El acceso al portal de soporte de Adobe es crucial para enviar tickets sobre 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 system-architecture-definition
Una propuesta inicial y una definición de la arquitectura para todos los entornos de la solución.
Documentación de arquitectura del sistema system-architecture-documentation
Un documento en el que se detalla la arquitectura del sistema; incluyendo interfaces, ubicación de red e integraciones para todos los entornos, entre otra información.
Concepto de seguridad de la arquitectura del sistema system-architecture-security-concept
Descripción general de cómo hacer que la arquitectura del sistema sea compatible con cualquier política de seguridad. Esto puede abarcar:
- cortafuegos y reglas de cortafuegos
- zonas de seguridad
- gestores de tráfico locales y generales
- servidores web
- proxies y proxies inversos
Factores de riesgo del sistema identificados y verificados system-risk-factors-identified-and-verified
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 implicado en cada
- junto con el esfuerzo estimado para cualquier cambio en la implementación que sea necesario hacer frente a ellos.
El equipo es consciente de los criterios y las definiciones de éxito team-is-aware-of-success-definitions-and-criteria
Confirmación de que todo el equipo es consciente de las definiciones y los criterios de éxito.
El equipo es consciente 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.
El equipo comprende el proyecto y las expectativas team-understands-project-and-expectations
Alineación con el proyecto general y las expectativas, tanto internas para el equipo del proyecto como para el cliente.
Requisitos técnicos technical-requirements
Estos requisitos son específicos de la implementación técnica de servicios que admiten la solución.
Factores de riesgo técnico verificados technical-risk-factors-verified
Identificar y verificar posibles riesgos técnicos. Los riesgos técnicos pueden incluir:
- ejecución en sitios cruzados
- campos de entrada orientados al usuario final
- infraestructura
- edad de la tecnología
- número de integraciones
- y dependencias
Especificación técnica technical-specification
La Especificación técnica abarca (entre otras informaciones):
- interfaces
- configuraciones
- API
- servicios compatibles con los requisitos de la solución
Especificación de plantilla template-specification
Las especificaciones de las plantillas requeridas. Estos deben cubrir detalles, incluidos parsys, el modelo y la asignación de herencia, entre otros.
Las especificaciones se basan en los requisitos empresariales y los requisitos de experiencia.
Casos de prueba test-cases
Casos de prueba específicos de los pasos detallados necesarios para ejecutar pruebas funcionales de la solución.
Probar contenido test-content
El contenido de prueba debe estar lo más cerca posible del contenido de producción. Debe tener una selección lo suficientemente amplia como para permitir probar todos los escenarios.
Entorno de prueba listo test-environment-ready
Asegúrese de que el entorno de prueba esté listo, con implementaciones automatizadas implementadas para garantizar que todo el código candidato a la versión esté actualizado para las pruebas.
Informes de prueba test-reports
Informes en los que se detallen los resultados de las pruebas; incluido:
- defectos elevados
- estado de los casos de prueba ejecutados
- otros temas relacionados con la calidad
Cabe señalar que:
- Se debe permitir que cualquier equipo de prueba permanezca neutral y ofrezca los resultados de la prueba.
- Corresponde al Administrador del proyecto evaluar las consecuencias de los resultados y decidir las medidas apropiadas.
Grupo de pruebas test-suite
Selección del conjunto de automatización y las herramientas. Se utilizarán para automatizar pruebas, incluidas las de casos de uso.
Grupo de herramientas de prueba seleccionado test-tooling-suite-selected
Grupo de automatización y herramientas seleccionadas para automatización de casos de uso y otras tareas de ejecución de pruebas.
Concepto de prueba testing-concept
El concepto de pruebas es el esquema de pruebas de muy alto nivel para el proyecto; incluye control de calidad, prueba de aceptación del cliente, rendimiento, seguridad y pruebas de integración.
Planes de prueba testing-plans
Estos planes describen en bueno detalle la realización de pruebas para cada fase de desarrollo y se basan en el Estrategia de prueba.
Ámbito de prueba testing-scope
Estos requisitos son específicos de la implementación técnica de servicios que admiten la solución.
Estrategia de prueba testing-strategy
La estrategia de pruebas describe la estrategia de alto nivel para la garantía de calidad y las pruebas de aceptación de los usuarios. Esto incluye las líneas de tiempo, la cadencia de informes y la ejecución.
Concepto de integración de terceros third-party-integration-concept
Concepto arquitectónico y de nivel de sistema para la integración con sistemas de terceros.
Especificación de integración de terceros third-party-integration-specification
Detalles de los requisitos (funcionales y no funcionales) para la funcionalidad y la integración compatibles de los 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 políticas 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
Derechos de acceso requeridos concedidos a las funciones respectivas utilizadas junto con sistemas de terceros.
Concepto de prueba de terceros third-party-testing-concept
Define:
- casos de uso para probar las integraciones
- funcionalidad relacionada con cualquier aplicación de terceros
Definición de umbral threshold-definition
Define los valores clave para los puntos de monitorización del sistema.
Por ejemplo:
- cuántos kilobytes (KB) de registros no enviados generan una advertencia en la instancia del servidor principal
- el número de milisegundos de retraso promedio por transacción que se toleran antes de que se genere una advertencia en el servidor principal
Línea de tiempo e hitos timeline-and-milestones
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.
Total de actividades de proyectos total-project-efforts
Deben consolidarse todas las estimaciones de esfuerzo, de cada uno de los posibles clientes del proyecto; incluidos, gastos generales, desarrollo, ingeniería de sistemas, arquitectura y pruebas.
Si se incluye un nivel de apoyo en el acuerdo, también deberían incluirse las actividades de apoyo y operaciones.
Materiales de formación training-materials
Material que se utilizará en las sesiones de formación. Los materiales deben crearse específicamente para la solución y diseñarse para utilizarse junto con las guías del usuario.
Comprender el alcance del proyecto y las expectativas understands-scope-of-project-and-expectations
La persona adecuada debe confirmar que comprende plenamente:
- el ámbito del proyecto
- todas las expectativas de los clientes
- que esta es la base de todas las decisiones tomadas por persona, por fase en el proyecto
Concepto de administración de URL url-handling-concept
El concepto de gestión de URL debe abarcar AEM funcionalidades de URL específicas, entre las que se incluyen:
- URL de vanidad
- externalización de vínculos
- páginas de error
- asignación
El concepto debería abarcar también:
- cualquier regla de reescritura
- hosts virtuales en el servidor web
- Consideraciones de SEO, como robots.txt
- mapa del sitio
Casos de uso use-cases
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 use-cases-converted-into-test-scenarios
Los escenarios de prueba se basan en los casos de uso técnico y empresarial. Se utilizan para comprobar que el comportamiento de la solución es el esperado.
Guías del usuario user-guides
Las guías del usuario proporcionan información y asistencia para los usuarios de la solución:
- autores
- usuarios de energía
- administradores
Plan presupuestario validado validated-budget-plan
Todos los interesados deben revisar y validar el plan presupuestario. Deben comprobar los detalles, como la facturación, las cantidades y los métodos/tiempos de presentación de informes del presupuesto.
Resultados de la prueba de la caja blanca white-box-test-results
La prueba de cuadro blanco es un método que prueba las estructuras internas o el funcionamiento de una aplicación, en lugar de su funcionalidad. La prueba de caja blanca se puede aplicar en los niveles de unidad, integración y sistema del proceso de prueba de software.
Especificaciones del flujo de trabajo workflow-specifications
Basándose en el concepto de flujos de trabajo, estas especificaciones deben definir, en detalle, los pasos que permitirán crear el flujo de trabajo completo.
La especificación de cada flujo de trabajo debe incluir (como mínimo):
- caso de uso
- roles
- pasos
- resultados
- gestión de errores
Concepto de flujos de trabajo workflows-concept
Los flujos de trabajo permiten automatizar AEM actividades. El concepto de flujos de trabajo describe:
- los procesos que necesitarán automatización
- los servicios y funciones de AEM que se verán afectados