El Test Basis y la documentación de un proyecto de IT

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

A.A.1

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.

A.A.2

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:

A.A.3

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.

A.A.4

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:

A.A.5

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:

A.A.6

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

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

A.A.8

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.

A.A.10

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 

 antonio.alvarez@sogeti.com

 

Autor: qanewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s