El objetivo de este artículo es mostrar los documentos que se generan durante el ciclo de vida de un proyecto de IT, y que pueden formar parte del Test Basis para la planificación y realización de las pruebas de Testing y Validación, indicando las características principales de estos documentos y la fase del proyecto en la que se generan.
La documentación del Ciclo de vida de un proyecto de IT y el Test Basis
Aquellos que se dedican a planificar, desarrollar o gestionar un proyecto de testing en el ámbito de IT saben que el llamado genéricamente “Test Basis” es un elemento fundamental que determina cómo se materializará el testing, sus características y sus elementos. El test basis nos ha de servir para conocer cuáles son los elementos críticos de un sistema o servicio, y esta criticidad determinará a su vez la profundidad o intensidad con la que hemos de evaluar un componente o una característica de dicho sistema o servicio. Asimismo este “test basis” condiciona el tipo de técnicas y métodos que podemos emplear para elaborar nuestras pruebas (test cases).
La definición estándar de Test Basis es la de aquel conjunto de información, es decir el conjunto de documentos, del cual podemos en primer lugar inferir o extraer los requerimientos (de usuario, técnicos, normativos, etc) de un sistema o servicio que han de ser verificados mediante el proceso de testing, y en segundo lugar determinar la criticidad o prioridad de los elementos del sistema/servicio y por tanto la dedicación con la que cada elemento ha de ser comprobado.
Los casos de test, y los datos que se emplearán para la ejecución de los tests, entre otros aspectos del proceso de testing, dependen necesariamente del Test Basis del cual dispongamos.
Al mismo tiempo, el llamado Test Level (de componente, de sistema, de integración, de aceptación, …) determina o requiere idealmente diferentes tipos de documentación.
Un ejemplo de la relación entre la documentación disponible, generada durante el desarrollo del proyecto, y los tipos de test que se pueden llevar a cabo (relacionados a su vez con el Test Level), se puede ver en la tabla siguiente.
| Tipo de Test |
Documento del Test Basis |
Test level |
| Accesibilidad | FS, SIPOC | FAT, GAT |
| Alpha | Business Cases, URS | AT |
| Back-to-back testing | FS | ST, FAT |
| Back-to-front | Risk Assessment | ST, PAT |
| Backup & restore | Risk Assessment, Contingency Plan | PAT |
| Batches | FS | ST, FAT, GAT |
| Beta, field | URS, Business Cases, SOPs, SLE | AT |
| Big-bang (integración) | DS, FS, Technical Architecture | UIT, SIT |
| Boundary testing | FMEA, FRA, FS | UT, ST, FAT |
| Business continuity and disaster recovery | Service Availability Plan, Contingency Plan, Risk Assessment | |
| Capacidad | Service Capacity Plan, Service Availability Plan, Technical Architecture Def | PAT |
| Carga | Service Capacity Plan, Service Availability Plan, FRA | GAT, PAT |
| Casos de uso | URS, Business Cases, SOPs, SIPOC | ST |
| Compatibilidad | Deployment Plan, SLE, Service Definition, Technical Architecture, Migration Plan, Decomission strategy | |
| Conectividad | Technical Architecture Def., Production Support Plan, Deployment Plan | UIT, ST, FAT, PAT |
| Configuración | DS, Operational Handbook, Technical Architecture Def. | ST, FAT |
| Continuidad | Service Availability Plan, Contingency Plan, Risk Assessment | PAT |
| Conversion | Migration Plan, URS, FS | ST, FAT, GAT |
| Disponibilidad | SLE, Architecture definition, Service Availability Plan | ST, GAT, PAT |
| Funcionalidad | FS, FRA, SIPOC | UT, UIT, SIT, ST, FAT, GAT en PAT |
| GUI | Business Cases, URS, DS | UT, ST, FAT |
| Hacker test | FRA, Risk Assessment, FMEA | PAT |
| Handover test | Handover checklist, cut-over plan, production support plan, decomission strategy | AT |
| Hardware test | Technical Architecture def., Implementation plan, deployment plan | UT, ST, PAT |
| Installation, rollback and de-installation | Implementation plan, deployment plan | ST, PAT |
| Interfaces | URS, Service definition, SIPOC, DS, FS, Technical Architecture Def | UIT, SIT, FAT |
| Penetración | FRA, Risk Assessment | ST, PAT |
| Pre-test | FS, URS | ST, SIT, AT |
| Procesos | URS, SIPOC, FS | GAT |
| Producción | Cut-over plan, Handover checklist, Implementation plan, Decomission strategy, Deployment plan | PAT |
| Recovery | Service Availability Plan, Contingency Plan, Risk Assessment | PAT |
| Regresión | FRA, Risk Assessment, FS | UT, UIT, ST, SIT, FAT, GAT, (PAT) |
| Rendimiento | Service Capacity Plan, Deployment plan, Technical Architecture Def | PAT |
| Security check | Risk Assessment, FRA, Contingency plan | ST, PAT |
| SLA | URS, FS, Service definition | ST, AT |
| Standards | URS, normativa aplicable | Reviews, ST, AT |
| Stress | Service capacity plan, Service availability plan, Contingency plan, SLA | PAT |
| Test de escenarios | Business cases, SOPs, SIPOC | GAT |
| Trial conversion | Migration Plan, URS | GAT, PAT |
| Usabilidad | SLA, URS, Business cases | GAT |
| Uso de recursos | Service capacity plan | ST, PAT |
Nota 1: FAT: Factory Acceptance Test; GAT: G Acceptance Test; AT: Acceptance Test; ST: System Test; PAT: Production Acceptance Test; UIT: User Interface Test; SIT: System Integration Test; UT: Unit Test; UIT: Unit Integration Test.
Nota 2: la tabla es un ejemplo orientativo. Según el tipo de proyecto y las características de la documentación, ésta se puede utilizar o no para la preparación de un tipo u otro de test.
Durante las fases iniciales (fase de Preparación, si seguimos el método de TMap) se debería evaluar la calidad de nuestra documentación que constituye el Test Basis, detectando gaps y deficiencias y concluyendo cuál puede ser la técnica de diseño de tests que mejor se adapta a la documentación disponible. Esta tarea se denomina Testability Review.
En el diagrama siguiente se muestra el flujo de trabajo de un proyecto, discurriendo en paralelo con el flujo de trabajo de testing, intercambiándose información sobre la calidad del producto/servicio en desarrollo, los errores, las desviaciones, etc. Para el caso del flujo de testing, como se puede ver, las características del Test Basis condicionan todo el desarrollo posterior.
La representación del ciclo de vida de desarrollo del software como flujos de trabajo o workstreams suele evidenciar que se trata más bien de un conjunto de flujos de trabajo imbricados o interrelacionados entre sí, interdependientes. Por ejemplo, como se muestra en el diagrama siguiente, los procesos de monitorización y evaluación de riesgos, los procesos de gestión de configuración, los de control de calidad, los de gestión del proyecto, o los de gestion de cambios, son flujos de trabajo que han de evolucionar coordinadamente, intercambiándose constantemente información. En este diagrama el testing y el desarrollo del proyecto no son dos flujos separados, sino que forman parte de una misma secuencia de procesos y actividades.
Una forma muy común de representar la relación entre el ciclo de vida del proyecto y el ciclo de vida del testing es el diagrama en V, en el que la parte izquierda se corresponde con la planificación, recogida de requisitos y elaboración de especificaciones de diseño y funcionales; mientras que la parte derecha de la V se corresponde con las actividades desarrolladas para verificar y controlar que la parte izquiera está evolucionando tal como se ha previsto. Los elmentos de una y otra parte se pueden hacer corresponder por pares formados por los elementos que se encuentre a la misma altura aproximadamente de la V.
La rama izquierda es en cierto modo equivalente al Test Basis, en tanto que la rama izquierda la forman las actividades de testing y validación.
Como ejemplo, el diagrama elaborado por la guía GAMP (Good Automated Manufacturing Practices), utilizada fundamentalmente en la validación de sistemas informáticos en la industria farmacéutica y en el software asociado a dispositivos médicos:
El informe del test, o Test Report, en las fases finales del proceso de testing, debería incluir la información sobre los documentos que han sido utilizados para elaborar los casos de test (test cases), los escenarios, los datos de test, etc.; es decir, qué Test Basis se ha utilizado. De esta manera se justifica al mismo tiempo por qué se ha decidido emplear o no emplear cierto tipo de cobertura, cierto tipo de tests, determinadas técnicas de diseño de tests, etc.
Pero en qué consiste concretamente el Test Basis?, qué documentos lo componen? De dónde salen estos documentos y a cuáles hemos de prestar más atención? Cómo varían estos documentos en función de la tipología del proyecto?
Durante la planificación de las pruebas tenemos que identificar claramente de qué documentación disponemos, y en relación con esta documentación, detallar qué es lo que vamos a verificar y cuál puede ser la cobertura más apropiada (coverage).
De forma muy general, los documentos que nos podemos encontrar y tendremos que evaluar en el momento de empezar a elaborar nuestra estrategia y nuestro plan de test pueden ser:
- Requerimientos (funcionales, de usuario, legislativos,…)
- Diseño funcional
- Diseño técnico
- Manuales de usuario
- Código fuente, pseudocódigo
- Opinión de expertos, reuniones informativas, etc.
La documentación del ciclo de vida de desarrollo de un proyecto de IT
Existen varios estándares destinados a organizar y regular la documentación que puede manejar una organización para desarrollar sus actividades. Por ejemplo la norma ISO 15489 o la especificación MoReq. Podría considerarse que la documentación generada durante el ciclo de vida de desarrollo de software, o durante la gestión de proyectos, es un subconjunto de la documentación de la organización, por lo que son igualmente aplicables este tipo de normas.
En la tabla siguiente se muestran las secciones principales de la ISO 15489 en una comparativa con la especificación MoReq.
Estándares más específicos del desarrollo de proyectos y el testing/validación en IT son:
- IEEE Standard for Software Verification and Validation Plans (ANSI/IEEE Std 1012)
- GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems.
- EU GMP Directive Good Manufacturing Practice Guidelines.
- Guidance for Industry Q10 Pharmaceutical Quality System (CDER, CBER)
- IEEE 829 Standard for Software Test Documentation
- ISO/IEC 12207:2008 Software life cycle processes
- ISO/IEC 26513:2009 Requirements for testers and reviewers of user documentation
- ISO/IEC 26514:2008 Requirements for designers and developers of user documentation
- ISO 15489-1: Information and documentation. Records management.
- ISO 20000: IT Service Management (ref BS15000) -> ITIL
- PRINCE2, The Stationary Office London
- TMap® Next, Testing Management Approach (Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon). UTN Publishers
Para poder ver más concretamente como evoluciona un proyecto (limitándonos a un proyecto en el ámbito de IT) y qué documentación o entregables genera que sean susceptibles de ser empleados como elementos del Test Basis, vamos a empezar por ver cómo los principales estándares (ISO 12207, PRINCE, PMBOK, GAMP, TMap) dividen los proyectos en fases, sin pararnos a considerar el detalle de actividades, responsabilidades o características de cada una, y señalando solamente los documentos relevantes generados en cada fase.
Un proyecto genérico se suele dividir en una fase o fases iniciales, una fase o fases de ejecución y una fase o fases de cierre, como en el ejemplo siguiente, indicando las actividades principales propias de cada fase:
En el ejemplo siguiente, relacionado con metodologías como PRINCE, la fase inicial se subdivide en Scope y Seek, mientras que se considera que el proyecto no acaba con la entrega del producto/servicio, sino que hay que hacer un seguimiento para garantizar la sostenibilidad y la calidad del mismo después de su despliegue:
Al comienzo y/o final de cada fase se suele realizar una revisión, mediante meetings y checklists, llamados a menudo Tollgates, para evidenciar el trabajo realizado, los entregables completados, las desviaciones y las tareas pendientes, y para decidir en este punto si continuar o no con la siguiente fase.
En el diagrama siguiente se muestran las fases típicas, los entregables más comunes de cada fase y los puntos de revisión (tollgates):
A menudo las dimensiones del proyecto determinan el tipo de documentación que se genera. A esta consideración se suele añadir la tipología del proyecto. Por ejemplo, cuando se trata de proyectos de IT en un ámbito muy regulado, como el farmacéutico, se ha de incluir documentación relacionada con GMP (Good Management Practices, EU), FDA (Federal Drug Administration, USA), etc. La tabla siguiente es un ejemplo de entregables en función del tamaño del proyecto (en este caso el criterio para determinar el tamaño es el coste):
Los entregables usuales en el ciclo de vida de desarrollo de un sistema informático en un sector fuertemente regulado como el farmacéutico (requiere validación y verificación del cumplimiento de normativas tipo GMP, FDA, etc) se podrían resumir como en la en la tabla siguiente:
| FASE |
ENTREGABLE |
|
| Project Definition / Planning | ||
| Project Definition | ||
| Project Proposal | ||
| Project Plan | ||
| Quality Project Plan | ||
| Business Case | ||
| Processes and Requirements | ||
| Communication Plan | ||
| Responsability Matrix | ||
| Planning Executive Summary | ||
| Kick-Off presentation and corresponding minutes. | ||
| Analysis | ||
| Processes and Requirements Definition | ||
| Stakeholder Analysis | ||
| Technical Arquitecture | ||
| Decomission Strategy | ||
| Detailed Project Plan (usually MS Project) | ||
| Support Model | ||
| Change Impact Analysis | ||
| Service Level Expectations (SLE) | ||
| Validation Master Plan | ||
| Risk Analysis | ||
| Migration Plan | ||
| Design | ||
| Traceability Matrix | ||
| GAP Inventory | ||
| Functional Design | ||
| Change Assessment | ||
| Build | ||
| Technical Design | ||
| Test Approach | ||
| Production Support Plan | ||
| Early Life Support Plan | ||
| Service Restoration Plan | ||
| Service Availability Plan | ||
| Service Capacity Plan | ||
| Change Management | ||
| Test Scenarios, Conditions & Expected Results | ||
| Technical Arquitecture Implementation | ||
| Build Documents | ||
| Configuration Guide | ||
| Service Pilot & Deployment Plan | ||
| Training Plan | ||
| Workforce Plan | ||
| Unit Test Inventory | ||
| Unit Test Report | ||
| Control Access Inventoy | ||
| Control Access Implementation | ||
| Test | ||
| Integration Test Cases | ||
| Integration Test Cases Results | ||
| Integration Test Report | ||
| Migration Test | ||
| Regression Testing Report | ||
| Training Documentation | ||
| User Acceptance Test Cases | ||
| User Acceptance Test Cases Results and Deviations | ||
| User Acceptance Test Report | ||
| Change Management Summary | ||
| Build / Test Executive Summary | ||
| Validation | ||
| IQ-Test Test Design | ||
| IQ-Test Test Cases | ||
| IQ-Test Test Cases Results and Deviations | ||
| IQ-Test Report | ||
| OQ Test Design | ||
| OQ Test Cases | ||
| OQ Test Cases Results and Deviations | ||
| OQ Report | ||
| IQ-Prod Test Design | ||
| IQ-Prod Test Cases | ||
| PQ Test Design | ||
| PQ Test Cases | ||
| Deployment | ||
| SOP’s | ||
| Updated Training Documentation (if applicable) | ||
| Contingency Plan | ||
| Installation Manual | ||
| User Guide | ||
| Co-existance Plan | ||
| Cut-Over / Roll-out Plan | ||
| Go-Live | ||
| PQ Test Cases Results and Deviations | ||
| IQ-Prod Report | ||
| PQ report | ||
| Project Closure | ||
| Validation Final Report | ||
| Decomission Strategy Execution | ||
| Project Closure | ||
Nota: se señala negrita la documentación generada en las fases de Testing y Validación, y que por tanto no forma parte del Test Basis, sino que se genera a partir de éste.
A continuación se muestra en un diagrama el resumen de la documentación generada en las fases principales del desarrollo de un proyecto y que es susceptible de ser empleada en el Test Basis.
Y finalmente, en la tabla siguiente, se describen las características y objetivos principales de todos aquellos documentos que pueden generarse (algunos habitualmente, otros no) durante el ciclo de vida del proyecto, y pueden formar parte del Test Basis para la planificación y especificación del testing y la validación.
| Abrev | Documento | Descripción |
|
|
Acceptance Report | Informe sobre los resultados generales de un proyecto frente a los criterios de aceptación predefinidos, tal como se documentaron en el Project Charter y/o en el Handover Checklist |
|
|
Acciones Correctivas Implementadas | |
|
|
Acciones Preventivas Implementadas | |
|
|
Analyze/Design Executive Summary | Documento tipo presentación donde se resume la información clave de la fase de Análisis/Diseño. Incluye la relación de entregables requeridos por esta fase. Este documento implica que se ha alcanzado una milestone y el proyecto puede continuar hacia la fase de Build/Test. |
|
|
Build/Test Executive Summary | Documento tipo presentación donde se resume la información clave de la fase de Build/Test. Incluye una relación de los entregables propios de esta fase. Este documento implica que se han alcanzado una milestone y el proyecto puede continuar hacia la siguiente fase (Service Pilot Phase, p.ej.) |
|
BC |
Business Case | Breve justificación del proyecto, que incluye una evaluación cualitativa/cuantitativa y el análisis de costes/beneficios |
|
SOP |
Business SOPs | |
|
|
Change Assessment | Identificación de los impactos colaterales de otros sistemas o procesos, que deben ser adaptados o almenos recomprobados (retested). |
|
|
Change Impact Analysis | Ver Change Assessment |
|
|
Change Log | |
|
|
Change management and implementation plan | Ver Change Assessment |
|
|
Change Requests, Solicitudes de Cambio Implementadas | |
|
COMP |
Communication Plan | Proporciona descripciones y recomendaciones para el mantenimiento de una comunicación efectiva durante las diferentes fases del proyecto, identificando quiénes son los implicados, qué información debe comunicarse y a quién, con qué frecuencia, cuáles son los canales a emplear y quién es responsable de cada flujo de comunicación. También se define cómo escalar la información en caso de incidencias, desviaciones, etc. |
|
|
Computer Service Supplier Audit Checklist | |
|
|
Configuration Guide | |
|
CP |
Contingency Plan | Definición de los requerimientos mínimos para garantizar que el negocio puede continuar con sus actividades. |
|
|
Control Access Inventoy | Inventario de los controles de acceso desde la perspectiva de la descripción del puesto de trabajo, indicando los usuarios asignados a cada uno. |
|
|
Customer Lessons Learned Summary | Documento para recoger los comentarios de los clientes en relación con el despliegue de un servicio y la satisfacción general respecto al mismo. |
|
|
Cut-Over Plan | Tareas para el manejo de la continuidad de los procesos. Se asocia con el Data Migration Plan, el Support Plan y el Contingency Plan |
|
DCM |
Data Conversion Migration Plan | Documento para la definición de la estrategia de conversión de los datos (data migration), incluyendo la identificación de los datos que han de ser migrados, los procesos de migración, los métodos, las responsabilidades para el test y la cualificación, etc de manera que se asegura que los datos traspasados al nuevo sistema están validados. |
|
|
Decomission Strategy Definition | Identifica cómo y cuándo los sistemas en uso serán desactivados (decomissioned) una vez que el proyecto se haya implementado y estabilizado. |
|
|
Defect Management | |
|
DP |
Deployment Plan | Definición de la estrategia de despliegue, incluyendo preparación del hardware, aplicaciones, políticas, procedimientos de migración desde el entorno de test hasta el entorno productivo, roll-out (puesta en marcha), data migration |
|
|
Deploy/Run Executive Summary | Documento de tipo presentation que resume la información clave de la fase de Despliegue/Ejecución (Deploy/Run). Incluye la relación de entregables propios de esta fase. Una vez superada esta fase y firmado este documento el proyecto puede darse por cerrado. |
|
DS |
Design Specification (DS) | Documento desarrollado frente a los Functional Requirements, proporcionando las especificaciones para el desarrollo de un producto/servicio de calidad. Muestra cómo el sistema se divide en subsistemas y suele contener diagramas aclarativos. se suele consultar el Project Solution Architect para determinar la metodología de diseño y las herramientas más apropiadas. Se define de forma no ambigua cómo el sistema implementa los requisitos expresados en la Functional Specification. Tanto el diseño como el código se debe trazar respecto a los requerimientos. |
|
|
Detailed Design Documents | |
|
|
Document Management | Documento donde se define como los documentos han de ser creados, nombrados, revisados, aprobados, distribuidos y almacenados. Se establece una convención para nombrar los documentos y mantener la consistencia a lo largo del proyecto. |
|
|
EA Questionnaire | Breve cuestionario para determinar la relevancia del proyecto. Suele ser un componen de la Solution Architecture. |
|
ELS |
Early Life Support (ELS) Plan | Documento para definir la asistencia limitada en el tiempo surante la fase de estabilización después del despliegue. También se define la transferencia de conocimientos y los integrantes del equipo de soporte. El plan establece los criterios de estabilización que, una vez obtenidos, implican la transferencia al soporte estándar. Se considera como el plan de soporte activo durante la fase piloto del proyecto. |
|
EAPP |
Enunciado de Alcance del proyecto preliminar (EAPP) | Suele formar parte del Project Charter. |
|
FMEA |
Failure Mode and Effects Analyses (FMEA) | Usado para la gestión de riesgos. Durante el proyecto, la lista de riesgos potenciales es revisada regularmente y actualizada con nuevos riesgos o con la mitigación de los riesgos existentes. Los riesgos potenciales se califican según su probabilidad de ocurrencia y su impacto potencial en el proyecto. |
|
FD |
Functional Design | Define cómo será implementado cada uno de los requerimientos, desde un punto de vista funcional. Cada funcionalidad incluye una definición relacionada con el proceso y el control de acceso. |
|
FMD |
Functional Model Definition | Definición de la forma en que el sistema ha de cumplir con los requerimientos de usuario. |
|
FRA |
Functional Risk Assessment (FRA) | Documento para centrar el testing en los riesgos principales. Se determina la criticidad de cada función y se añade la recomendación del tipo o intensidad del test asociado. |
|
FS |
Functional Specification (FS) | Documento para la descripción de los requerimientos en términos de funcionalidades (qué debería hacer el sistema) y capacidades. Cada requerimiento se divide en las funciones encargadas de satisfacerlo. La FS es una extensión de los User Requirements Specification (URS), describiendo las funcionalidades implicadas con más detalle. Es la base para la vase de Design & Development, así como para el testing reslacionado con la Operational Qualification (OQ). |
|
GAP |
GAP Inventory | Identificación de las funcionalidades no cubiertas por el sistema. |
|
|
Handover Checklist | Proporciona una guía de las actividades requeridas y los documentos a generar en el traspaso del systema computerizado al servicio receptor. Transición del Project Mode al Operational Mode. |
|
HLRA |
High Level Risk Assessment (HLRA) | Evaluación de alto nivel del proceso de negocio que se quiere cubrir con el sistema, señalando las dificultades y posibles contratiempos. Puede necesitar de modificaciones y actualizaciones, especialmente tras la elaboración de los requisitos de usuario (URS). |
|
|
Kick-Off Meeting | Se obtiene la implicación de todos los participantes en el proyecto. Asisten las áreas implicadas. Información general sobre el proyecto, el papel de cada área y los riesgos posibles. |
|
|
Lessons Learned | Compendio de las lecciones aprendidas durante el proyecto, de manera que puedan aplicarse a otros proyectos. |
|
|
Organizational Change and Training Concept | Aproximación de alto nivel para el soporte de los usuarios finales de un sistema:Cambios organizaciones requeridos, requerimientos de formación, etc |
|
|
Operational Handbook | Información operacional necesaria para el manejo eficiente del sistema en el entorno operativo. Incluye la descripción de los procedimientos de uso, los roles y responsabilidades y los entregables. |
|
|
Organizational Readiness Assessment | Análisis de la disponibilidad de la organización para desplegar y dar soporte tal como previamente se ha especificado (habitualmente en un Service Level Expectation (SLE)), considerando factores como seguridad, transferencia de conocimientos, tecnología, monitorización, roles y responsabilidades. El documento es determinante para decidir el paso a producción del sistema (go/delay decision). |
|
|
Package Evaluation & Selection | |
|
|
Physical and technical design | |
|
|
Planning Executive Summary | Documento tipo presentación que resume la información clave del Project Definition, Project Plan, y del Business Case. Estos cuatro documentos constituyen el Project Charter. Una vez revisado y firmado el proyecto puede avanzar hacia la fase de Análisis/Diseño. |
|
|
Production Support Plan | Documento que define cómo se ha de dar soporte para un servicio determinado, desde la perspectiva de los procesos y procedimientos definidos a nivel organizacional. |
|
|
Project Change Management Procedure | |
|
ACP, PCh |
Project Charter (Acta de Constitución del Proyecto – ACP) | Documento que proporciona la informacion consensuada respecto a un proyecto, actuando como contrato entre el patrocinador y el equipo del proyecto. Es un documento vivo que puede irse actualizando a lo largo del proyecto. |
|
|
Project Charter (Draft), Project Proposal | Documento cuya aprobación implica el inicio del proyecto (fase de Planificación y preparación) Basado en calendario, costes, esfuerzo, recursos, alcance. Se propone un responsable para cada tarea. Se evalúa el posible impacto GMP para el caso de las validaciones. |
|
|
Project Charter (Planning) | Versión actualizada del Draft Project Charter que proporciona información sobre el alcance, objetivos, causas origen de los problemas, soluciones anticipadas, costes, business case, riesgos principales, organización del proyecto, fechas clave (milestones) y entregables principales. |
|
|
Project Charter (Execution) | Documento empleado para la aprobación de la realización de los entregables del proyecto, una vez que la planificación se ha completado y los requerimientos han sido consensuados. |
|
|
Project Closeout Checklist | Documento para verificar que toda la documentación ha sido debidamente guardada y que todas las tareas se han completado antes del cierre del proyecto. |
|
PD |
Project Definition | Definición del alcanze global del proyecto, de los objetivos, las asunciones, los riesgos, las dependencias, los flujos del procesos, los stakeholders, la comunicación y los requisitos para la gestión del proyecto. Se tienen en cuenta objetivos, impacto, costes, riesgos y calendario. |
|
PDL |
Project Documentation List | |
|
PP, PGP |
Project Plan, Plan de Gestión del Proyecto (PGP) | Compendio de tareas y del calendario previsto, así como los recursos y el coste estimado. Seguimiento del progreso de cada tarea. REquiere inputs procedentes de: Data Migration Plan, Communication Plan, Test Plan, y Deployment Plan |
|
PRM |
Project Risk management | |
|
|
Project Schedule | Calendario previsto y actualizable del proyecto, milestones |
|
|
Project Scope Management | |
|
QP |
Quality Plan | Sumario de los procesos y entregables que verifican que un sistema se ha desarrollado e implementado de forma que se puede garantizar su calidad y el cumplimiento de los requerimientos. |
|
RFP |
Request for Proposal (RFP) | |
|
RA |
Risk Assessment | Identificación de los riesgos asociados con el desarrollo del proyecto |
|
RMS |
Risk Management Strategy | |
|
|
Roles & Responsibility Matrix | Identifica las personas implicadas a lo largo del ciclo de vida del proyecto, definiendo sus responsabilidades (ejecución, supervisión, asistencia, información,…) |
|
SAP |
Service Availability Plan | Documento sobre las suposiciones y los planes para asegurar la disponibilidad del servicio. |
|
SCP |
Service Capacity Plan | Documento sobre los supuestos y la capacidad para el uso esperado de un sistema. |
|
SD |
Service Definition | Visión general (high level overview) sobre las interfaces claves para el sevicio, las estructuras organizaciones o las entidades funcionales, y los procesos implementados por IT. Se describen los atributos principales o más relevantes del servicio (alcance, exclusiones, funciones, beneficios,…) |
|
|
Service Flow | Visión general de los inputs princpales del servicio, las actividades y las salidas, en un diagrama visual. Se identifican los pasos de los procesos y los roles implicados. |
|
SLA |
Service Level Agreement (SLA) | |
|
SLE |
Service Level Expectations (SLE) | Definición o naturaleza del servicio y conjunto de expectativas respecto a la disponibilidad, rendimiento, tiempos de respuesta, soporte y procesos de usuario y de cliente empleados para el manejo del servicio. |
|
|
Service Pilot & Deployment Plan | Planificación de la fase de servicio piloto y despliegue. incluye criterios principales de éxito, relaciones y dependencias con otros proyectos, alcance del servicio piloto, stakeholders, riesgos de la implementación, actividades principales y tiempos previstos. |
|
|
Service Pilot Lessons Learned | Lecciones aprendidas y áreas de mejora en relación con la fase del Servicio piloto |
|
|
Service Pilot Executive Summary | Documento tipo presentación que resume la información principal de la fase de Servicio Piloto. Incluye los entregables propios de esta fase. Completada esta fase el proyecto puede iniciar la fase de Despliegue y Ejecución (Deploy/Run Phase). |
|
SRP |
Service Restoration Plan | Documento para definir y planificar el cumplimiento del Service Level Expectation (SLE), Data Recovery, y Custom Significant Incident guidelines para cada servicio. |
|
|
Service Run Book | Documento para dar soporte a la transición del servicio a producción (“run” state), proporcionando una explicación detallada de cómo el servicio debería operar, incluyendo procedimientos paso-a-paso, by providing a detailed explanation of how the service should operate and includes step-by-step procedures, consejos generales, etc. |
|
|
Service Supplier Audit Checklist | |
|
SIPOC |
SIPOC | Proceso de mapeo de alto nivel de los proveedores (Suppliers), Inputs (entradas), Salidas (Outputs) y Clientes (Customers) implicados en el proyecto. |
|
|
Software Supplier Audit Checklist | |
|
|
Solution Architecture Blueprint | Muestra a grandes rasgos cómo ha de ser el servicio o sistema, contiene las decisiones de diseño, los procesos, la tecnología, así como el soporte para la formacion y el desempeño. No suele contener detalles de la especificación (cómo trabaja cada una de las partes), sino que define qué partes se usan y cómo interactúan. |
|
SOP |
SOP’s | Procedimientos operativos relacionados con los procesos impactados por el sistema desarrollado/implementado. |
|
SCR |
Source Code Review | Resultado de una revisión independiente del código fuente y evaluación general junto con recomendaciones. La Design Specification debe estar previamente aprovada, ya que es el input principal para esta evaluación. También han de estar presentes los estándares de programación utilizados, para usarlos como criterio de corrección. |
|
|
Stakeholder Analysis | |
|
|
Support Model | Documento que identifica los elementos principales que impactan en la estrategia de soporte durante la estapas de transición y de operación. también se indican las herramientas a utilizar para la estrategia de soporte. |
|
TAD |
Technical Architecture Definition | Requerimientos relacionados con la arquitectura para el desarrollo del proyecto y el despliegue. |
|
|
Technology and organizational assessment | |
|
TM |
Traceability Matrix | Documento para enlazar requerimientos con especificaciones funcionales y con test cases. El documento se inicia al entregar los URS y puede ir evolucionando al lo largo del proyecto. |
|
rTM |
Requirements Traceability Matrix | Documento que mapea los requerimientos de usuario, incluyendo funcionales, de calidad, interfaces, seguridad, técnicos, de formación, de rendimiento o de despliegue |
|
TAI |
Technical Arquitecture Implementation | Implementación de los requerimientos de la arquitectura técnica para el desarrollo del proyecto y el despliegue. |
|
TD |
Technical Design | Define cómo se implementará un requerimiento o un GAP desde un punto de vista técnico. |
|
|
Training program | |
|
|
Training Forms | Formación de los usuarios finales para el trabajo con el sistema. |
|
URS |
User Requirements Specification (URS) | Describe en términos entendibles para el usuario común, qué es lo que el sistema debería hacer, los datos, la interfaz, aspectos de seguridad, rendimiento, requerimientos de hardware, etc. proporciona una descripción comprehensiva de lo que se espera del sistema. Se suele emplear para el proceso de selección del proveedor y como fundamento de las Especificaciones Funcionales (Functional Specifications). |
|
|
Vendor Assessment | |
|
VOC |
VOC – CTQ Planning Project Charter | Proporciona una visión de las necesidades del cliente o usuario en relación con los procesos de negocio (descritos en el SIPOC), traduciéndolas en requisitos específicos y medibles (CTQ = Critical to Quality) |
|
WBS |
Work Breakdown Structure (WBS) | |
|
|
Workforce Plan |
For more information:
Antonio Álvarez Folgado – Analista Funcional – Sogeti España
Tu centro de expertise en España sobre Quality Engineering y Testing 
0 comments on “El Test Basis y la documentación de un proyecto de IT”