Documente Academic
Documente Profesional
Documente Cultură
PERUANA 2016
Dirección de Normalización - INACAL
Calle Las Camelias 815, San Isidro (Lima 27) Lima, Perú
(EQV. ISO/IEC 12207:2008 IEEE Std 12207-2008 Systems and software engineering - Software life
cycle processes)
2016-06-15
3ª Edición
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta
publicación podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo
fotocopia o publicándolo en el Internet o intranet, sin permiso por escrito del INACAL, único representante
de la ISO/IEC en territorio peruano.
© INACAL 2016
Todos los derechos son reservados. A menos que se especifique lo contrario, ninguna parte de esta
publicación podrá ser reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo
fotocopia o publicándolo en el Internet o intranet, sin permiso por escrito del INACAL.
INACAL
i
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
ÍNDICE
página
ÍNDICE ii
PREFACIO vi
PRÓLOGO (ISO) ix
INTRODUCCIÓN xi
1 VISIÓN GENERAL 1
1.1 Alcance 1
1.2 Propósito 1
1.3 Limitaciones 2
2 CONFORMIDAD 3
3 REFERENCIAS NORMATIVAS 4
4 TÉRMINOS Y DEFINICIONES 4
ii
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
5.1.12 Modelos y etapas del ciclo de vida 22
5.2 Organización de esta Norma 23
5.2.1 Categorías de los procesos del ciclo de vida 23
5.2.2 Resumen de los procesos del ciclo de vida 26
5.2.3 Modelo de Proceso de Referencia 32
iii
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
7.1.6 Proceso de Integración del Software 123
7.1.7 Proceso de Pruebas de Calificación del Software 126
7.2 Procesos de Soporte del Software 128
7.2.1 Procesos de Gestión de la Documentación del Software 128
7.2.2 Proceso de Gestión de la Configuración del Software 131
7.2.3 Proceso de Aseguramiento de la Calidad del Software 134
7.2.4 Procesos de Verificación del Software 137
7.2.5 Proceso de Validación del Software 141
7.2.6 Proceso de Revisión del Software 144
7.2.7 Proceso de Auditoría del Software 147
7.2.8 Proceso de Resolución de Problemas del Software 149
7.3 Procesos de Reutilización del Software 151
7.3.1 Proceso de Ingeniería de Dominio 152
7.3.2 Proceso de Gestión de Activos de Reutilización 156
7.3.3 Proceso de Gestión de Programas de Reutilización 159
ANEXOS
iv
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
ANEXO C (INFORMATIVO) HISTORIA Y JUSTIFICACIÓN 188
v
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
PREFACIO
A. RESEÑA HISTÓRICA
vi
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
ENTIDAD REPRESENTANTE
vii
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
Resumen: Esta Norma establece un marco común para los procesos del ciclo de vida del
software, con la terminología bien definida, que puede ser referenciada por la industria del
software. Se aplica a la adquisición de sistemas y productos y servicios software, al
suministro, desarrollo, operación, mantenimiento y retiro de los productos software y la
parte software de un sistema, ya sea ejecutado interna o externamente a una organización.
Esos aspectos de la definición del sistema necesarios para proporcionar el contexto para
los productos y servicios software, están incluidos. El software incluye la parte software
del firmware. Esta revisión integra la norma ISO/IEC 12207:1995 1 , con sus dos
enmiendas y fue coordinada con la revisión paralela de la ISO/IEC 15288:2002 (procesos
del ciclo de vida del Sistema) para alinear la estructura, términos y las correspondientes
procesos organizativos y de proyecto. Esta norma se puede utilizar independiente o
conjuntamente con ISO/IEC 15288 2 , y suministra un modelo de proceso de referencia
que soporta la evaluación de la capacidad del proceso según la norma ISO/IEC 15504-2 3
(evaluación del Proceso). Un anexo proporciona soporte para los usuarios de IEEE y
describe las relaciones de esta Norma con los estándares IEEE.
1
La NTP-ISO/IEC 12207:2006 es equivalente a la ISO/IEC 12207:1995 +
ISO/IEC 12207:1995/Amd 1:2002 + ISO/IEC 12207:1995/Amd 2:2004 .
2
La NTP-ISO/IEC 15288 es quivalente a la ISO/IEC 15288 .
3
La NTP-ISO/IEC 15504-2 es equivalente a la ISO/IEC 15504-2 .
viii
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
PRÓLOGO
(ISO)
Los Estándares Internacionales son redactados de acuerdo con las reglas establecidas en
las Directivas ISO/IEC, Parte 2.
Existe la posibilidad que alguno de los elementos de este documento pueda estar sujeto
a derechos de patente. ISO e IEC no deben ser responsables de la identificación de
dichos derechos de patente.
ISO/IEC 12207 4 fue preparada por el Comité Técnico Conjunto ISO/IEC JTC1 ,
Information technology, Subcommittee SC 7, Software and Systems engineering.
4
La NTP-ISO/IEC 12207:2016 es equivalente a la ISO/IEC 12207:2008 IEEE Std 12207-2008 .
ix
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
Los cambios en esta revisión de la ISO/IEC 12207 4 fueron desarrollados en conjunción
con una correspondiente revisión de la ISO/IEC 15288 2. El objetivo de estas revisiones
es alinear mejor las dos Normas Internacionales para facilitar su utilización conjunta.
Esta alineación es el primer paso hacia la armonización de las estructuras y contenidos
de los dos Normas Internacionales, en tanto soporta los requisitos de la comunidad de
evaluación. Esta alineación proporciona la base para facilitar la evolución de un
tratamiento integrado y totalmente armonizado de procesos de ciclo de vida. Esta
Norma fue desarrollada con los siguientes objetivos:
Una revisión posterior es prevista para lograr una visión totalmente armonizada de los
procesos de ciclo de vida del sistema y del software. Las áreas identificadas para ser
tratadas en el futuro incluyen: propósitos y resultados de procesos comunes,
arquitectura de los estándares, el nivel de prescripción de actividades y tareas,
tratamientos del ciclo de vida, tratamiento de productos y servicios, conceptos de
verificación y validación comunes, conceptos de gestión de la configuración común,
recomendaciones y alineación con otras normas aplicables diferidas.
x
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
INTRODUCCIÓN
La ISO/IEC 12207 4 fue publicada el 1 de agosto de 1995 y fue la primera Norma que
proporciona un conjunto completo de procesos, actividades y tareas de ciclo de vida
para el software que forma parte de un sistema más grande, y para productos y servicios
software independientes. Esta Norma fue seguida en Noviembre del 2002 por la
ISO/IEC 15288 2 , la cual trata los procesos del ciclo de vida del sistema. La ubicuidad
del software significó que el software y sus procesos de diseño no deberían ser
considerados separadamente de dichos sistemas, sino como una parte integral del
sistema y de los procesos de diseño del sistema. Las Enmiendas de la ISO/IEC 12207 4
en 2002 y 2004 adicionaron a la Norma el propósito y los resultados de los procesos y
establecieron un Modelo de Procesos de Referencia de acuerdo con los requisitos de la
ISO/IEC 15504-2 3 .
Esta revisión integra la ISO/IEC 12207:1995 1 con sus dos Enmiendas y aplica las
pautas del SC7 en la definición de los procesos para respaldar la consistencia y mejorar
su usabilidad. La ejecución del proyecto fue coordinada cuidadosamente con la revisión
paralela de la ISO/IEC 15288:2002 para alinear la estructura, términos y los
correspondientes procesos organizacionales y de proyecto.
xi
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
Por un adquiriente y un proveedor - para ayudar a elaborar un acuerdo
relacionado a procesos y actividades. A través del acuerdo; los procesos
y actividades en esta norma se seleccionan, negocian, acuerdan y
ejecutan. En este modo, esta norma se utiliza para la orientación en el
desarrollo del acuerdo.
Esta norma contiene requisitos en cuatro capítulos: capítulo 6, que define los requisitos
para los procesos del ciclo de vida del sistema, capítulo 7, que define los requisitos para
los procesos del ciclo de vida de software específico, apartados del Anexo A , que
proporciona los requisitos para la adaptación de esta norma y apartados del Anexo B ,
que proporciona un Modelo de Proceso de Referencia (MPR) que puede ser utilizado
para propósitos de evaluación.
xii
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
INTRODUCCIÓN IEEE
Esta introducción no es parte de IEEE Std 12207™ -2008 , Ciclo de Vida de Sistemas e
Ingeniería de Software-Software Procesos.
IEEE Std 12207 ™ -2008 y IEEE Std 15288 ™ -2008 son idénticos a la norma
ISO/IEC 12207:2008 4 y ISO/IEC 15288:2008 2 . Por lo tanto, todas las referencias a la
norma ISO/IEC 12207 4 o ISO/IEC 15288 2 se aplican igualmente bien a su IEEE
homólogos. Otros detalles con respecto a las relaciones de los estándares IEEE se
pueden encontrar en el Anexo G.
IEEE no recogió estas modificaciones, prefiriendo una base estable para los usuarios de
su estándar.
xiii
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
Esta nueva revisión de la norma ISO/IEC 12207 4 es el producto de un esfuerzo
coordinado por IEEE e ISO/IEC JTC 1/SC 7. Los documentos de base para la revisión
incluyen el estándar ISO/IEC y sus modificaciones, y el IEEE/EIA norma y su material
único.
En esta revisión se integra la norma ISO/IEC 12207:1995 1 con sus dos enmiendas y
aplica las directrices para el proceso de SC7 definición de apoyo a la coherencia y la
mejora en la usabilidad. La ejecución del proyecto fue cuidadosamente coordinada con
la revisión paralela de la norma ISO/IEC 15288:2002 para alinear la estructura, los
términos, y la correspondiente organización y los procesos del proyecto.
Esta norma revisada es un paso en la estrategia de armonización SC7 para lograr una
suite totalmente integrada de sistema y los procesos del ciclo de vida del software y los
lineamientos para su aplicación. También es un paso importante en la estrategia
compartida de la norma ISO/IEC JTC 1/SC 7 y el IEEE para armonizar sus respectivas
colecciones de normas. La nueva edición de la norma ISO/IEC 12207 4 e
ISO/IEC 15288 2 , y sus ediciones idénticas IEEE, proporcionarán una sola, compartidos
la línea de base de los sistemas y procesos del ciclo de vida del software aplicables a las
normas ISO/IEC y los estándares IEEE colecciones.
Errata
Interpretaciones
xiv
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
Patentes
---oooOooo---
xv
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 1 de 220
1 VISIÓN GENERAL
1.1 Alcance
Esta norma establece un marco de trabajo común para los procesos del ciclo de vida del
software, con terminología bien definida, que puede servir de referencia para la industria
del software. Contiene procesos, actividades y tareas que son aplicables durante la
adquisición de un producto o servicio de software y durante el suministro, desarrollo,
operación, mantenimiento y de los productos software. El software incluye la parte
software del “firmware”.
Esta norma también proporciona un proceso que se puede emplear para definir, controlar y
mejorar los procesos del ciclo de vida del software.
Los procesos, actividades y tareas de esta norma - sea solo o en conjunto con la
ISO/IEC 15288 2 - también se puede aplicar durante la adquisición de un sistema que
contiene software.
1.2 Propósito
Esta norma está escrita para adquirientes de productos y servicios de sistemas y software
para proveedores, desarrolladores, operadores, personas a cargo de mantenimiento,
administradores, gerentes del aseguramiento de la calidad y usuarios de productos
software.
Esta norma está orientada para ser utilizada en una situación de dos-partes y puede ser
igualmente aplicada cuando las dos partes son de la misma organización. La situación
puede variar desde un acuerdo informal hasta un contrato legalmente vinculante. La norma
puede ser utilizada por una sola de las partes a través de un conjunto de procesos
autoimpuestos. Este apartado no impide el uso de la ISO/IEC 12207 4 por los proveedores
o desarrolladores de software pre-elaborado (off the shelf).
1.3 Limitaciones
Esta Norma no detalla los procesos del ciclo de vida en términos de métodos o
procedimientos que se requieren para cumplir los requisitos y resultados de un proceso.
NOTA: ISO/IEC 15289 aborda el contenido para los elementos de información del proceso del ciclo
de vida (documentación).
Esta Norma no pretende entrar en conflicto con las políticas, procedimientos y estándares
organizacionales ni con las leyes y regulaciones nacionales. Cualquier conflicto debería
ser resuelto antes de usar esta Norma.
2 CONFORMIDAD
Los requisitos de esta norma están contenidos en los capítulos 6 y 7 y el Anexo A . Esta
norma establece los requisitos para una serie de procesos adecuados para su utilización
durante el ciclo de vida de un producto o un servicio software. Se reconoce que proyectos
u organizaciones en particular pueden no necesitar utilizar todos los procesos
proporcionados por esta norma. Por lo tanto, la implementación de esta Norma usualmente
consiste en seleccionar un conjunto de procesos adecuados para la organización o
proyecto. Hay dos maneras en que una implementación puede ser declarada conforme a los
requisitos de esta Norma. Cualquier declaración de conformidad está descrita en una de las
dos siguientes formas.
NOTA 1: Cuando esta Norma se utiliza para ayudar en el desarrollo de un acuerdo entre un
adquiriente y un proveedor, los capítulos de esta norma se pueden seleccionar para su incorporación
en el acuerdo, con o sin modificación. En este caso, es más adecuado para el adquiriente y el
proveedor declarar el cumplimiento del acuerdo en lugar de la conformidad con esta Norma.
NOTA 2: Cualquier organización (por ejemplo, nacional, asociación industrial, empresa) que imponga
esta norma, como condición comercial, debería especificar y hacer público el conjunto mínimo
requerido de procesos, actividades y tareas, que constituyen la conformidad de los proveedores con
esta norma.
NOTA 3: Los requisitos de esta Norma son resaltados con la utilización del verbo "deberá". Las
recomendaciones están resaltadas por el uso del verbo "debería". Los permisos son resaltados por el
uso del verbo "puede".
3 REFERENCIAS NORMATIVAS
4 TÉRMINOS Y DEFINICIONES
Para los propósitos de esta norma, se aplican los siguientes términos y definiciones.
4.1
adquiriente
interesado que adquiere o intenta adquirir un producto o servicio de un proveedor.
NOTA: El adquiriente puede ser uno de los siguientes: comprador, cliente consumidor o propietario.
4.2
adquisición
proceso para obtener un sistema, producto software o servicio software.
4.3
actividad
conjunto de tareas cohesionadas de un proceso.
4.4
acuerdo
reconocimiento mutuo de términos y condiciones bajo los cuales se lleva a cabo una
relación de trabajo.
4.5
auditoría
evaluación independiente de los productos y procesos software, realizada por una persona
autorizada con el fin de evaluar la conformidad con los requisitos.
4.6
línea base
especificación o producto que se ha revisado y pactado formalmente, que en adelante sirve
como base para desarrollos adicionales y que se puede cambiar únicamente a través de
procedimientos formales de control de cambios.
4.7
elemento de configuración
entidad dentro de una configuración que satisface una funcionalidad y que puede ser
identificada en forma única en un punto de referencia dado.
4.8
contrato
acuerdo vinculante entre dos partes, especialmente exigible por ley, o un acuerdo interno
similar, totalmente dentro de una organización.
4.9
cliente
organización o persona que recibe un producto o un servicio.
NOTA 3: Otros términos que se usan comúnmente para cliente son: adquiriente, comprador y
consumidor.
4.10
entidad desarrolladora
organización que realiza actividades de desarrollo (incluyendo análisis de requisitos,
diseño, pruebas de aceptación) durante un proceso del ciclo de vida.
4.11
sistema habilitador
sistema que da soporte a un sistema de interés durante sus etapas del ciclo de vida, pero
que no necesariamente contribuye directamente a su función durante la operación.
NOTA 1: Por ejemplo, cuando un sistema de interés ingresa en la etapa de producción, se requiere un
sistema habilitador de producción.
NOTA 2: Cada sistema habilitador tiene su propio ciclo de vida. Esta Norma se aplica a cada uno de
los sistemas habilitadores cuando, por derecho propio, es tratado como un sistema de interés.
4.12
evaluación
determinación sistemática del grado hasta el cual una entidad cumple sus criterios
especificados.
4.13
recurso
medio físico o equipo que facilita la ejecución de una acción, por ejemplo edificaciones,
instrumentos, herramientas.
4.14
firmware
combinación de un dispositivo de hardware e instrucciones de la computadora o datos de la
computadora que residen como software de sólo lectura en el dispositivo de hardware.
4.15
entidad implementadora
organización que lleva a cabo tareas de implementación.
4.16
ciclo de vida
evolución de un sistema, producto, servicio, proyecto u otra entidad elaborada por el
hombre desde la concepción hasta su retiro.
4.17
modelo del ciclo de vida
marco de procesos y actividades relacionadas con el ciclo de vida que se pueden organizar
en etapas, el cual también actúa como una referencia común para la comunicación y el
entendimiento.
4.18
entidad a cargo del mantenimiento
organización que lleva a cabo actividades de mantenimiento.
4.19
monitoreo
examen del estado de las actividades de un proveedor y de sus resultados por parte de un
comprador o una tercera parte.
4.20
elemento no entregable
producto hardware o software que no se requiere entregar bajo contrato, pero que se puede
utilizar en el desarrollo de un producto software.
4.21
producto listo para la venta (off-the-shelf)
<producto> que ya se ha desarrollado y está disponible.
4.22
operador
entidad que lleva a cabo la operación de un sistema.
NOTA 1: El rol de operador y rol de usuario pueden ser asignados de manera simultánea o secuencial,
a la misma persona u organización.
NOTA 2: En el contexto de esta definición específica, el término entidad significa una persona o una
organización.
4.23
organización
persona o grupo de personas e instalaciones con una disposición de responsabilidades,
autoridades y relaciones.
NOTA 2: Una organización es un conjunto de personas organizadas para algún propósito específico
tales como un club, sindicato, corporación o sociedad.
NOTA 3: Una parte determinada de una organización (incluso tan pequeña como una sola persona) o
un grupo determinado de organizaciones pueden ser considerados como una organización si tiene
responsabilidades, autoridades y relaciones.
NOTA 4: Una forma de entidad organizacional a menudo se denomina empresa, de modo que los
aspectos organizacionales de esta Norma se aplicarían también a una empresa.
4.24
parte
organización que participa en un contrato.
NOTA: En esta Norma, las partes del acuerdo se denominan el adquiriente y el proveedor.
4.25
proceso
conjunto de actividades mutuamente relacionadas o que interactúan las cuales transforman
elementos de entradas en salidas.
[ISO 9000:2005]
4.26
propósito del proceso
objetivo de alto nivel de la ejecución del proceso y los posibles resultados de la
implementación efectiva del proceso.
NOTA: La aplicación del proceso debería proporcionar beneficios tangibles a las partes interesadas.
4.27
resultados del proceso
resultado observable del logro exitoso del propósito del proceso.
producción de un artefacto;
un cambio significativo en el estado; y
cumplimiento de restricciones específicas, por ejemplo, requisitos, metas, entre otros.
4.28
producto
resultado de un proceso
[ISO 9000:2005]
4.29
proyecto
esfuerzo con fechas definidas de inicio y finalización que se emprende para crear un
producto o un servicio, de acuerdo con los requisitos y los recursos especificados.
NOTA 2: Un proyecto puede ser considerado como un proceso único que comprende actividades
coordinadas y controladas y puede estar compuesto de actividades de los procesos del proyecto y de
los procesos técnicos definidos en esta Norma.
4.30
portafolio de proyectos
conjunto de proyectos que están alineados a los objetivos estratégicos de la organización.
4.31
calificación
proceso que demuestra si una entidad es capaz de cumplir los requisitos especificados.
4.32
requisito de calificación
conjunto de criterios o condiciones que se deben cumplir con el fin de calificar un producto
de software como conforme con sus especificaciones y listo para el uso en su ambiente de
objetivo, o para la integración con el sistema que lo contiene.
4.33
prueba de calificación
pruebas, realizadas por el encargado del desarrollo y presenciadas por el adquiriente (según
corresponda), para demostrar que un producto de software satisface sus especificaciones y
está listo para usar en su ambiente de producción o para la integración con el sistema que
lo contiene.
4.34
aseguramiento de la calidad
todas las actividades planificadas y sistemáticas que se implementan dentro del sistema de
calidad, y que se ha demostrado son necesarias, para proporcionar confianza adecuada que
la entidad cumplirá los requisitos de calidad.
NOTA 1: Existen propósitos tanto internos como externos para el aseguramiento de la calidad:
NOTA 3: A menos que los requisitos para la calidad reflejen en su totalidad las necesidades del
usuario, el aseguramiento de la calidad puede que no suministre una confianza adecuada.
4.35
versión
versión particular de un elemento de configuración que está disponible para un propósito
específico (por ejemplo, versión para prueba).
4.36
solicitud de propuesta
oferta
documento utilizado por el adquiriente como medio para anunciar su intención a postores
potenciales de adquirir un sistema específico, producto de software o servicio de software.
4.37
recurso
activo que es utilizado o consumido durante la ejecución de un proceso.
4.38
retiro
remoción del soporte activo por parte de la organización de operación y mantenimiento,
sustitución parcial o total por un nuevo sistema, o instalación de un sistema mejorado.
4.39
seguridad
protección de la información y de los datos de manera que personas o sistemas no
autorizados no puedan leerlos ni modificarlos, que a las personas o sistemas autorizados no
se les niegue el acceso a ellos.
4.40
servicio
ejecución de actividades, trabajo o deberes asociados con un producto.
4.41
elemento de software
elemento
código fuente, código objeto, código de control, datos de control o un conjunto de estos
elementos.
NOTA: Un elemento de software se puede considerar como un elemento del sistema según la norma
ISO/IEC 15288:2008 2.
4.42
producto software
conjunto de programas de computador, procedimientos y posiblemente documentación y
datos asociados.
4.43
unidad de software
parte del código que se puede compilar de manera separada.
4.44
etapa
período dentro del ciclo de vida de una entidad que se relaciona con el estado de su
descripción o realización.
NOTA 1: Tal como se utiliza en esta norma, las etapas se relacionan con los hitos importantes de
avance y logro de la entidad a través de su ciclo de vida.
4.45
parte interesada
individuo u organización que tenga un derecho, acción, reclamo o interés en un sistema o
en las que posee características que cumplen sus necesidades y expectativas.
4.46
declaración de trabajo
documento utilizado por el adquiriente como medio para describir y especificar las tareas
que se deben ejecutar según el contrato.
4.47
proveedor
organización o individuo que establece un acuerdo con el adquiriente para el suministro de
un producto o servicio.
4.48
sistema
combinación de elementos organizados que interactúan para lograr uno o más propósitos
establecidos.
NOTA 1: Un sistema puede ser considerado como un producto o como los servicios que presta.
NOTA 2: En la práctica, la interpretación de este significado con frecuencia se aclara con el uso de un
sustantivo asociativo, por ejemplo, sistema de aeronave. Como alternativa, la palabra "sistema" se
puede sustituir simplemente por un sinónimo que dependa del contexto, por ejemplo, aeronave,
aunque esta sustitución puede ocultar una perspectiva de los principios de sistemas.
4.49
elemento del sistema
miembro de un conjunto de elementos que constituyen un sistema.
NOTA: Un elemento del sistema es una parte separada de un sistema que se puede implementar para
satisfacer requisitos específicos. Un elemento del sistema puede ser hardware, software, datos,
personas, procesos (por ejemplo, procesos para proveer el servicio a los usuarios), procedimientos
(por ejemplo, instrucciones del operador), instalaciones, materiales y entidades de origen natural (por
ejemplo, el agua, organismos, minerales) o cualquier combinación.
4.50
tarea
requisito, recomendación o acción permitida, destinada a contribuir al logro de uno o más
resultados de un proceso.
4.51
cobertura de la prueba
grado hasta el cual los casos de prueba demuestran el cumplimiento de los requisitos para
el sistema o el producto de software.
4.52
facilidad de prueba
nivel hasta el cual un objetivo y una prueba factible se pueden diseñar para determinar si se
cumple un requisito.
4.53
usuario
individuo o grupo que se beneficia de un sistema durante su utilización.
NOTA: Los roles del usuario y del operador pueden estar asignados, simultáneamente o en secuencia
en el mismo individuo u organización.
4.54
validación
confirmación, mediante la aportación de evidencia objetiva de que se han cumplido los
requisitos para una utilización o aplicación específica prevista
[ISO 9000:2005]
4.55
verificación
confirmación mediante la aportación de evidencia objetiva de que se han cumplido los
requisitos especificados.
[ISO 9000:2005]
4.56
versión
instancia identificada de un elemento.
NOTA: La modificación de una versión de un producto de software, que resulte en una versión nueva,
requiere la gestión de la configuración.
Este capítulo presenta una visión general de los procesos del ciclo de vida del software que
se pueden utilizar para adquirir, proporcionar, desarrollar, operar, mantener y disponer
productos y servicios de software. El objetivo es proveer un mapa de ruta para los usuarios
de esta Norma, de manera que puedan orientarse en ella y aplicarla con criterio.
Esta sección introduce conceptos claves útiles para la lectura y aplicación de esta norma.
En pocos casos, las palabras de uso común se utilizan de manera especial en la norma. Este
apartadosección también describe esos usos especiales. Mayor detalle sobre estos
conceptos se puede encontrar en la ISO/IEC TR 15271 5 , A guide for the application of
ISO/IEC 12207 4 , Software life cycle processes.
NOTA: Un futuro Reporte Técnico (ISO/IEC TR 24748 , Guide for life cycle management) también
brindará mayores detalles.
Este apartado general, esta Norma se aplica tanto a productos de software como a servicios
de software. Las disposiciones de los procesos específicos establecen su aplicabilidad.
NOTA: La ISO/IEC 20000 proporciona procesos, requisitos y directrices para los proveedores de
servicios para la entrega de servicios de administrador.
5
La NTP-ISO/IEC TR 15271 es equivalente a la ISO/IEC TR 15271 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 16 de 220
Esta Norma establece un vínculo fuerte entre un sistema y su software. Esto se basa en los
principios generales de la ingeniería de sistemas. El software se trata como una parte
integral del sistema total y ejecuta ciertas funciones en el sistema. Se implementa mediante
la extracción de los requisitos del software a partir de los requisitos y el diseño del sistema,
produciendo el software e integrándolo en el sistema. Es una premisa fundamental de esta
Norma que el software siempre exista en el contexto de un sistema, incluso si el sistema
consta únicamente del procesador en el cual se ejecuta el software. Por lo tanto, un
producto o servicio software siempre se trata como un elemento en un sistema. Por
ejemplo, la Norma hace una distinción entre el análisis de requisitos del sistema y el
análisis de requisitos del software, porque, en el caso general, el diseño arquitectónico del
sistema asignará los requisitos del sistema a varios elementos del sistema, y el análisis de
los requisitos del software derivará en los requisitos del software a partir de los requisitos
del sistema asignados a cada elemento del software. Por supuesto, en algunos casos, los
elementos que no son software de un sistema pueden ser tan mínimos que no es necesario
llevar a cabo análisis diferentes del sistema y del software.
Esta Norma tiene una relación fuerte con ISO/IEC 15288:2008 2 . Procesos del ciclo de
vida del sistema, y se puede usar junto con ella. En muchos casos, los procesos de esta
Norma corresponden directamente a los procesos de la ISO/IEC 15288 2 , pero con alguna
especialización para los productos y servicios de software. Un ejemplo notable es que el
proceso de implementación del software de esta Norma es una especialización –una
especialización detallada- del proceso de implementación de la ISO/IEC 15288 2 .
Cuando el sistema tiene elementos importantes que no son del software, una organización
puede aplicar la ISO/IEC 15288 2 para proporcionar los procesos adecuados del ciclo de
vida. Para cada elemento de software del sistema, la organización aplicaría el proceso
Implementación de Software de esta Norma para crear el elemento del software.
Cuando las partes del sistema que no son de software son mínimas, una organización,
puede aplicar esta Norma sin referencia a la ISO/IEC 15288 2 . Esta Norma contiene
procesos adicionales a nivel del sistema –aunque especializados a las necesidades del
software- con el fin de brindar un mínimo contexto de sistemas apropiado para el software.
Cuando se aplica esta Norma junto con ISO/IEC 15288 2 , se debe considerar una
incongruencia menor en la terminología. ISO/IEC 15288 2 descompone un sistema en un
conjunto de "elementos" del sistema. Se puede determinar que algunos de esos elementos
son productos de software que se van a implementar utilizando esta norma. Esta norma
utiliza el término "elemento" para hacer referencia a un elemento importante del sistema.
En resumen, esta Norma utiliza el término "elemento" cuando la
ISO/IEC 15288 2 utiliza el término "elemento de software".
Una organización o una parte derivan su nombre de los procesos de los cuales es
responsable. Por ejemplo, se denomina adquiriente cuando ejecuta el proceso de
adquisición. De este modo, cuando se utilizan los siguientes términos en esta Norma, no
tienen su significado genérico sino que se refieren a la organización o la parte responsable
de ejecutar el proceso con un nombre similar: adquiriente, proveedor, entidad a cargo de la
implementación, entidad a cargo del mantenimiento y operador.
Otros pocos términos se aplican a las organizaciones en esta Norma: "usuario" puede ser la
organización que se beneficia de la utilización del producto o servicio software; "cliente"
se refiere al usuario y al adquiriente colectivamente; "parte involucrada" se refiere a una
organización que tiene interés en el éxito del proyecto.
Los procesos de esta Norma forman un conjunto completo que sirve a distintas
organizaciones. Una organización, pequeña o grande, que depende de su propósito de
negocio o de su estrategia de adquisición, puede seleccionar un conjunto adecuado de
procesos (y actividades y tareas asociadas) para cumplir dicho propósito. Una organización
puede realizar un proceso o más de un proceso. Bajo un contrato o la aplicación de esta
Norma, una parte determinada no debería realizar ambos procesos, el de adquisición y el
de suministro, pero puede realizar otros procesos. Un proceso puede ser ejecutado por una
organización o más de una organización. Un ejemplo de un proceso ejecutado por más de
una organización es el proceso de revisión del software.
Esta Norma está proyectada para su aplicación interna por parte de una organización, o
externamente por dos o más organizaciones. Cuando se aplique internamente, las dos
partes del acuerdo por lo general actúan bajo los términos de un acuerdo que puede variar
en formalidad, bajo circunstancias diferentes. Cuando se aplique externamente, las dos
partes del acuerdo por lo general actúan bajo los términos de un contrato. Con el fin de
facilitar la aplicación de esta Norma bien sea interna o contractualmente; las tareas se
expresan en lenguaje contractual. Cuando se aplique internamente, en lenguaje contractual
se ha de interpretar como disciplina autoimpuesta.
Para el propósito de esta Norma, se asume que cualquier proyecto se ejecuta dentro del
contexto de una organización. Esto es importante porque un proyecto de software depende
de varios resultados producidos por los procesos del negocio de la organización, por
ejemplo empleados para dotar de personal al proyecto y recursos para albergar el proyecto.
Para este fin, esta Norma proporciona un conjunto de procesos "que habilitan el proyecto
organizacional". No se asume que estos procesos son adecuados para operar un negocio ni
se asume que algún Proceso de Proyecto individual esté totalmente definido. En su lugar,
los procesos, considerados como grupo, están proyectados para establecer un conjunto
mínimo de dependencias que el proyecto establece sobre la organización.
En algunos casos, los proyectos pueden ser ejecutados por una organización que no tiene
un conjunto adecuado de procesos adoptados a nivel organizacional. Tal proyecto puede
aplicar las disposiciones de esta Norma directamente.
5.1.5 Adaptación
El Anexo A, que es Normativo, define las actividades básicas necesarias para realizar la
adaptación de esta Norma.
Debería notarse que la adaptación puede disminuir el valor percibido de una declaración de
conformidad con esta Norma. Esto se debe a que es difícil que otras organizaciones
comprendan el grado hasta el cual la adaptación puede haber eliminado disposiciones
deseables. Una organización que afirma una declaración de conformidad de una sola parte
con esta Norma puede encontrar ventajoso declarar la conformidad absoluta con una lista
más pequeña de procesos y no con una conformidad adaptada con una lista más grande de
procesos.
En esta Norma, los procesos, sus actividades y tareas se organizan en una secuencia
adecuada para la exposición. Esta secuencia de posición no prescribe ni dictamina ninguna
secuencia que dependa del tiempo. Por la carencia de un consenso sobre una secuencia
universal que dependa del tiempo o sobre su utilización, el usuario de esta Norma puede
seleccionar y solicitar los procesos, las actividades y las tareas según sean adecuadas y
efectivas. Esta Norma fomenta la iteración entre las actividades y la recurrencia dentro de
una actividad, para compensar los efectos de cualquier secuencia implicada de actividades
y tareas. Las partes bajo esta Norma son responsables de seleccionar un modelo del ciclo
de vida para el proyecto y el mapeo de procesos, actividades y tareas sobre ese modelo.
Las organizaciones que están involucradas en cualquier proceso del ciclo de vida realizan
evaluaciones de los productos de las tareas. Los procesos de Verificación de Software y
Validación de Software brindan la oportunidad para evaluaciones adicionales. Estos
procesos son conducidos por el adquiriente, el proveedor o una parte independiente con el
fin de verificar y validar los productos, con profundidad variable dependiendo del
proyecto. Estas evaluaciones no duplican ni reemplazan a otras valoraciones, sino que las
complementan. Oportunidades adicionales para la evaluación son proporcionadas por los
procesos de Revisión del Software, Auditoría del Software, Aseguramiento de la Calidad
del Software y los Procesos de Gestión de Modelo de Ciclo de Vida.
Esta Norma establece un marco para el ciclo de vida del software. El ciclo de vida empieza
con una idea o una necesidad que se puede satisfacer total o parcialmente mediante el
software, y termina con el retiro del software. La arquitectura se conforma con un conjunto
de procesos e interrelaciones entre esos procesos. La determinación de los procesos del
ciclo de vida se basa en dos principios básicos: cohesión y responsabilidad.
Cohesión: los procesos del ciclo de vida son cohesivos y acoplados hasta el grado óptimo
que se considera práctico y viable.
Los procesos de esta Norma se describen de manera similar a la ISO/IEC 15288 2 con el
fin de facilitar el uso de ambas Normas en una sola organización o en un solo proyecto.
Las actividades son un listado de acciones que se utilizan para obtener los
resultados.
Además de estos atributos básicos, los procesos se pueden caracterizar mediante otros
atributos comunes a todos los procesos. La ISO/IEC 15504-2 3 identifica atributos
comunes del proceso que caracterizan seis niveles de logro dentro de un marco de
medición de la capacidad del proceso. El Anexo B de esta Norma incluye el listado de los
atributos del proceso que contribuyen al logro de niveles más altos de capacidad del
proceso, según se define en la ISO/IEC 15504-2 3 .
Cada proceso de esta Norma satisface los criterios descritos anteriormente. Para el
propósito de una descripción clara, en ocasiones los procesos se descomponen en partes
más pequeñas. Algunos procesos se dividen en actividades y/o procesos de nivel inferior.
Un proceso de nivel inferior se describe cuando la parte separada del proceso satisface los
criterios para ser un proceso. Una actividad se utiliza cuando la unidad descompuesta no
califica como proceso. Una actividad puede considerarse simplemente como un grupo de
tareas (ver abajo).
Esta Norma no exige el uso de ningún modelo particular de ciclo de vida. Sin embargo,
exige que cada proyecto defina un modelo adecuado de ciclo de vida, de preferencia uno
que haya sido definido por la organización para su utilización en una variedad de
proyectos. La aplicación de un modelo de ciclo de vida proporciona los medios para
establecer la secuencia dependiente del tiempo necesaria para la gestión del proyecto.
Además, esta Norma no exige el uso de ningún conjunto particular de etapas. Un ejemplo
de conjunto de etapas para el ciclo de vida de un sistema incluye: concepto, desarrollo,
producción, utilización, soporte y retiro. Un ejemplo de conjunto de etapas para un ciclo de
vida de un producto software comprende desarrollo, operación y mantenimiento.
Se han descrito varios tipos o clases de modelos de ciclo de vida. Los ejemplos de estos
ciclos se conocen con nombres tales como cascada, desarrollo creciente, desarrollo
evolutivo y espiral. Cabe anotar que la simple selección del nombre de un tipo de modelo
no satisface el requisito de definir un modelo compuesto de etapas, propósito y resultados
definidos que se obtienen a través de los procesos de esta Norma.
NOTA: Un futuro informe técnico (ISO/IEC TR 24748) brindará detalles adicionales con respecto a
los modelos y las etapas del ciclo.
Esta Norma agrupa las actividades que se pueden ejecutar durante el ciclo de vida de un
sistema software en siete grupos de procesos. Cada uno de los procesos del ciclo de vida
dentro de estos grupos se describe en términos de su propósito y de los resultados que se
buscan y listan las actividades y tareas que se deben realizar para alcanzar esos resultados.
El propósito y los resultados de los procesos del ciclo de vida constituyen un Modelo de
Proceso de Referencia
Estos grupos de procesos del ciclo de vida se describen más adelante y se ilustran en la
Figura 1 .
Proceso de
Proceso de Proceso de Diseño Proceso de Diseño
Aseguramiento de
Gestión de Arquitectural del Arquitectural del
la Calidad del
Decisiones Sistema (apartado Software
Software
Procesos (apartado 6.3.3) 6.4.3) (apartado 7.1.3)
(apartado 7.2.3)
Organizacionales
de Habilitación Proceso de Proceso de Diseño Proceso de
Proceso de
Gestión del Detallado del Verificación del
del Proyecto Riesgo
Implementación
Software Software
(apartado 6.4.4)
(apartado 6.3.4) (apartado 7.1.4) (apartado 7.2.4)
Proceso de
Proceso de Proceso de Proceso de Proceso de
Gestión del
Gestión de la Integración del Construcción del Validación del
Modelo de Ciclo
Configuración Sistema (apartado Software Software
de Vida
(apartado 6.3.5) 6.4.5) (apartado 7.1.5) (apartado 7.2.5)
(apartado 6.2.1)
Proceso de
Proceso de Proceso de Proceso de Proceso de
Pruebas de
Gestión de la Gestión de la Integración del Revisión del
Calificación del
Infraestructura Información Software Software
Sistema (apartado
(apartado 6.2.2) (apartado 6.3.6) (apartado 7.1.6) (apartado 7.2.6)
6.4.6)
Proceso de Proceso de
Proceso de Proceso de
Gestión del Proceso de Pruebas de
Instalación del Auditoría del
Portafolio del Medición Calificación del
Software Software
Proyecto (apartado 6.3.7) Software
(apartado 6.4.7) (apartado 7.2.7)
(apartado 6.2.3) (apartado 7.1.7)
Proceso de Proceso de
Gestión de la Operación del
Calidad Software Procesos de Reutilización del Software
(apartado 6.2.5) (apartado 6.4.9)
Proceso de
Proceso de Proceso de
Gestión de
Mantenimiento del Ingeniería de
Programas de
Software Dominio (apartado
Reutilización
(apartado 6.4.10) 7.3.1)
(apartado 7.3.3)
Proceso de Gestión
Proceso de Retiro
de Activos de
del Software
Reutilización
(apartado 6.4.11)
(apartado 7.3.2)
Los resultados del proceso se utilizan para demostrar el logro exitoso del propósito de un
proceso. Esto facilita a los evaluadores del proceso la determinación de la capacidad del
proceso implementado de la organización y proporcionar material fuente para planificar la
mejora de los procesos organizacionales.
Para facilitar el uso simultáneo de la ISO/IEC 15288 2 y la ISO/IEC 12207 4 , los procesos
correspondientes al capítulo 6 tiene los mismos números de apartado (en el nivel 6.x.x).
Estos procesos definen las actividades necesarias para establecer un acuerdo entre dos
organizaciones. Si se invoca el Proceso de Adquisición, este proporciona los medios para
hacer negocios con un proveedor de productos, que son proporcionados para uso como
sistema operacional, de servicios en soporte de un sistema operacional o de elementos de
un sistema que está siendo desarrollado por un proyecto. Si se invoca el Proceso de
Suministro, este proporciona los medios para ejecutar un proyecto cuyo resultado es un
producto o servicio que se entrega al adquiriente.
Existen dos categorías de Procesos de Proyecto. Los Procesos de Gestión del Proyecto se
utilizan para planificar, ejecutar, evaluar y controlar el avance de un proyecto. Los
Procesos de Soporte del Proyecto dan soporte a los objetivos especializados de la gestión.
Ambos se describen a continuación.
Los Procesos de Gestión del Proyecto se utilizan para establecer y desarrollar planes del
proyecto, para evaluar el logro real y el progreso frente a los planes y para controlar la
ejecución del proyecto hasta su cumplimiento. Los Procesos de Gestión del Proyecto
individual se pueden invocar en cualquier momento del ciclo de vida y en cualquier nivel
en una jerarquía de proyectos, según lo exijan los planes del proyecto o los eventos no
previstos. Los Procesos de Gestión del Proyecto se aplican con un nivel de rigor y
formalidad que depende del riesgo y la complejidad del proyecto.
e) Proceso de Medición.
En general, los Procesos de Soporte del Proyecto proporcionados en esta Norma son
idénticos a los Procesos de Soporte del Proyecto establecidos en la ISO/IEC 15288 2 , salvo
por algunas diferencias en el formato. En varios casos, los Procesos de Soporte del
Software pueden tener una relación con los Procesos Soporte del Proyecto.
Los Procesos Técnicos se utilizan para definir los requisitos para un sistema, para
transformar los requisitos en un producto eficaz, para permitir la reproducción consistente
del producto cuando sea necesario, usar el producto, brindar los servicios exigidos,
sostenerla prestación de esos servicios y disponer del producto cuando se retire del servicio.
Los Procesos Técnicos definen las actividades que habilitan las funciones organizacionales
del proyecto con el fin de optimizar los beneficios y reducir los riesgos que se presentan
debido a las decisiones y las acciones técnicas. Estas actividades permiten que los
productos y los servicios posean la puntualidad y la disponibilidad, el rendimiento y la
funcionalidad, confiabilidad, mantenibilidad, producibilidad, usabilidad y otros atributos
requeridos por las organizaciones adquiriente y suministradora. También permiten que los
productos y los servicios estén conformes con las expectativas o los requisitos legales de la
sociedad, incluyendo salud, protección, seguridad y factores ambientales.
En general, los Procesos Técnicos provisto en esta Norma son especializaciones adecuadas
al software o contribuciones a los resultados de los Procesos Técnicos estipulados en la
ISO/IEC 15288 2 . Muchos parecen similares a los Procesos de Implementación del
Software, pero conservan diferencias cruciales, por ejemplo, el Análisis de Requisitos del
Sistema y el Análisis de Requisitos del Software empiezan desde puntos distintos y tienen
audiencias diferentes.
Los Procesos de Implementación del Software se utilizan para producir un elemento del
sistema especificado (elemento de software) implementado en el software. Estos procesos
transforman comportamiento especificado, interfaces y restricciones de implementación en
acciones de implementación, que dan como resultado un elemento del sistema que
satisface los requisitos derivados de los requisitos del sistema.
El Grupo de Procesos de Reutilización del Software consta de tres procesos que dan
soporte a la capacidad de una organización para reutilizar los elementos de software a
través de los límites del proyecto. Estos procesos son únicos porque, debido a su
naturaleza, operan fuera de los límites de cualquier proyecto en particular.
declaración de las metas del desempeño de cada proceso. Esta declaración de objetivos
permite la evaluación de la eficacia de los procesos de manera distinta a la simple
evaluación de conformidad. Por ejemplo, se pueden evaluar definiciones de procesos
nuevos frente a las declaraciones de Propósito y Resultados del Anexo B en lugar de
hacerlo frente a las disposiciones detalladas en el texto principal de esta Norma.
NOTA 1: En esta Norma, la expresión "Modelo de Proceso de Referencia" se utiliza con el mismo
significado que se indica en ISO/IEC 15504-2 3 .
NOTA 2: El MPR está destinado para ser usado en el desarrollo de un modelo o modelos de
evaluación, para evaluar procesos usando la ISO/IEC 15504-2 3 .
6.1.1.1 Propósito
El propósito del Proceso de Adquisición es obtener el producto y/o servicio que satisface la
necesidad expresada por el adquiriente. El proceso empieza con la identificación de las
necesidades del cliente y finaliza con la aceptación del producto y/o servicio que necesita
el adquiriente.
6.1.1.2 Resultados
El adquiriente debe implementar las siguientes actividades, de acuerdo con las políticas y
procedimientos de la organización aplicables, con respecto al Proceso de Adquisición.
NOTA: Las actividades y tareas en este proceso se pueden aplicar a uno o más proveedores.
6.1.1.3.1.2 El adquiriente debe definir y analizar los requisitos del sistema. Los
requisitos del sistema deberían incluir requisitos del negocio, organizativos y del usuario,
así como los de protección, seguridad y otros requisitos de criticidad junto con las normas
y procedimientos de diseño, prueba y conformidad relacionados.
6.1.1.3.1.5 Los Procesos Técnicos (apartado 6.4) se deberían utilizar para realizar las
tareas de los apartados 6.1.1.3.1.2 y 6.1.1.3.1.4. El adquiriente puede utilizar el Proceso de
Definición de Requisitos de las Partes Interesadas para establecer los requisitos del cliente.
a) Comprar un producto software “listo para usar” que satisfaga los requisitos.
d) Una combinación de a, b y c .
f) Riesgos considerados, así como los métodos para gestionar dichos riesgos.
e) Términos y condiciones.
f) Control de subcontratos.
NOTA: Esto puede incluir la asociación de la gestión de la cadena de suministro que intercambia
información entre los proveedores relacionados y los adquirientes con el fin de alcanzar un enfoque
armónico o colectivo para aspectos comerciales y técnicos comunes.
6.1.1.3.3 Selección del proveedor. Esta actividad consta de las siguientes tareas:
6.1.1.3.4 Acuerdo del contrato. Esta actividad consta de las siguientes tareas:
6.1.1.3.4.3 Una vez el contrato entra en vigencia, el adquiriente debe controlar los
cambios en el contrato a través de la negociación con el proveedor como parte de un
mecanismo de control de cambios. Los cambios en el contrato se deben investigar para
determinar el impacto en los planes, costos, beneficios, calidad y cronograma del proyecto.
NOTA 2: El acuerdo entre el adquiriente y el proveedor debería expresar claramente las expectativas,
responsabilidades y obligaciones de ambas partes.
NOTA 3: El mecanismo de control de cambios del contrato debería tratar las funciones de gestión del
cambio y las responsabilidades, el nivel de formalidad de las solicitudes de los cambios propuestos y
la renegociación del contrato, así como la comunicación de las partes interesadas afectadas. El anexo
informativo F contiene una muestra del proceso de gestión de cambios del contrato que se puede
utilizar para sustentar este aspecto.
6.1.1.3.5 Seguimiento del acuerdo. Esta actividad consta de las siguientes tareas:
NOTA: El adquiriente puede instalar el producto software o ejecutar el servicio software de acuerdo
con las instrucciones definidas por el proveedor.
NOTA 1: Cuando el producto o servicio proporcionado ha satisfecho las condiciones del acuerdo e
identificado que se han cerrado de manera satisfactoria los elementos pendientes, el adquiriente
concluye el acuerdo mediante la entrega del pago u otra consideración acordada y la notificación de la
conclusión del acuerdo.
6.1.2.1 Propósito
6.1.2.2 Resultados
El proveedor debe implementar las siguientes actividades, de acuerdo con las políticas y
procedimientos de la organización aplicables, con respecto al Proceso de Suministro.
NOTA: Para un producto o servicio desarrollado por clientes, un agente, por ejemplo, una función de
mercadeo dentro de la organización proveedora, puede representar al adquiriente.
6.1.2.3.2 Licitación del proveedor. Esta actividad consta de las siguientes tareas:
6.1.2.3.2.2 El proveedor debería tomar una decisión para hacer una oferta o aceptar el
contrato.
6.1.2.3.3.2 El proveedor puede solicitar la modificación del contrato como parte del
mecanismo de control de cambio.
6.1.2.3.4 Ejecución del contrato. Esta actividad consta de las siguientes tareas:
6.1.2.3.4.3 El proveedor debe establecer los requisitos para los planes de gestión y
aseguramiento del proyecto y, para asegurar la calidad del producto o servicio software
entregable. Los requisitos para los planes deberían incluir necesidades de recurso y
compromiso del adquiriente.
6.1.2.3.4.4 Una vez que los requisitos de planificación son establecidos, el proveedor
debe considerar las opciones para desarrollar el producto software o proveer el servicio
software considerando un análisis de riesgo asociado con cada opción. Las opciones
incluyen:
c) Obtener los productos de software “listo para usar” de las fuentes internas o
externas.
NOTA: Los elementos considerados en el plan incluyen, pero no están limitados a lo siguiente:
i) La participación del adquiriente; por medios tales como revisiones (véase apartado 7.2.6),
auditorías (véase apartado 7.2.7), reuniones informales, informe, modificación y cambio;
implementación, aprobación, aceptación, y acceso a instalaciones.
j) La participación del usuario; por medios tales como ejercicios para establecer requisitos,
demostraciones de prototipos y evaluaciones.
k) La gestión del riesgo; que es, la gestión de las áreas del proyecto que involucran riesgos
potenciales técnicos, de costo o de cronograma.
l) La política de seguridad; que es, las reglas para la “necesidad de saber” y el “acceso a la
información” de cada nivel de organización del proyecto.
6.1.2.3.4.11 El proveedor debe interactuar con otras partes tal como se especifica en el
contrato y en los planes del proyecto.
6.1.2.3.4.13 El proveedor debe realizar o apoyar las reuniones informales, las revisiones
de aceptación, las pruebas de aceptación, las revisiones conjuntas y las auditorías con el
adquiriente tal como se especifica en el contrato y en los planes del proyecto. Las
revisiones conjuntas deben realizarse de acuerdo con el apartado 7.2.6 y las auditorías de
acuerdo con el apartado 7.2.7 .
NOTA: Cuando se requiera en el acuerdo, el proveedor debería instalar el producto de acuerdo con los
requisitos establecidos.
NOTA: El acuerdo debería indicar términos y autorización para iniciar el cierre del proyecto.
6.2.1.1 Propósito
El propósito del Proceso de Gestión del Modelo de Ciclo de Vida es definir, mantener y
asegurar la disponibilidad de políticas, procesos del ciclo de vida, modelos de ciclo de vida
y procedimientos para uso de la organización con respecto al alcance de esta Norma.
Este proceso proporciona políticas, procesos y procedimientos del ciclo de vida que son
consistentes con los objetivos de la organización, los cuales son definidos, adaptados,
mejorados y mantenidos para dar soporte a las necesidades del proyecto individual dentro
del contexto de la organización, y son capaces de ser aplicados utilizando métodos y
herramientas eficaces y probadas.
6.2.1.2 Resultados
Como resultado de la implementación exitosa del Proceso de Gestión del Modelo del Ciclo
de Vida:
c) los procesos, modelos y procedimientos del ciclo de vida para utilizarse por
la organización son definidos, mantenidos y mejorados; y
La organización debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión del
Modelo del Ciclo de Vida.
6.2.1.3.2 Evaluación del Proceso. Esta actividad consta de las siguientes tareas:
6.2.1.3.3 Mejora del proceso. Esta actividad consta de las siguientes tareas:
6.2.1.3.3.1 La organización debe efectuar las mejoras en los procesos que considera
necesarios de acuerdo al resultado de la evaluación y la revisión del proceso. La
documentación del proceso debería estar actualizada para reflejar la mejora en los procesos
organizativos.
6.2.1.3.3.3 Los datos del costo de calidad se deberían recolectar, mantener y utilizar
para mejorar los procesos de la organización como una actividad de la gestión. Estos datos
deben servir para establecer el costo tanto de la prevención como de la solución de
problemas y de la no conformidad en los productos y servicios software.
6.2.2.1 Propósito
6.2.2.2 Resultados
NOTA: Los elementos de la infraestructura pueden incluir hardware, software, métodos, herramientas,
técnicas, normas e instalaciones para el desarrollo, operación o mantenimiento.
La organización debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión de la
Infraestructura.
6.2.2.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
6.2.3.1 Propósito
El propósito del Proceso de Gestión del Portafolio del Proyecto es iniciar y sostener los
proyectos necesarios, suficientes y adecuados con el fin de satisfacer los objetivos
estratégicos de la organización.
6.2.3.2 Resultados
Como resultado de la implementación exitosa del Proceso de Gestión del Portafolio del
Proyecto:
d) los proyectos que cumplen los requisitos del acuerdo y de las partes
interesadas son respaldados; y
e) los proyectos que no cumplen los requisitos del acuerdo o de las partes
interesadas son redirigidos o finalizados.
La organización debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de Gestión
del Portafolio del Proyecto.
6.2.3.3.1 Inicio del proyecto. Esta actividad consta de las siguientes tareas:
NOTA: Priorizar los proyectos que se van a iniciar y establecer los umbrales para determinar cuáles
proyectos se van a ejecutar.
6.2.3.3.1.4 La organización debe asignar los recursos para alcanzar los objetivos del
proyecto.
6.2.3.3.1.5 La organización debe identificar todas las interfaces entre los múltiples
proyectos que deben ser administradas o soportadas por el proyecto.
NOTA: Esto incluye el uso de los sistemas de habilitación utilizados por más de un proyecto y el uso
de elementos del sistema común por más de un proyecto.
6.2.3.3.1.6 La organización debe especificar los requisitos de los informes del proyecto
y los hitos de revisión que controlarán la ejecución del proyecto.
6.2.3.3.2 Evaluación del portafolio. Esta actividad consta de las siguientes tareas:
6.2.3.3.2.1 La organización debe evaluar los proyectos en curso para confirmar que:
6.2.3.3.2.2 La organización debe actuar para continuar o redirigir los proyectos que
están avanzando satisfactoriamente o que se espera progresen de forma satisfactoria,
mediante una redirección adecuada.
6.2.3.3.3 Cierre del proyecto. Esta actividad consta de las siguientes tareas:
6.2.3.3.3.1 La organización debe actuar para cancelar o suspender los proyectos cuyas
desventajas o riesgos para la organización superen los beneficios de una inversión
continua, cuando los acuerdos así lo permiten.
NOTA 1: La organización asegura que el cierre del proyecto explica la retención de la documentación
por parte de la organización después de cerrar el proyecto.
NOTA 2: Después del cierre del proyecto, la organización puede autorizar la liberación del proyecto
del portafolio de proyectos.
6.2.4.1 Propósito
6.2.4.2 Resultados
La organización debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión de los
Recursos Humanos.
6.2.4.3.1.1 Se debe llevar a cabo una revisión de los requisitos de la organización y del
proyecto para establecer y proporcionar oportunamente la adquisición o desarrollo de los
recursos y habilidades requeridas por el personal administrativo y técnico. Estas
necesidades se pueden satisfacer a través de entrenamiento, contratación y otros
mecanismos de desarrollo del personal.
6.2.4.3.3.2 Definir criterios objetivos que se pueden utilizar para evaluar el desempeño
del personal.
6.2.4.3.3.3 Evaluar el desempeño del personal con respecto a sus contribuciones en las
metas de la organización o el proyecto.
6.2.4.3.3.5 Mantener registros adecuados del desempeño del personal que incluya
información sobre las habilidades, entrenamientos realizados y evaluaciones de
desempeño.
NOTA: Se debería resolver los conflictos que se presenten en las demandas de recursos de los
proyectos múltiples.
6.2.4.3.3.7 Potenciar a los equipos para cumplir con su función asegurando que tengan:
b) Una visión o sentido compartido de los intereses comunes para el éxito del
proyecto.
6.2.4.3.4 Gestión del conocimiento. Esta actividad consta de las siguientes tareas:
6.2.4.3.4.1 La organización debe planificar los requisitos para gestionar los activos de
conocimiento de la organización. La planificación debe incluir la definición de la
infraestructura y el entrenamiento para apoyar a los colaboradores y los usuarios de los
activos de conocimiento de la organización, el esquema de clasificación para los activos y
los criterios de los activos.
6.2.5.1 Propósito
El propósito del Proceso de Gestión de la Calidad es asegurar que los productos, servicios
e implementaciones de los procesos del ciclo de vida satisfagan los objetivos de calidad de
la organización y logren la satisfacción del cliente.
6.2.5.2 Resultados
La organización debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de Gestión
de la Calidad.
NOTA 1: En la ISO 9001:2000 se puede encontrar un modelo de procesos para el sistema de gestión
de la calidad. Para las organizaciones que desean avanzar mas allá de la ISO 9001:2000 en busca de la
mejora continua del desempeño, en la ISO 9004:2000 6 se brindan las directrices.
NOTA 2: Las directrices para la aplicación de la ISO 9001:2000 al software se pueden encontrar en la
ISO/IEC 90003:2004 7.
6
La NTP-ISO 9004:2001 es equivalente a la ISO 9004:2000 .
7
La NTP-ISO/IEC 90003:2008 (revisada el 2013) es equivalente a la ISO/IEC 90003:2004 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 59 de 220
NOTA: Se debe asegurar que se hayan establecido los objetivos de la calidad basado en los requisitos
de las partes interesadas de cada proyecto.
6.3.1.1 Propósito
El propósito del Proceso de Planificación del Proyecto es producir y comunicar los planes
de proyecto eficaces y viables.
Este proceso determina el alcance de la gestión del proyecto y de las actividades técnicas,
identifica las salidas del proceso, tareas del proyecto y entregables, establece los
cronogramas para realizar las tareas del proyecto, incluyendo los criterios del logro, y los
recursos necesarios para cumplir las tareas del proyecto.
6.3.1.2 Resultados
b) la factibilidad del logro de las metas del proyecto con los recursos y las
restricciones disponibles es evaluada;
d) las interfaces entre los elementos del proyecto con otros proyectos y
unidades organizativas son identificadas;
El administrador debe implementar las siguientes actividades de acuerdo con las políticas y
los procedimientos aplicables a la organización con respecto al Proceso de Planificación
del Proyecto:
6.3.1.3.1 Iniciación del proyecto. Esta actividad consta de las siguientes tareas:
6.3.1.3.1.1 El administrador debe establecer los requisitos del proyecto a los que se
comprometen.
NOTA: El establecimiento de los requisitos incluye la identificación de los objetivos del proyecto,
motivaciones y límites.
6.3.1.3.1.2 Una vez se han establecido los requisitos del proyecto, el administrador
debe establecer la factibilidad del proyecto verificando que los recursos (personal,
materiales, tecnología y ambiente) requeridos para ejecutar y administrar el proyecto estén
disponibles, sean adecuados y convenientes, y que los plazos considerados para su
terminación se puedan cumplir.
6.3.1.3.1.3 Según sea necesario, y por acuerdo de todas las partes interesadas, los
requisitos del proyecto se pueden modificar en este punto para lograr el criterio de
terminación.
6.3.1.3.2 Planificación del proyecto. Esta actividad consta de las siguientes tareas:
6.3.1.3.2.1 El administrador debe preparar los planes de la ejecución del proyecto. Los
planes asociados con la ejecución del proyecto deben contener las descripciones de las
actividades y tareas asociadas en la identificación de los productos software que se van a
proveer.
d) Asignación de tareas
e) Designación de responsabilidades
NOTA: Los modelos organizacionales para uso de los proyectos se deberían proporcionar a través del
Proceso de Gestión del Modelo de Ciclo de Vida.
6.3.1.3.3 Activación del proyecto. Esta actividad consta de las siguientes tareas:
6.3.2.1 Propósito
El propósito del Proceso de Evaluación y Control del Proyecto es determinar el estado del
proyecto y asegurar que éste se ejecuta de acuerdo con los planes y los cronogramas, y
dentro de los presupuestos proyectados, y además satisface los objetivos técnicos.
Este proceso incluye la redirección de las actividades del proyecto, según corresponda,
para corregir las desviaciones y variaciones identificadas con respecto a otros procesos de
gestión de proyecto o procesos técnicos. La redirección puede incluir replanificar cuando
sea apropiado.
6.3.2.2 Resultados
b) las interfaces entre los elementos del proyecto y con otros proyectos y
unidades organizativas son monitoreados;
c) las acciones para corregir las desviaciones con respecto al plan y para
prevenir la recurrencia de problemas identificados en el proyecto son
tomadas, cuando no se cumplen los objetivos del proyecto; y
El administrador debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Evaluación y
Control del Proyecto.
NOTA: El administrador asegura que las interfaces internas de los elementos del proyecto, así como
las interfaces con otros proyectos pertinentes y unidades organizativas, se monitorean durante esta
actividad.
6.3.2.3.2 Control del proyecto. Esta actividad consta de las siguientes tareas:
6.3.2.3.3 Evaluación del proyecto. Esta actividad consta de las siguientes tareas:
6.3.2.3.3.1 El administrador debe asegurar que los productos software y los planes se
evalúen con respecto a la satisfacción de los requisitos.
NOTA: El administrador utiliza los resultados de la evaluación para tomar medidas para prevenir la
recurrencia futura de problemas identificados en el proyecto.
6.3.2.3.4 Cierre del proyecto. Esta actividad consta de las siguientes tareas:
6.3.2.3.4.1 Cuando se han terminado todos los productos software, actividades y tareas,
el administrador debe determinar si el proyecto está finalizado, teniendo en cuenta los
criterios que se especifican en el contrato, o como parte del procedimiento de la
organización.
6.3.3.1 Propósito
Este proceso responde a una solicitud de una decisión encontrada durante el ciclo de vida
del sistema, cualquiera sea su naturaleza o fuente, con el fin de alcanzar el resultado
especificado, deseable y óptimo. Las acciones alternativas se analizan y se selecciona y
dirige un curso de acción. Las decisiones y su justificación se registran para sustentar la
futura toma de decisiones.
6.3.3.2 Resultados
El proyecto debe implementar las siguientes las siguientes actividades de acuerdo con las
políticas y procedimientos aplicables a la organización con respecto al Proceso de Gestión
de Decisiones.
NOTA: Esto incluye la identificación de las categorías de decisión y un esquema de priorización, así
como la identificación de las partes responsables. Los decisores son identificados y se les asigna la
responsabilidad y autoridad para la toma de decisiones. Las decisiones se pueden originar como
resultado de una nueva evaluación de eficacia, una compensación técnica, un problema que necesita
solución, una acción necesaria como respuesta a un riesgo que excede el umbral aceptable, una nueva
oportunidad o la aprobación para el avance del proyecto a la siguiente etapa del ciclo de vida. La
estrategia de toma de decisiones incluye la identificación y la asignación de responsabilidades en las
decisiones y autoridad para tomarlas.
6.3.3.3.1.3 El proyecto debe identificar las circunstancias y las necesidades para una
decisión.
NOTA: Registre, clasifique y, reporte de manera inmediata y objetiva los problemas o las
oportunidades, así como los cursos de acción alternativos que solucionarán su resultado.
6.3.4.1 Propósito
El propósito del Proceso de Gestión del Riesgo es identificar, analizar y monitorear los
riesgos continuamente.
El proceso de Gestión del Riesgo es un proceso continuo y sistemático que trata los riesgos
durante todo el ciclo de vida de un sistema o de un producto o servicio software. Se puede
aplicar a los riesgos relacionados con la adquisición, el desarrollo, el mantenimiento o la
operación de un sistema.
6.3.4.2 Resultados
d) los riesgos son analizados y la prioridad con la cual aplicar los recursos para
el tratamiento de estos riesgos es determinada;
e) las medidas de los riesgos para determinar los cambios en el estado del
riesgo y el progreso de las actividades de tratamiento son definidas,
aplicadas y evaluadas; y
f) el tratamiento adecuado para corregir o evitar el impacto del riesgo con base
en su prioridad, probabilidad y consecuencia u otro umbral de riesgo
definido es realizado.
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y los procedimientos de la organización aplicables con respecto al Proceso de
Gestión del Riesgo.
NOTA: La ISO/IEC 16085, Risk Management Process, provee un conjunto más detallado de
actividades y tareas que están alineadas con las actividades y tareas que se muestran a continuación.
6.3.4.3.1.1 Se deben definir las políticas de gestión del riesgo que describan las
directrices bajo las cuales se debe realizar la gestión del riesgo.
6.3.4.3.1.2 Se debe documentar una descripción del Proceso de Gestión del Riesgo que
se va a implementar.
6.3.4.3.1.3 Se debe identificar a las partes responsables de llevar a cabo la gestión del
riesgo así como sus funciones y responsabilidades.
6.3.4.3.1.4 Se debe proveer con recursos adecuados a las partes responsables para
ejecutar el Proceso de Gestión del Riesgo.
6.3.4.3.1.5 Se debe proporcionar una descripción del proceso para evaluar y mejorar el
Proceso de Gestión del Riesgo.
6.3.4.3.2 Gestión del perfil del riesgo. Esta actividad consta de las siguientes tareas:
6.3.4.3.2.1 Se debe definir y documentar el contexto del Proceso de Gestión del Riesgo.
NOTA: Esto incluye una descripción de las perspectivas de las partes interesadas, las categorías de
riesgos y una descripción (posiblemente por referencia) de los objetivos técnicos y gerenciales, los
supuestos y las restricciones.
6.3.4.3.2.2 Se debe documentar los umbrales del riesgo que definen las condiciones en
las que se puede aceptar un nivel de riesgo.
NOTA: El perfil de riesgo registra: el contexto de gestión del riesgo; un registro del estado de cada
uno de los riesgos que incluya su probabilidad, sus consecuencias y los umbrales del riesgo; la
prioridad de cada riesgo con base en los criterios proporcionados por las partes interesadas, y las
solicitudes de acción para los riesgos junto con el estado de su tratamiento. El perfil de riesgo se
actualiza cuando existen cambios en el estado de un riesgo individual. La prioridad en el perfil de
riesgo se utiliza para determinar la aplicación de los recursos para el tratamiento.
6.3.4.3.3 Análisis del riesgo. Esta actividad consta de las siguientes tareas:
6.3.4.3.3.4 Para cada riesgo que esté por encima de su umbral, se deben definir y
documentar las estrategias de tratamiento recomendadas. También se deben definir y
documentar las medidas que indican la eficacia de las alternativas de tratamiento.
NOTA: Las estrategias de tratamiento del riesgo incluyen, entre otras, eliminación del riesgo,
reducción de su probabilidad de ocurrencia o de la gravedad de las consecuencias, o aceptación del
riesgo.
6.3.4.3.4 Tratamiento del riesgo. Esta actividad consta de las siguientes tareas:
6.3.4.3.4.2 Si las partes interesadas determinan que es conveniente tomar acciones para
que un riesgo sea aceptable, entonces se debe implementar una alternativa para el
tratamiento del riesgo.
6.3.4.3.4.3 Si las partes interesadas aceptan un riesgo que excede su umbral, este riesgo
se debe considerar de alta prioridad y se debe monitorear continuamente para determinar si
son necesarias acciones futuras de tratamiento del riesgo.
6.3.4.3.4.4 Una vez que se selecciona el tratamiento para un riesgo, este debe recibir las
mismas acciones de gestión que los problemas, de acuerdo con las actividades de
evaluación y control del apartado 6.3.2 de esta norma o de la ISO/IEC 15288 2 .
6.3.4.3.5 Monitoreo del riesgo. Esta actividad consta de las siguientes tareas:
6.3.4.3.5.3 Se debe monitorear continuamente el proyecto para los riesgos nuevos y las
fuentes a través de todo el ciclo de vida.
6.3.4.3.6 Evaluación del proceso de gestión de riesgos. Esta actividad consta de las
siguientes tareas:
6.3.4.3.6.1 Se debe reunir información durante todo el ciclo de vida del proyecto con el
fin de mejorar el Proceso de Gestión del Riesgo y generar lecciones aprendidas.
NOTA: La información del riesgo incluye los riesgos identificados, sus fuentes, sus causas, su
tratamiento y el éxito de los tratamientos seleccionados.
6.3.5.1 Propósito
6.3.5.2 Resultados
NOTA: El Proceso de Gestión de la Configuración del Software es una especialización del Proceso de
Gestión de la Configuración y se incluye en el grupo de procesos de soporte del software.
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de Gestión
de la Configuración.
NOTA: Esto incluye la definición de las autoridades para la disposición, el acceso, la liberación y el
control de los cambios en los elementos de la configuración; definición de los lugares y condiciones
de almacenamiento, su ambiente y, en el caso de la información, el medio de almacenamiento, de
acuerdo con los niveles asignados de integridad, seguridad y protección; definición de los criterios o
eventos para iniciar el control de la configuración y mantener las líneas base de las configuraciones en
evolución así como definir la estrategia de auditoría y las responsabilidades para asegurar la integridad
y la seguridad continuas de la información de definición de la configuración. Las actividades de
gestión de la configuración deberían ser compatibles con las directrices que se indican en la
ISO 10007 8 .
8
La NTP-ISO 10007:2004 (revisada el 2014) es equivalente a la ISO 10007 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 73 de 220
6.3.5.3.1.2 El proyecto debe identificar los elementos que están sujetos al control de
configuración.
NOTA: Los elementos se distinguen mediante marcas o identificadores únicos y durables, cuando
corresponda. Los identificadores están acordes con los estándares relevantes y los convenios del sector
del producto, de modo que se puede hacer seguimiento a los elementos bajo control de la
configuración de manera no ambigua hacia sus especificaciones o descripciones documentadas o
equivalente.
NOTA: Esto incluye tomar en cuenta la naturaleza de los elementos bajo control de configuración.
Las descripciones de la configuración deben cumplir, cuando sea posible, con los estándares del
producto o la tecnología. Asegurar que la información de la configuración permita la trazabilidad
hacia adelante y hacia atrás hacia otros estados de configuración con la línea base. Consolidar los
estados de evolución de la configuración de los elementos de configuración para formar líneas base
documentadas en momentos designados o bajo circunstancias definidas. Registrar la justificación para
la línea base y las autorizaciones asociadas en los datos de la línea base de la configuración. Mantener
registros de la configuración a través del ciclo de vida del sistema y archivarlos de acuerdo con los
acuerdos, la legislación pertinente o la mejor práctica industrial.
6.3.5.3.2.2 El proyecto debe asegurar que los cambios en las líneas base de la
configuración sean adecuadamente identificados, registrados, evaluados, aprobados,
incorporados y verificados.
NOTA: Consolidar los estados de configuración en evolución de los elementos de configuración para
formar líneas base documentadas en los momentos indicados o bajo circunstancias definidas.
Registrar las etapas de la configuración, la justificación para la línea base y las autorizaciones
asociadas en los datos de la línea base de configuración. Mantener registros de la configuración a
través del ciclo de vida del sistema y archivarlos de acuerdo con los acuerdos, la legislación relevante
o la mejor práctica industrial. Administrar los registros, recuperación y consolidación de los estados
de configuración actual y de los estados de todas las configuraciones anteriores para confirmar que la
información es correcta, oportuna, integra y segura. Realizar auditorías para verificar la conformidad
de la línea base con los esquemas, los documentos de control de interfaz y otros requisitos del
acuerdo.
6.3.6.1 Propósito
6.3.6.2 Resultados
NOTA: El Proceso de Gestión de la Documentación del Software es una especialización del Proceso
de Gestión de la Información y se incluye en el Grupo de Procesos de Soporte del Software.
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Gestión de la Información.
NOTA: La ISO/IEC 15289 resume los requisitos para los elementos de información (documentación)
y proporciona directrices sobre su desarrollo.
6.3.6.3.1.1 El proyecto debe definir los elementos de información que se van a manejar
durante el ciclo de vida del sistema, de acuerdo con la legislación o las políticas
organizacionales, y que se van a mantener durante un período definido posterior.
NOTA: La información se puede originar y puede finalizar de cualquier forma (por ejemplo, verbal,
textual, gráfica, numérica) y se puede almacenar, procesar, replicar y transmitir utilizando cualquier
medio (por ejemplo, electrónico, impreso, magnético, óptico). Se debe poner debida atención a las
restricciones de la organización, por ejemplo, infraestructura, comunicación entre organizaciones,
trabajo de proyectos distribuidos. Los estándares y convenios de almacenamiento de información
pertinente, transformación, transmisión y presentación, se utilizan de acuerdo con las restricciones
relacionadas con las políticas, acuerdos y legislación.
NOTA: Esto incluye revisiones del estado de la información almacenada para determinar su
integridad, validez y disponibilidad, así como las necesidades para replicación o transformación en un
medio alternativo. Considerar la necesidad de conservar tanto infraestructura como cambios de
tecnología de tal forma que los medios archivados se puedan leer o la necesidad de volver a registrar
los medios archivados utilizando nueva tecnología.
NOTA: Registrar el estado de los elementos de información, por ejemplo, descripción de la versión,
registro de distribución, clasificación de la seguridad. La información debería ser legible y
almacenarse y conservarse de forma tal que se pueda recuperar fácilmente en instalaciones que
provean un ambiente adecuado, y que prevenga el daño, deterioro y pérdida.
NOTA: Los medios, ubicación y protección de la información se seleccionan de acuerdo con los
períodos especificados de almacenamiento y recuperación, y con la política de la organización,
acuerdos y legislación. Asegurar que existan los acuerdos para conservar la documentación necesaria
después del cierre del proyecto.
6.3.7.1 Propósito
6.3.7.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y los procedimientos de la organización aplicables con respecto al Proceso de
Medición.
NOTA 1: ISO/IEC 15939, Software Measurement Process, proporciona un conjunto más detallado de
actividades y tareas que están alineados con las actividades y las tareas que se indican a continuación.
NOTA 2: El capítulo 8 de ISO 9001:2000 especifica los requisitos del Sistema de Gestión de la
Calidad para la medición y monitoreo de procesos y productos.
6.3.7.3.1.3 El proyecto debe seleccionar y documentar las medidas que satisfagan las
necesidades de información.
6.3.7.3.1.5 El proyecto debe definir los criterios para la evaluación de los productos de
información y del proceso de medición.
6.3.7.3.1.6 El proyecto debe revisar, aprobar y proveer los recursos para las tareas de
medición.
NOTA: El Proceso de Definición de los Requisitos de las Partes Interesadas de esta Norma es una
especialización del Proceso de Definición de los Requisitos de las Partes Interesadas de la
ISO/IEC 15288 2 . Los usuarios pueden considerar la declaración de conformidad con el proceso de la
ISO/IEC 15288 2 en lugar de hacerlo con el proceso de esta Norma.
6.4.1.1 Propósito
El propósito del Proceso de Definición de los Requisitos de las Partes Interesadas es definir
los requisitos para un sistema que puede proveer los servicios que los usuarios y otras
partes interesadas necesitan en un ambiente definido.
El proceso identifica a las partes interesadas o las clases de las partes interesadas,
involucradas con el sistema durante todo el ciclo de vida, y sus necesidades y deseos. Los
analiza y transforma en un conjunto común de requisitos de las partes interesadas, el cual
expresa la interacción prevista que el sistema tendrá con su ambiente operacional y que son
la referencia frente a la cual se valida cada servicio operacional resultante con el fin de
confirmar que el sistema satisface las necesidades.
6.4.1.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Definición de los Requisitos de las Partes Interesadas.
6.4.1.3.1.1 El proyecto debe identificar a las partes interesadas individuales o las clases
de las partes interesadas que tienen un interés legítimo en el sistema durante todo su ciclo
de vida.
NOTA: Esto incluye, pero no está limitado a usuarios, operadores, encargados del
soporte, desarrolladores, productores, entrenadores, encargados del mantenimiento,
encargados de la eliminación, organizaciones adquirientes y proveedoras, las partes
responsables de las entidades de interfaz externa, organismos de regulación y
miembros de la sociedad. Cuando no es viable la comunicación directa, por ejemplo,
para productos y servicios al consumidor, se seleccionan representantes o
representantes designados de las partes interesadas.
NOTA: Los requisitos de las partes interesadas describen las necesidades, carencias, deseos,
expectativas y restricciones percibidas de las partes interesadas identificadas. Se expresan en términos
de un modelo que puede ser textual o formal, el cual concentra el propósito del sistema y el
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 82 de 220
6.4.1.3.2.2 El proyecto debe definir las restricciones en una solución del sistema que
son consecuencias inevitables de los acuerdos existentes, las decisiones de la dirección y
las decisiones técnicas.
NOTA: Éstas pueden resultar de 1) casos o áreas de solución definida por la partes interesadas;
2) decisiones de implementación tomadas a niveles superiores en la estructura jerárquica del sistema;
3) uso exigido de sistemas de habilitación, recursos y personal definidos.
NOTA: Los escenarios se utilizan para analizar la operación del sistema en su ambiente previsto con
el fin de identificar los requisitos que pueden no haber sido especificados formalmente por alguna de
las partes interesadas, por ejemplo, obligaciones legales, reglamentarias y sociales. El contexto de uso
del sistema se identifica y analiza. Incluir en el análisis del contexto las actividades que los usuarios
realizan para lograr los objetivos del sistema, las características pertinentes de los usuarios finales del
sistema (por ejemplo, entrenamiento esperado, nivel de fatiga), el ambiente físico (por ejemplo,
iluminación disponible, temperatura) y todo equipo que se vaya a utilizar (por ejemplo, equipo
protector o de comunicaciones). Cuando corresponda, se analizan las influencias sociales y
organizacionales en los usuarios que podrían afectar el uso del sistema o restringir su diseño.
9
La NTP-ISO/IEC 9126-1 es equivalente a la ISO/IEC 9126-1 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 83 de 220
NOTA: Identificar los riesgos de seguridad y, si se justifica, especificar los requisitos y las funciones
para proporcionar seguridad. Esto incluye riesgos asociados con los métodos de operaciones y
soporte, salud y seguridad, amenazas a la propiedad e influencias ambientales. Utilizar estándares
aplicables, p.e., la IEC 61508 y prácticas profesionales aceptadas. Identificar los riesgos de seguridad
y, si se justifica, especificar todas las áreas aplicables de seguridad del sistema, incluyendo las físicas,
de procedimientos, comunicaciones, computadores, programas, datos y emisiones. Identificar las
funciones que pudieran tener impacto en la seguridad del sistema, incluyendo acceso y daños para el
personal, propiedades e información protegidos, compromiso de información sensitiva y negación del
acceso aprobado a la propiedad e información. Especificar las funciones de seguridad requeridas,
incluyendo la mitigación y contención, haciendo referencia a los estándares aplicables y las prácticas
profesionales aceptadas cuando sea obligatorio o pertinente.
6.4.1.3.4 Acuerdo sobre los requisitos. Esta actividad consta de las siguientes tareas.
NOTA: Esto incluye los requisitos que no se pueden llevar a cabo o cuyo logro es imposible.
NOTA: Explicar y obtener un acuerdo sobre las propuestas de solución de requisitos en conflicto,
imprácticos e inalcanzables.
6.4.1.3.4.3 El proyecto debe establecer con las partes interesadas que sus requisitos se
han expresado correctamente.
NOTA: Esto incluye la confirmación que los requisitos de las partes interesadas son comprensibles
para aquellos que los originaron y que la solución de los conflictos en los requisitos no han
desintegrado ni comprometido las intenciones de las partes interesadas.
6.4.1.3.5 Registro de los requisitos. Esta actividad consta de las siguientes tareas:
6.4.1.3.5.1 El proyecto debe registrar los requisitos de las partes interesadas de manera
adecuada para la gestión de los requisitos durante todo el ciclo de vida y posteriormente.
NOTA: Estos registros establecen la línea base de los requisitos de las partes interesadas y conservan
los cambios en las necesidades y su origen a través del ciclo de vida del sistema. Conforman la base
para la trazabilidad hacia los requisitos del sistema y forman una fuente de conocimiento de los
requisitos para sistemas y comunicaciones posteriores con las partes interesadas sobre el estado de los
requisitos.
NOTA: Los requisitos de las partes interesadas se revisan en momentos de decisiones clave en el ciclo
de vida para asegurar que se han tomado en cuenta todos los cambios de las necesidades.
NOTA: El Proceso de Análisis de los Requisitos del Sistema en esta Norma es una especialización del
Proceso de Análisis de Requisitos de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una
declaración de conformidad con el proceso de la 15288 en lugar del proceso de esta Norma.
6.4.2.1 Propósito
El propósito del Análisis de los Requisitos del Sistema es transformar los requisitos
definidos de las partes interesadas en un conjunto de requisitos técnicos del sistema
deseado que guiarán el diseño del sistema.
6.4.2.2 Resultados
Como resultado de la implementación exitosa del Análisis de los Requisitos del Sistema:
h) los requisitos del sistema a todas las partes afectadas y a la línea base son
comunicados.
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Análisis de los Requisitos del Sistema.
NOTA 2: Se debería comprender el impacto de los requisitos del sistema en el ambiente operativo.
NOTA 3: Se deberían priorizar, aprobar, establecer en la línea base y comunicar los requisitos del
sistema a todas las partes afectadas. Las actualizaciones a la línea base de los requisitos se deberían
evaluar para determinar el impacto técnico, de costos y cronograma.
6.4.2.3.2 Evaluación de los requisitos. Esta actividad consta de las siguientes tareas:
6.4.2.3.2.1 Los requisitos del sistema se deben evaluar considerando los criterios que se
listan a continuación. Los resultados de las evaluaciones deben estar documentados.
c) facilidad de prueba;
NOTA: Las necesidades de adquisición incluyen la línea base de los requisitos de las partes
interesadas.
NOTA: El Proceso de Diseño Arquitectural del Sistema de esta Norma es una especialización del
Proceso de Diseño de la Arquitectura de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer
una declaración de conformidad con el proceso 15288 en lugar de hacerlo con el proceso de esta
Norma.
6.4.3.1 Propósito
El propósito del Proceso de Diseño Arquitectural del Sistema es identificar los requisitos
del sistema que se deberían asignar a los elementos del sistema.
6.4.3.2 Resultados
a) se define un diseño arquitectural del sistema que identifica los elementos del
sistema y satisface los requisitos definidos;
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y los procedimientos de la organización aplicables con respecto al Proceso de
Diseño Arquitectural del Sistema.
6.4.3.3.1.1 Se debe establecer una arquitectura de máximo nivel para el sistema. Esta
arquitectura debe identificar los elementos de hardware, software y operaciones manuales.
Se debe asegurar que todos los requisitos del sistema estén asignados entre los elementos.
Los elementos de configuración del hardware, elementos de configuración del software y
operaciones manuales se deben identificar posteriormente, a partir de estos elementos. La
arquitectura del sistema y los requisitos del sistema asignados a los elementos deben estar
documentados.
NOTA 1 Las interfaces internas y externas de cada elemento del sistema deberían estar definidas en la
arquitectura del sistema.
NOTA 2 Se deberían identificar y ejecutar actividades de diseño centrado en los humanos, y las
técnicas y el conocimiento de ergonomía se deberían incorporar en el diseño del sistema.
NOTA 3 El diseño arquitectural del sistema y la relación con los requisitos del sistema se deberían
establecer en la línea base y comunicar a todas las partes afectadas.
6.4.3.3.2.1 La arquitectura del sistema y los requisitos para los elementos se deben
evaluar considerando los criterios listados a continuación. Los resultados de las
evaluaciones deben estar documentados.
NOTA: La trazabilidad de la arquitectura del sistema hacia los requisitos del sistema también debería
proporcionar trazabilidad hacia la línea base de los requisitos de las partes interesadas.
6.4.4.1 Propósito
NOTA: Los usuarios de esta Norma pretenden tratar un producto software o un elemento del software
de un sistema más grande. El Proceso de Implementación del software (apartado 7.1.1) es un ejemplo
acorde con el Proceso de Implementación de la ISO/IEC 15288 2 , especializado para las necesidades
particulares de implementación de un producto o servicio software. El Proceso de Implementación del
Software reemplaza al Proceso de Implementación en esta Norma.
NOTA: El Proceso de Integración del Sistema en esta Norma es una especialización del Proceso de
Integración de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una declaración de
conformidad con el proceso 15288 en lugar de hacerlo con el proceso de esta Norma.
6.4.5.1 Propósito
El propósito del Proceso de Integración del Sistema es integrar los elementos del sistema
(incluyendo elementos de software, elementos de hardware, operaciones manuales y otros
sistemas, según sea necesario) para producir un sistema completo que satisfaga el diseño
del sistema y las expectativas del cliente expresadas en los requisitos del sistema.
6.4.5.2 Resultados
a) una estrategia para integrar el sistema de acuerdo con las prioridades de los
requisitos del sistema es desarrollada;
d) se desarrolla y aplica una estrategia de regresión para repetir las pruebas del
sistema cuando se hacen cambios;
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Integración del Sistema.
NOTA 1: La actividad de integración del sistema se debería realizar de acuerdo con una estrategia de
integración predefinida que tenga en cuenta las prioridades de los requisitos del sistema.
NOTA 2: La estrategia de integración debería abordar la consistencia y trazabilidad entre el diseño del
sistema y los elementos del sistema integrado.
6.4.5.3.2 Reparación de las pruebas. Esta actividad consta de las siguientes tareas:
NOTA: Se debería desarrollar una estrategia de regresión para aplicarla en la repetición de las pruebas
del sistema cuando se realicen cambios.
6.4.5.3.2.2 El sistema integrado se debe evaluar considerando los criterios que se listan
a continuación. Los resultados de las evaluaciones deben estar documentados.
NOTA: El Proceso de Pruebas de Calificación del Sistema de esta Norma contribuye a los resultados
del Proceso de Verificación de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una
declaración de conformidad con el proceso 15288 en lugar de hacerlo con el proceso en esta Norma.
6.4.6.1 Propósito
6.4.6.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y los procedimientos de la organización aplicables con respecto al Proceso de
Pruebas de Calificación del Sistema.
6.4.6.3.1.1 La prueba de calificación del sistema se debe llevar a cabo de acuerdo con
los requisitos de calificación especificados para el sistema. Se debe asegurar que la
implementación de cada requisito del sistema se prueba para determinar la conformidad, y
que el sistema está preparado para la entrega. Los resultados de la prueba de calificación
deben estar documentados.
NOTA: Los requisitos de calificación para el sistema deberían incluir los criterios para evaluar la
conformidad con los requisitos del sistema.
NOTA: Los criterios de evaluación deberían abordar la preparación del sistema para la entrega.
NOTA: Este apartado no se aplica a aquellos elementos de configuración del software para los cuales
se realizaron auditorías previamente.
NOTA: El Proceso de Instalación del Software de esta Norma contribuye a los resultados del proceso
de Transición de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una declaración de
conformidad con el proceso 15288 en lugar de hacerlo con el proceso de esta Norma.
6.4.7.1 Propósito
El propósito del Proceso de Instalación del Software es instalar un producto software que
satisfaga los requisitos acordados en el entorno de destino.
6.4.7.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Instalación del Software.
6.4.7.3.1 Instalación del software. Esta actividad consta de las siguientes tareas:
NOTA 1: La estrategia de instalación del software se debería desarrollar de acuerdo con el cliente y la
organización operadora.
NOTA 2: Una parte importante en el desarrollo de una estrategia de instalación es desarrollar una
estrategia para regresar a la última versión en funcionamiento del sistema. Con el fin de poder
reinstalar la última versión en funcionamiento, se debería hacer una copia de seguridad completa del
sistema antes de iniciar la instalación.
NOTA 3: Basado en los requisitos de instalación, el encargado de la instalación debería desarrollar los
criterios para el ambiente en donde se va a instalar el software.
NOTA 4: El encargado de la instalación debería especificar los requisitos para la adaptación del
sistema a su entorno previsto.
NOTA 5: El encargado de la instalación debería adaptar el sistema para satisfacer los requisitos de
operación.
NOTA: El encargado de la instalación debería asegurar que el producto software esté listo para su
utilización en su entorno previsto.
NOTA: El Proceso de Soporte de la Aceptación del Software de esta Norma contribuye a los
resultados del Proceso de Transición de la ISO/IEC 15288 2 . El Proceso de Soporte de la Aceptación
del Software de esta Norma también puede contribuir a los resultados del Proceso de Validación del
Software de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una declaración de
conformidad con el proceso 15288 en lugar de hacerlo con el proceso de esta Norma.
6.4.8.1 Propósito
6.4.8.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Soporte de la Aceptación del Software.
6.4.8.3.1 Soporte de aceptación del software. Esta actividad consta de las siguientes
tareas:
El Proceso de Operación del Software de esta Norma es una especialización del Proceso de
Operación de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una declaración
de conformidad con el proceso 15288 en lugar de hacerlo con el proceso de esta Norma.
6.4.9.1 Propósito
6.4.9.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y los procedimientos de la organización aplicables con respecto al Proceso de
Operación del Software.
6.4.9.3.2.1 Para cada versión del producto software, el operador debe llevar a cabo la
prueba operacional y, si se satisfacen los criterios especificados, liberar el producto
software para su uso operativo.
6.4.9.3.2.2 El operador debe asegurar que el código del software y las bases de datos se
inician, ejecutan y finalizan según se describe en el plan.
NOTA: Cuando se haya acordado, mantener la capacidad y calidad de servicio continuo cuando el
sistema reemplace a otro existente que se está retirando. Durante un período especificado de
intercambio o de operación simultánea, maneje la transferencia de los servicios de forma tal que se
logre el desempeño continuo para las necesidades de las partes interesadas que aún permanecen.
NOTA 1: La operación en el ambiente previsto incluye el desarrollo de criterios para el uso operativo
de forma tal que se pueda demostrar la conformidad con los requisitos acordados, y realizar la prueba
operativa para cada versión del producto, evaluando la satisfacción frente a los criterios especificados.
6.4.9.3.4.2 El operador debe enviar las solicitudes del usuario, según necesidad, al
Proceso de Mantenimiento del Software (apartado 6.4.10) para su solución. Estas
solicitudes debe tener tratamiento y las acciones que se planifican y que se emprenden se
deben reportar a quienes originan las solicitudes. Todas las soluciones se deben monitorear
hasta su conclusión.
NOTA 1: El Proceso de Mantenimiento del Software en esta Norma es una especialización del
Proceso de Mantenimiento de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una
declaración de conformidad con el proceso 15288 en lugar de hacerlo con el proceso de esta Norma.
6.4.10.1 Propósito
NOTA: Las actividades pre-entrega del Mantenimiento del Software incluyen la planificación de las
operaciones post-entrega, la facilidad de soporte y las determinaciones logísticas. Las actividades
post-entrega incluyen la modificación del software y el soporte operativo, tales como el entrenamiento
u operación de la mesa de ayuda.
6.4.10.2 Resultados
e) las mejoras del producto hacia el ambiente del cliente son migradas; y
6.4.10.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
d) Ejecución de la migración.
e) Verificación de la migración.
6.4.10.3.5.3 A los usuarios se les debe notificar sobre los planes y las actividades de la
migración. Las notificaciones deben incluir los siguientes aspectos:
6.4.10.3.5.6 Se debe llevar a cabo una revisión post-operación para evaluar el impacto
del cambio al nuevo ambiente. Se deben enviar los resultados de la revisión a las
autoridades apropiadas para su información, guía y acción.
6.4.10.3.5.7 Los datos utilizados por o asociados al ambiente antiguo deben ser
accesibles de acuerdo con los requisitos del contrato para protección de los datos y
auditoría aplicable a los datos.
NOTA: El Proceso de Retiro del Software de esta Norma es una especialización del Proceso de Retiro
de la ISO/IEC 15288 2 . Los usuarios pueden considerar hacer una declaración de conformidad con el
proceso 15288 en lugar de hacerlo con el proceso de esta Norma.
6.4.11.1 Propósito
El propósito del Proceso de Retiro del Software es terminar con la existencia de una
entidad de software del sistema.
6.4.11.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y los
procedimientos de la organización aplicables con respecto al Proceso de Retiro del
Software.
6.4.11.3.1 Planificación del retiro del software. Esta actividad consta de las
siguientes tareas:
6.4.11.3.1.1 Se define y documenta una estrategia para el retiro del software. Se debe
desarrollar y documentar un plan para eliminar el soporte activo por parte de las
organizaciones de operación y mantenimiento. Las actividades de planificación deben
incluir a los usuarios. El plan de retiro del software debe abordar los elementos que se
enumeran a continuación:
NOTA 1: Esto define cronogramas, acciones y recursos que: 1) terminan los servicios de entrega de
software; 2) transforman el sistema o lo retienen en un estado social y físicamente aceptable, evitando
así efectos adversos posteriores en las partes interesadas, la sociedad y el ambiente; 3) toman en
consideración la salud, protección, seguridad privacidad aplicable a las acciones de retiro y a la
condición de largo plazo del material e información físico resultante.
NOTA 2: Las restricciones para el retiro se deberían proporcionar como entradas para los requisitos
de las actividades planificadas para el retiro.
6.4.11.3.2 Ejecución del retiro del software. Esta actividad consta de las siguientes
tareas:
6.4.11.3.2.2 Se debe notificar a los usuarios sobre los planes y las actividades para el
retiro de los productos y servicios de software. Las notificaciones deben incluir lo
siguiente:
6.4.11.3.2.3 Se deberían llevar a cabo operaciones paralelas del producto software nuevo
y de aquel que se está retirando con el fin de realizar una transición suave al nuevo sistema.
Durante este periodo se debe proporcionar entrenamiento al usuario como se especifica en
el contrato.
6.4.11.3.2.4 Cuando llegue el retiro programado, se debe enviar una notificación a todos
los interesados. Todos los registros y la documentación de desarrollo asociada, así como
los códigos se deberían archivar, cuando así corresponda.
6.4.11.3.2.5 Los datos utilizados por o asociados con el producto software retirado deben
ser accesibles de acuerdo con los requisitos del contrato para la protección de datos y la
auditoría aplicable a los datos.
NOTA: El Proceso de Implementación del Software es una instancia de conformidad del Proceso de
Implementación de la ISO/IEC 15288 2 , especializado para las necesidades particulares de la
implementación de un producto o servicio software.
7.1.1.1 Propósito
7.1.1.2 Resultados
Además de sus actividades, el Proceso de Implementación del Software tiene los siguientes
procesos de nivel inferior:
NOTA: Los usuarios de la ISO/IEC 15288 2 pueden decidir que los procesos marcados con un
asterisco (*) en la lista anterior deben ser proporcionados por la aplicación recurrente de la
ISO/IEC 15288 2 , incluso para los elementos de software del sistema.
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Implementación
del Software.
NOTA: Estas actividades y tareas se pueden superponer o interactuar y se pueden ejecutar de manera
iterativa o recurrente.
NOTA: Idealmente, se ejecuta mediante la utilización de un modelo de ciclo de vida definido para la
organización.
7.1.1.3.1.4 El implementador debe desarrollar planes para llevar a cabo las actividades
del Proceso de Implementación del Software. Los planes deberían incluir normas
específicas, métodos, herramientas, acciones y responsabilidad asociadas con el desarrollo
y calificación de todos los requisitos incluyendo protección y seguridad. Si es necesario, se
pueden desarrollar planes separados. Estos planes se deben documentar y ejecutar.
NOTA: El Proceso de Análisis de Requisitos del Software en esta Norma es un proceso de nivel
inferior del Proceso de Implementación del Software. Los usuarios de la ISO/IEC 15288 2 pueden
decidir que este proceso debe ser proporcionado por el proceso de análisis de requisitos de la
ISO/IEC 15288 2 en una aplicación recurrente de esa norma.
7.1.2.1 Propósito
El propósito del Proceso de Análisis de Requisitos del Software es establecer los requisitos
de los elementos de software del sistema.
7.1.2.2 Resultados
b) los requisitos del software son analizados para las correcciones y las
pruebas;
g) los cambios en los requisitos del software por el impacto técnico, en el costo
y en el cronograma son evaluados; y
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Análisis de Requisitos del Software.
c) Requisitos de calificación.
c) Consistencia interna.
d) Facilidad de prueba.
NOTA: Siguiendo una evaluación y revisión exitosa, los requisitos del software se deberían aprobar,
estableciendo la línea base y comunicando a las partes afectadas. Los cambios posteriores a la línea
base de los requisitos del software se deberían evaluar para determinar el impacto en el costo,
cronograma y lo técnico.
NOTA: El Proceso de Diseño Arquitectural del Software en esta Norma es un proceso de nivel
inferior del Proceso de Implementación del Software. Los usuarios de la ISO/IEC 15288 2 pueden
decidir que este proceso debe ser proporcionado por el diseño arquitectural de la ISO/IEC 15288 2 en
una aplicación recurrente de esa norma.
7.1.3.1 Propósito
El propósito del Proceso de Diseño Arquitectural del Software es brindar un diseño para el
software que implemente y pueda ser verificado contra los requisitos.
7.1.3.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Diseño
Arquitectural del Software.
NOTA: Esta actividad se implementa para cada elemento de software, consistente con un sistema de
diseño arquitectural.
NOTA: El diseño arquitectural del software también debe proporcionar una base para verificar los
elementos de software, la integración de los elementos de software entre sí, y la integración de los
elementos de software con el resto de los elementos del sistema.
NOTA: El Proceso de Diseño Detallado del Software de esta Norma es un proceso de nivel inferior
del Proceso de Implementación del Software.
7.1.4.1 Propósito
El propósito del Proceso de Diseño Detallado del Software es proveer un diseño para el
software que implemente y se pueda verificar frente a los requisitos y a la arquitectura del
software, y que esté suficientemente detallado para permitir la codificación y la prueba.
7.1.4.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Diseño Detallado
del Software.
7.1.4.3.1 Diseño detallado del software. Para cada elemento de software (o elemento
de configuración, si está identificado) esta actividad consta de las siguientes tareas:
e) Factibilidad de la prueba.
NOTA: El Proceso de Construcción del Software en esta Norma es un proceso de nivel inferior del
Proceso de Implementación del Software.
7.1.5.1 Propósito
7.1.5.2 Resultados
a) los criterios de verificación para todas las unidades de software frente a sus
requisitos son definidos;
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Construcción del Software.
NOTA: El Proceso de Integración del Software de esta Norma es un proceso de nivel inferior del
Proceso de Implementación del Software. Los usuarios de la ISO/IEC 15288 2 pueden decidir que este
proceso sea proporcionado por el proceso de integración de la ISO/IEC 15288 2 en una aplicación
recurrente de esta Norma.
7.1.6.1 Propósito
El propósito del Proceso de Integración del Software es combinar las unidades de software
y los componentes de software, produciendo elementos de software integrados,
consistentes con el diseño del software, que demuestren que se satisfacen los requisitos
funcionales y no funcionales del software en una plataforma equivalente u operacional
completa.
7.1.6.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Integración del Software.
NOTA: Se debería desarrollar una estrategia de regresión para que se aplique en la repetición de la
verificación de los elementos de software cuando se haga un cambio en las unidades de software
(incluyendo requisitos asociados, diseño y código).
c) Consistencia interna.
NOTA: Los criterios de evaluación deberían incluir la consistencia y trazabilidad entre el diseño del
software y los elementos de software.
NOTA: El Proceso de Pruebas de Calificación del Software de esta Norma es un proceso de nivel
inferior del Proceso de Implementación del Software. Los usuarios de la ISO/IEC 15288 2 pueden
decidir que este proceso debe ser proporcionado por el Proceso de Verificación de la ISO/IEC 15288 2
en una aplicación recurrente de esa norma.
7.1.7.1 Propósito
7.1.7.2 Resultados
NOTA: Se debería desarrollar una estrategia de regresión para aplicarla en la repetición de la prueba
del software integrado cuando se hace un cambio en los elementos de software.
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Pruebas de
Calificación del Software.
NOTA: El Proceso de Pruebas de Calificación del Software (apartado 7.2.4) puede ser usado en el
Proceso de Validación del Software (apartado 7.2.5).
NOTA Los procesos de soporte que se enumeran en este apartado son específicos para el software y se
etiquetan como Procesos de Soporte del Software. Aunque ellos juegan un rol integral en la asistencia
del Proceso de Implementación del Software, los Procesos de Soporte del Software también pueden
proveer servicios a otros procesos, por ejemplo, los Procesos de Acuerdo, de Prueba de Calificación
del Sistema, de Soporte de Aceptación del Software, de Operación del Software y el Proceso de
Mantenimiento del Software.
NOTA: El Proceso de Gestión de la Documentación del Software es una especialización del Proceso
de Gestión de la Información del Grupo de Procesos del Proyecto de esta Norma.
7.2.1.1 Propósito
NOTA: La ISO/IEC 15289 provee un contenido más detallado para los elementos de información del
proceso del ciclo de vida (documentación).
7.2.1.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión de la
Documentación del Software.
a) Título o nombre.
b) Propósito y contenido.
c) Audiencia prevista.
7.2.1.3.2.1 Cada documento identificado se debe diseñar de acuerdo con las estándares
de documentación aplicables a medios, formatos, descripción de contenido, numeración de
páginas, ubicación de figuras/tablas, marcas de patente/seguridad, empaque y otros
aspectos de presentación.
NOTA: La documentación se puede originar y puede terminar de cualquier forma (por ejemplo,
verbal, textual, gráfica, numérica) y se puede almacenar, procesar, replicar y transmitir utilizando
cualquier medio (por ejemplo, electrónico, impreso, magnético, óptico).
7.2.1.3.2.2 Se debe confirmar la fuente y la pertinencia de los datos de entrada para los
documentos. Se pueden utilizar herramientas automatizadas de soporte de la
documentación.
7.2.1.3.4.1 Se deben ejecutar las tareas del Proceso de Mantenimiento del Software,
que se requieren cuando se va a modificar la documentación (véase apartado 6.4.10). Para
aquellos documentos que están bajo la gestión de la configuración, las modificaciones se
deben manejar de acuerdo con el Proceso de Gestión de la Configuración del Software
(apartado 7.2.2).
NOTA: El Proceso de Gestión de la Configuración del Software es una especialización del Proceso de
Gestión de la Configuración del Grupo de Procesos del Proyecto de esta Norma.
7.2.2.1 Propósito
7.2.2.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión de la
Configuración del Software.
NOTA: El plan puede ser parte del plan de gestión de la configuración del sistema.
NOTA: El Proceso de Gestión de Resolución de Problemas del Software podría dar soporte a esta
actividad.
7.2.2.3.4.1 Se deben preparar los registros de gestión y los informes que muestran el
estado y el historial de los elementos de software controlado, incluyendo las líneas base.
Los informes de estado deberían incluir el número de cambios del proyecto, las últimas
versiones de los elementos de software, los identificadores de la versión, el número y las
comparaciones de las versiones.
7.2.3.1 Propósito
7.2.3.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Aseguramiento de
la Calidad del Software.
7.2.3.3.1 Implementación del proceso. Esta actividad consta que las siguientes
tareas:
7.2.3.3.2.1 Se debe asegurar que todos los planes exigidos por el contrato estén
documentados, cumplan con el contrato, tengan consistencia mutua y se ejecuten según las
exigencias.
7.2.3.3.3 Aseguramiento del proceso. Esta actividad consta de las siguientes tareas:
7.2.3.3.3.1 Se debe asegurar que aquellos procesos del ciclo de vida del software
(procesos de suministro, desarrollo, operación, mantenimiento y soporte que incluyen
aseguramiento de la calidad) empleados para el proyecto cumplen con el contrato y con los
planes.
7.2.3.3.3.2 Se debe asegurar que las prácticas internas de ingeniería del software, el
ambiente de desarrollo, el ambiente de prueba y las librerías cumplan con lo indicado en el
contrato.
7.2.3.3.3.3 Se debe asegurar que los requisitos aplicables del contrato principal se
entreguen al subcontratista, y que los productos software del subcontratista satisfagan los
requisitos del contrato principal.
7.2.3.3.3.4 Se debe asegurar que el adquiriente y las otras partes reciban el soporte y la
cooperación exigidos según el contrato, las negociaciones y los planes.
7.2.3.3.3.5 Se debe asegurar que el producto software y las mediciones del proceso
estén acordes con las normas y los procedimientos establecidos.
7.2.4.1 Propósito
El propósito del Proceso de Verificación del Software es confirmar que cada producto y/o
servicio de trabajo del software de un proceso o proyecto, refleja correctamente los
requisitos especificados.
7.2.4.2 Resultados
10
La NTP-ISO 9001 es equivalente a la ISO 9001 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 138 de 220
El proyecto debe implementar las actividades y tareas de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Verificación del
Software.
7.2.4.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
7.2.5.1 Propósito
El propósito del Proceso de Validación del Software es confirmar que se cumplen los
requisitos para el uso específico previsto del producto software de trabajo.
7.2.5.2 Resultados
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Validación del Software.
7.2.5.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
NOTA: Para la validación se pueden utilizar otros medios además de la prueba (tales como, análisis,
modelado, simulación, entre otros.).
7.2.5.3.2.3 Realizar las pruebas que se indican en los apartados 7.2.5.3.2.1 y 7.2.5.3.2.2 ,
incluyendo:
7.2.6.1 Propósito
7.2.6.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Revisión del
Software.
7.2.6.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
7.2.6.3.1.2 Se deben proporcionar todos los recursos que se requieren para realizar las
revisiones. Estos recursos incluyen personal, lugar, instalaciones, hardware, software y
herramientas.
7.2.6.3.1.3 Las partes que participan en una revisión deberían llegar a un acuerdo sobre
los siguientes elementos en cada revisión: agenda para la reunión, productos software
(resultados de una actividad) y problemas que se van a revisar, alcance y procedimientos y
los criterios de entrada y salida para la revisión.
7.2.6.3.2.1 Se debe evaluar el estado del proyecto con relación a los planes,
cronogramas, normas y directrices aplicables al proyecto. La gerencia correspondiente
debería tomar en consideración el resultado de la revisión y proveer lo siguiente:
d) Evaluar y hacer la gestión de los aspectos del riesgo que pueden poner en
peligro el éxito del proyecto.
7.2.6.3.3.1 Se deben realizar revisiones técnicas para evaluar los productos o servicios
software bajo consideración y para proporcionar evidencia que:
a) Están completos.
7.2.7.1 Propósito
7.2.7.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Auditoría del
Software.
7.2.7.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
7.2.7.3.1.3 Las partes deben estar de acuerdo sobre los recursos requeridos para realizar
las auditorías. Estos recursos incluyen personal de soporte, lugar, instalaciones, hardware,
software y herramientas.
7.2.7.3.1.4 Las partes deberían acordar sobre los siguientes elementos en cada
auditoría: agenda, productos software (y resultados de una actividad) que se van a revisar,
alcance y procedimientos de auditoría, y criterios de entrada y salida para la auditoría.
7.2.7.3.1.5 Los problemas detectados durante las auditorías se deben registrar e ingresar
en el Proceso de Resolución de Problemas del Software (apartado 7.2.8), según se requiera.
7.2.7.3.1.7 Las partes deben llegar a un acuerdo sobre el resultado de la auditoría y las
responsabilidades del elemento de acción y los criterios de cierre.
7.2.7.3.2.1 Las auditorías del software se deben realizar para asegurar que:
a) Tal como están codificados, los productos software (tal como, un elemento
de software) reflejan la documentación del diseño.
g) Las actividades se han llevado a cabo de acuerdo con los requisitos, planes y
contrato aplicables.
7.2.8.1 Propósito
El propósito del Proceso de Resolución de Problemas del Software es asegurar que todos
los problemas descubiertos se identifiquen, analicen, administren y controlen hasta su
solución.
7.2.8.2 Resultados
NOTA: El Proceso de Resolución de Problemas del Software se podría utilizar o adaptar fácilmente
para manejar, hacer seguimiento y controlar las solicitudes de cambio del software.
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al proceso de solución de
problemas del software.
a) El proceso debe ser de bucle cerrado, asegurando que: todos los problemas
detectados se reporten oportunamente e ingresen en el Proceso de
Resolución del Problema; se inicia la acción para ellos; se notifica a las
partes pertinentes sobre la existencia de los problemas, según corresponda;
se identifican y analizan las causas y, cuando sea posible, se eliminan; se
logra la solución y se retroalimenta; se reporta y se realiza seguimiento al
estado; y los registros de los problemas son mantenidos según lo estipulado
en el contrato.
NOTA: Los usuarios de esta Norma que deseen adoptar las prácticas de reutilización del software
organizacional pueden complementar las disposiciones de esta Norma con aquellos de la norma IEEE
Std 1517™-1999, IEEE Standard for Information Technology - Software Life Cycle Processes - Reuse
Processes.
7.3.1.1 Propósito
7.3.1.2 Resultados
f) los activos que pertenecen al dominio durante todos sus ciclos de vida son
adquiridos o desarrollados y mantenidos; y
g) los modelos y las arquitecturas de dominio durante todos sus ciclos de vida
son mantenidos.
NOTA 1: La ingeniería de dominio es un enfoque basado en la reutilización para definir el alcance (es
decir, la definición del dominio), especificar la estructura (es decir, la arquitectura del dominio) y
construir los activos (por ejemplo, requisitos, diseños, código del software, documentación para una
clase de sistemas, subsistemas o aplicaciones).
NOTA 2 El Proceso de Ingeniería de Dominio se puede superponer con los procesos de desarrollo y
mantenimiento que emplean los activos producidos por el proceso de ingeniería del dominio.
El proyecto debe implementar las siguientes actividades y tareas de acuerdo con las
políticas y procedimientos de la organización aplicables con respecto al Proceso de
Ingeniería de Dominio.
NOTA: La norma IEEE Std 1517™, IEEE Standard for Information Technology - Software Life Cycle
Processes - Reuse Processes proporciona un conjunto más detallado de actividades y tareas que
cumplen con los lineamientos de las actividades y las tareas que se indican a continuación.
7.3.1.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
7.3.1.3.2.7 El ingeniero de dominio debe realizar la revisión o las revisiones del análisis
del dominio. Los encargados de desarrollar el software, gerentes de los activos, expertos en
el dominio y usuarios se deben incluir en las revisiones.
7.3.1.3.3.3 Para cada entidad seleccionada que va a ser diseñada para reutilización, el
ingeniero de dominio debe desarrollar y documentar una especificación de activos.
7.3.1.3.3.4 Para cada activo especificado, la especificación se debe evaluar según los
procedimientos de aceptación y certificación de activos de la organización.
7.3.1.3.4.4 El ingeniero de dominio debe realizar la revisión o las revisiones del activo.
Las entidades desarrolladoras del software y los gerentes de activos se deben incluir en las
revisiones.
7.3.2.1 Propósito
7.3.2.2 Resultados
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión de la
Reutilización de los Activos.
7.3.2.3.1 Implementación del proceso. Esta actividad consta de las siguientes tareas:
7.3.2.3.1.1 El gerente de activos debe crear un plan de gestión de activos para definir
los recursos y los procedimientos para gestionar los activos.
7.3.2.3.3 Gestión y control de los activos. Para cada activo, esta actividad consta de
las siguientes tareas:
7.3.2.3.3.1 Para cada activo presentado al gerente de activos, se debe evaluar dicho
activo con base en sus criterios de aceptación y certificación de activos.
7.3.2.3.3.2 Para cada activo aceptado, éste se debe poner a disposición para la
reutilización a través del mecanismo de almacenamiento y recuperación de activos.
7.3.2.3.3.8 El gerente de activos debe notificar a todos aquellos que reutilizan el activo,
y al ingeniero de dominio, acerca de los problemas detectados en dicho activo, las
modificaciones hechas, las nuevas versiones y la eliminación del activo del mecanismo de
almacenamiento y recuperación de activos.
7.3.3.1 Propósito
7.3.3.2 Resultados
NOTA: En las partes afectadas se pueden incluir a los administradores del programa de reutilización,
gerentes de activos, ingenieros a cargo del dominio, encargados del desarrollo, operadores y
encargados del mantenimiento.
El proyecto debe implementar las siguientes actividades de acuerdo con las políticas y
procedimientos de la organización aplicables con respecto al Proceso de Gestión de
Reutilización de los Activos.
ANEXO A
(NORMATIVO)
PROCESO DE ADAPTACIÓN
A.1 Introducción
El propósito del Proceso de Adaptación es adaptar los procesos de esta Norma para
satisfacer las circunstancias o factores particulares que:
a) Los procesos modificados del ciclo de vida son definidos con el fin de
cumplir los propósitos y resultados de un modelo que ciclo de vida.
A.2.3.2 En el caso de las propiedades críticas para el sistema, se debe tomar en cuenta las
estructuras del ciclo de vida, recomendadas o exigidas por los estándares pertinentes para
la dimensión de la criticidad.
A.2.3.3 Obtener entradas de todas las partes afectadas por las decisiones de
adaptación. Éstas incluyen, entre otras:
NOTA 1: Las organizaciones establecen modelos estándar del ciclo de vida como parte del Proceso de
Gestión del Modelo del Ciclo de Vida. Puede ser adecuado que una organización adapte los procesos
de esta Norma para cumplir los propósitos y resultados de las etapas del modelo de ciclo de vida que
se va a establecer.
NOTA 2: Los proyectos seleccionan un modelo de ciclo de vida establecido en la organización para el
proyecto como parte del Proceso de Planificación del Proyecto. Puede ser apropiado adaptar procesos
adoptados en la organización para cumplir los propósitos y los resultados de las etapas del modelo de
ciclo de vida seleccionado.
NOTA 3: En los casos en que los proyectos estén aplicando directamente esta Norma, puede ser
adecuado adaptar los procesos de esta Norma con el fin de cumplir los propósitos y los resultados de
las etapas de un modelo de ciclo de vida adecuado.
A.2.3.5 Seleccionar los procesos del ciclo de vida que requieren de adaptación y
eliminar los resultados, actividades o tareas seleccionados.
NOTA 2: Una organización o proyecto puede encontrar una situación en la que se desea modificar una
disposición de esta Norma. Se debería evitar la modificación porque ésta puede tener consecuencias
no anticipadas en otros procesos, resultados, actividades o tareas. Si es necesaria, la modificación se
realiza eliminando la disposición (haciendo la correspondiente declaración de conformidad adaptada)
y, con consideración cuidadosa de las consecuencias, implementado un proceso que logre resultados
adicionales o realice actividades y tareas adicionales más allá del estándar adaptado.
ANEXO B
(NORMATIVO)
B.1 Introducción
Se entiende que algunos usuarios de esta Norma pueden desear evaluar los procesos
implementados según la ISO/IEC 15504-2 3 , Information Technology – Process
Assessment. Part 2: Performing an Assessment. Este anexo proporciona un Modelo de
Proceso de Referencia adecuado para el uso en conjunto con esta Norma.
La fuente para los procesos en este modelo son los procesos del texto principal de esta
Norma. En cada caso, se ha hecho referencia al nombre, la declaración del propósito y la
declaración de los resultados para cada proceso en el texto principal de esta Norma para su
uso en este anexo. En algunos casos, los procesos del texto de esta Norma tienen un
alcance que se considera demasiado grande para ser evaluado eficazmente. Por lo tanto, en
dichos casos, se han adicionado procesos de nivel inferior en el anexo con propósitos de
evaluación. Cada uno de estos procesos de nivel inferior adicionales refleja una
elaboración de una de las actividades del proceso asociado en el texto principal de la
Norma.
B.2.1 Generalidades
El Modelo de Proceso de Referencia que se incluye en este anexo es adecuado para el uso
en la evaluación del proceso realizada según la ISO/IEC 15504-2 3 , Information
Technology – Process Assessment. Part 2: Performing an Assessment.
b) Una descripción, que cumpla los requisitos del apartado 6.2.4 de esta norma,
de los procesos dentro del alcance del Modelo de Proceso de Referencia.
Esta se proporciona en el Anexo B.3 .
Los procesos definidos dentro del Modelo de Proceso de Referencia deben tener
descripciones e identificación únicas de los procesos. Las descripciones de los procesos
son únicas. La identificación está dada por nombres únicos y por la numeración de
capítulos en este Anexo.
c) las descripciones del proceso deben ser tales que ninguno de los
aspectos del Marco de Medición como se describe en la capítulo 5
[ISO/IEC 15504-2 3] superior al nivel 1, es contenido o implicado.
Producción de un artefacto;
Además de estos atributos básicos, los procesos se pueden caracterizar mediante otros
atributos comunes a todos los procesos. Estos atributos comunes contribuyen al logro del
nivel superior de capacidades del proceso, tal como se define en la ISO/IEC 15504-2 3 .
Existen seis niveles de capacidad del proceso en el marco de medición de la ISO/IEC
15504-2 3 , tal como se describe en la siguiente tabla:
La ISO/IEC 15504-2 3 identifica los siguientes atributos de proceso común (AP) asociado
con el logro de niveles superiores de capacidad del proceso:
gestión del producto de trabajo (AP 2.2) ̶ determina la medida en que los
productos de trabajo producidos por el proceso se gestionan adecuadamente.
El logro de este atributo asegura que los productos de trabajo se establecen,
controlan y mantienen apropiadamente.
medición del proceso (AP 4.1) ̶ determina la medida en que se utilizan las
mediciones del proceso para asegurar que el desempeño del proceso soporte
el logro de las metas definidas del negocio. El logro de este atributo se
centra en la existencia de un sistema eficaz para la colección de medidas
pertinentes para el desempeño del proceso y la calidad de los productos de
trabajo. Las medidas se aplican para determinar la medida del logro de las
metas del negocio de la organización.
Número de capítulo o
Nombre de Proceso de la
apartado de la
ISO/IEC 12207:2008 4
ISO/IEC 12207 4
6 Procesos del Ciclo de Vida del Sistema
6.1 Procesos de Contratación
6.1.1 Proceso de Adquisición
6.1.2 Proceso de Suministro
6.2 Procesos Organizacionales de Habilitación
del Proyectos
6.2.1 Proceso de Gestión del Modelo de Ciclo de
Vida
6.2.2 Proceso de Gestión de la Infraestructura
6.2.3 Proceso de Gestión del Portafolio del
Proyecto
6.2.4 Proceso de Gestión de los Recursos Humanos
6.2.5 Proceso de Gestión de la Calidad
6.3 Procesos del Proyecto
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 173 de 220
Número de capítulo o
Nombre de Proceso de la
apartado de la
ISO/IEC 12207:2008 4
ISO/IEC 12207 4
6.3.1 Proceso de Planificación del Proyecto
6.3.2 Proceso de Evaluación y Control del
Proyecto
6.3.3 Proceso de Gestión de Decisiones
6.3.4 Proceso de Gestión del Riesgo
6.3.5 Proceso de Gestión de la Configuración
6.3.6 Proceso de Gestión de la Información
6.3.7 Proceso de Medición
6.4 Procesos Técnicos
6.4.1 Proceso de Definición de Requisitos de las
Partes Interesadas
6.4.2 Proceso de Análisis de Requisitos del Sistema
6.4.3 Proceso de Diseño Arquitectural del Sistema
6.4.4 Proceso de Implementación
6.4.5 Proceso de Integración del Sistema
6.4.6 Proceso de Pruebas de Calificación del
Sistema
6.4.7 Proceso de Instalación del Software
6.4.8 Proceso de Soporte de la Aceptación del
Software
6.4.9 Proceso de Operación del Software
6.4.10 Proceso de Mantenimiento del Software
6.4.11 Proceso de Retiro del Software
7 Procesos de Ciclo de Vida del Software
7.1 Procesos de Implementación del Software
7.1.1 Proceso de Implementación del Software
7.1.2 Proceso de Análisis de Requisitos del
Software
7.1.3 Proceso de Diseño Arquitectural del Software
7.1.4 Proceso de Diseño Detallado del Software
7.1.5 Proceso de Construcción del Software
7.1.6 Proceso de Integración del Software
7.1.7 Proceso de Pruebas de Calificación del
Software
7.2 Procesos de Soporte del Software
7.2.1 Proceso de Gestión de la Documentación del
Software
7.2.2 Proceso de Gestión de la Configuración del
Software
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 174 de 220
Número de capítulo o
Nombre de Proceso de la
apartado de la
ISO/IEC 12207:2008 4
ISO/IEC 12207 4
7.2.3 Proceso de Aseguramiento de la Calidad del
Software
7.2.4 Proceso de Verificación del Software
7.2.5 Proceso de Validación del Software
7.2.6 Proceso de Revisión del Software
7.2.7 Proceso de Auditoría del Software
7.2.8 Proceso de Resolución de Problemas del
Software
7.3 Procesos de Reutilización del Software
7.3.1 Proceso de Ingeniería de Dominio
7.3.2 Proceso de Gestión de Activos de
Reutilización
7.3.3 Proceso de Gestión de Programas de
Reutilización
Algunas de las actividades de los procesos de los capítulos 6 y 7 son reemplazadas con los
procesos correspondientes de nivel inferior. Las descripciones de estos procesos de nivel
inferior se indican la continuación.
B.3.1.1.1 Propósito
B.3.1.1.2 Resultados
B.3.1.2.1 Propósito
El propósito del Proceso de Selección del Proveedor es elegir a la organización que será
responsable de la entrega de los requisitos del proyecto.
B.3.1.2.2 Resultados
B.3.1.3.1 Propósito
B.3.1.3.2 Resultados
B.3.1.4.1 Propósito
B.3.1.4.2 Resultados
B.3.2.1.1 Propósito
El propósito del Proceso de Licitación del Proveedor es establecer una interfaz para
responder a las consultas y solicitudes de propuestas del adquiriente, así como preparar y
presentar las propuestas.
B.3.2.1.2 Resultados
B.3.2.2.1 Propósito
B.3.2.2.2 Resultados
NOTA: El Proceso de Ejecución del Contrato se utiliza para obtener una confirmación formal de las
asignaciones que fueron ofrecidas durante el Proceso de Licitación del Proveedor.
B.3.2.3.1 Propósito
B.3.2.3.2 Resultados
B.3.3 Procesos de Nivel Inferior del Proceso de Gestión del Modelo del Ciclo
de Vida
Este es un proceso de nivel inferior del Proceso de Gestión del Modelo del Ciclo de Vida.
Reemplaza a la actividad de Establecimiento del Proceso (apartado 6.2.1.3.1).
B.3.3.1.1 Propósito
B.3.3.1.2 Resultados
Este es un proceso de nivel inferior del Proceso de Gestión del Modelo del Ciclo de Vida.
Reemplaza a la actividad de Evaluación del Proceso (apartado 6.2.1.3.2).
B.3.3.2.1 Propósito
El propósito del Proceso de Evaluación del Proceso es determinar la medida en que los
procesos estándares de la organización contribuyen al logro de las metas de su negocio y
facilitan que la organización se centre en la necesidad de la mejora continua del proceso.
B.3.3.2.2 Resultados
Este es un proceso de nivel inferior del Proceso de Gestión del Modelo del Ciclo de Vida.
Reemplaza a la actividad de Mejora del Proceso (apartado 6.2.1.3.3).
B.3.3.3.1 Propósito
B.3.3.3.2 Resultados
NOTA 1: Las fuentes de información que proporcionan entradas para el cambio pueden incluir:
resultados de evaluación del proceso, auditorías, informes de satisfacción del cliente,
eficacia/eficiencia organizativa, costos de calidad.
NOTA 2: El estado actual de los procesos se puede determinar mediante la evaluación del proceso.
Este es un proceso de nivel inferior del Proceso de Gestión de los Recursos Humanos.
Reemplaza a la actividad de Desarrollo de Habilidades (apartado 6.2.4.3.2).
B.3.4.1.1 Propósito
B.3.4.1.2 Resultados
Este es un proceso de nivel inferior del Proceso de Gestión de los Recursos Humanos.
Reemplaza a la actividad de Adquisición y Provisión de Habilidades (apartado 6.2.4.3.3).
B.3.4.2.1 Propósito
B.3.4.2.2 Resultados
Este es un proceso de nivel inferior del Proceso de Gestión de los Recursos Humanos.
Reemplaza a la actividad de Gestión del Conocimiento (apartado 6.2.4.3.4).
B.3.4.3.1 Propósito
B.3.4.3.2 Resultados
Este es un proceso de nivel inferior del Proceso de Operación del Software. Reemplaza a la
actividad de Uso Operativo (apartado 6.4.9.3.3).
B.3.5.1.1 Propósito
El propósito del Proceso de Uso Operativo es asegurar la operación correcta y eficiente del
producto durante la duración de su uso previsto y en su ambiente instalado.
B.3.5.1.2 Resultados
c) los criterios para el uso operativo son desarrollados para que demuestren el
cumplimiento con los requisitos del acuerdo.
Este es un proceso de nivel inferior del Proceso de Operación del Software. Reemplaza a la
actividad de soporte al cliente (apartado 6.4.9.3.4).
B.3.5.2.1 Propósito
B.3.5.2.1 Resultados
b) la satisfacción del cliente con respecto tanto a los servicios de soporte que se
proporcionan como al producto en sí mismo es evaluado regularmente;
ANEXO C
(INFORMATIVO)
HISTORIA Y JUSTIFICACIÓN
C.1 Introducción
Este Anexo C brinda la historia y justificación para esta Norma, así como una descripción
informativa de la estructura del documento.
C.2 Historia
En el mismo marco temporal, la industria del software se dio cuenta que tenía la misma
importancia, la necesidad de evaluar la capacidad del proceso en una escala continua de
una manera comparable y repetible para dar soporte a la mejora del proceso y a la
reducción del riesgo durante la selección del proveedor. Los conceptos de mejora continua
del proceso, madurez de la organización y evaluación de la capacidad son actualmente bien
establecidos y reconocidos, y están siendo normalizados en la serie de normas
ISO/IEC 15504.
Aunque la ISO/IEC 12207 4 trató a los procesos del ciclo de vida del software dentro de un
contexto de sistemas, fue evidente que se necesitaba un estándar similar en el dominio de
los sistemas. La ISO/IEC 15288 2 , publicada en Noviembre de 2002, cubrió esa necesidad.
Los desarrolladores de este estándar se beneficiaron de la experiencia ganada en el
desarrollo de la enmienda de la ISO/IEC 12207 4 y comprendieron las necesidades tal
como se expresan en la ISO/IEC 15504; por lo tanto, los procesos en la norma
ISO/IEC 15288 2 se expresan en términos de propósitos y resultados con la descripción de
las actividades requeridas para lograr tales resultados.
C.3 Metas
Esta Norma es un paso hacia la armonización total de los procesos del ciclo de vida del
sistema y del software al tiempo que brinda soporte a los requisitos de la comunidad de
evaluación. Esta Norma se desarrolló con las siguientes metas:
Esta Norma agrupa las actividades que se pueden ejecutar durante el ciclo de vida de los
sistemas de software en siete Grupos de Procesos. La descripción de alto nivel de estos
grupos se puede encontrar en el apartado 5.2.2. Cada uno de los procesos del ciclo de vida
dentro de dichos grupos se describe en términos de su propósito y de los resultados
deseados, y enumera las actividades y las tareas que son necesarias realizar para alcanzar
tales resultados.
La Figura C.1 es una representación UML de los constructos del proceso usados en esta
Norma y en la ISO/IEC 15288:2008 2 .
Para beneficio de los usuarios de la edición previa de la ISO/IEC 12207 4 y sus enmiendas
y la edición previa de la ISO/IEC 15288 2 , la Tabla C.1 brinda información con respecto a
la fuente de las disposiciones en los procesos alineados de la ISO/IEC 12207:2008 4 . La
información de esta tabla se debería utilizar con precaución dado que:
ANEXO D
(INFORMATIVO)
4
Este anexo describe el alineamiento de los procesos de la ISO/IEC 12207 e
ISO/IEC 15288 2 .
En cada caso, el proceso de la ISO/IEC 12207 4 está previsto como una especialización del
software en un proceso más general de la ISO/IEC 15288 2 .
El apartado 6.4 de cada norma contiene los “Procesos Técnicos”. Los dos estándares usan
nombres ligeramente diferentes para estos procesos. En algunos casos, el proceso de la
ISO/IEC 12207 4 es una especialización del software del proceso de la ISO/IEC 15288 2 .
En otros casos, el proceso de la ISO/IEC 12207 4 sólo contribuye al logro de uno o más
resultados del proceso correspondiente de la ISO/IEC 15288 2 . La tabla siguiente enumera
los procesos e indica la naturaleza de su relación.
4
Finalmente, el capítulo 7 de la ISO/IEC 12207 contiene únicamente procesos que son
específicos para el software.
NOTA 1: Aunque en esta Norma el Proceso de Verificación del Software permanece asignado como
proceso de soporte y ubicado en el Grupo de Procesos de Soporte del Software del capítulo 7 , si el
proceso se implementa para un elemento de software del sistema (un elemento software), el proceso
puede contribuir a uno o más resultados del Proceso de Verificación de la ISO/IEC 15288 2 .
NOTA 2: Aunque en esta Norma el Proceso de Validación del Software permanece asignado como
proceso de soporte y ubicado en el Grupo de Procesos de Soporte del Software del capítulo 7 , si el
proceso se implementa para un elemento de software del sistema (un elemento software), el proceso
puede contribuir a uno o más resultados del Proceso de Validación de la ISO/IEC 15288 2 .
ANEXO E
(INFORMATIVO)
E.1 Introducción
E.2 Definición
[ISO/IEC 42010:2007]
Punto de vista: una especificación de las convenciones para construir y usar una vista. Un
patrón o plantilla a partir de la cual se desarrollan vistas individuales estableciendo el
propósito y las audiencias para una vista y las técnicas para su creación y análisis.
NOTA: En esta definición, pero no en el resto del anexo, el "sistema" al que se hace referencia es la
reunión de los procesos del ciclo de vida proporcionados por la ISO/IEC 15288 2 y la
ISO/IEC 12207 4 .
Pueden existir casos en los cuales se necesita un enfoque unificado para las actividades y
las tareas que se seleccionan a partir de procesos distintos con el fin de brindar visibilidad
para un concepto significativo o una amenaza que trascienden los procesos utilizados en
todo el ciclo de vida. Es útil aconsejar a los usuarios de las normas la forma de identificar y
definir estas actividades para su uso, aunque no pueden localizar un proceso sencillo que
aborde su interés específico.
Para este fin, se ha formulado el concepto de vista del proceso. Como un proceso, la
descripción de una vista del proceso incluye una declaración del propósito y de los
resultados. A diferencia de un proceso, la descripción de la vista de un proceso no incluye
las actividades ni las tareas. En lugar de ello, la descripción incluye una directriz que
indica la forma que en se pueden alcanzar los resultados utilizando las actividades y las
tareas de los diversos procesos de la ISO/IEC 15288 2 y la ISO/IEC 12207 4 . Las vistas del
proceso se pueden construir utilizando la plantilla del punto de vista del proceso que se
encuentra en el apartado E.3.1 .
La vista del proceso está conforme con el punto de vista del proceso. El punto de vista del
proceso proporcionado aquí se puede usar para crear vistas del proceso. El apartado E.4
contiene un ejemplo de la aplicación de este punto de vista.
los intereses que enmarca: los procesos necesarios para reflejar un interés
particular de ingeniería;
NOTA: Los requisitos para la documentación de los puntos de vista se encuentran en ISO/IEC
42010:2007 4 , "Systems and software engineering - Recommended practice for architectural
description of software-intensive sistems", apartado 5.3 . Esta descripción es consistente con los
requisitos.
Esta sección proporciona un ejemplo de la aplicación del punto de vista del proceso para
definir una vista del proceso para Usabilidad, previsto para ilustrar la forma en la cual un
proyecto puede ensamblar los procesos, actividades y tareas de la ISO/IEC 12207 4 para
centrar la atención en el logro de un producto utilizable.
d) el diseño del sistema abordará los posibles efectos adversos del uso en la
salud humana, la seguridad y el desempeño; y
NOTA: Aunque la participación de los usuarios es uno de los principios del diseño centrado en el
humano, los resultados permiten la posibilidad de que las características deseadas no se pueden medir
directamente sino que pueden ser retadas e inferidas con base en las características de otro proceso o
producto que se pueden medir.
Esta vista del proceso se puede implementar utilizando los siguientes procesos, actividades
y tareas tomados de la ISO/IEC 12207 4 .
NOTA: Siempre que sea posible, se utilizan estándares aplicables, por ejemplo ISO 13407, Human-
centred design process for interactive systems, ISO 9241-11, Guidence on usability (describe el
contexto de uso) e ISO 9241, Ergonomics of human-system interaction (estándar con varias partes
acerca de los requisitos y las recomendaciones), y prácticas profesionales aceptadas.
ANEXO F
(INFORMATIVO)
Dado que los siguientes ejemplos de procesos se consideran de gran utilidad para algunos
lectores de este estándar, se han incluido en este anexo. Éstos se podrían incorporar en la
documentación del proceso organizacional del usuario.
F.1.1 Propósito
El propósito del Alineamiento Organizacional es permitir que los procesos del software
necesarios para la organización provean productos y servicios software, que sean
consistentes con las metas de su negocio.
F.1.2 Resultados
F.2.1 Propósito
NOTA: Aunque las operaciones organizacionales, en general, tienen un alcance mucho más amplio
que el de los procesos del software, estos procesos de software se implementan en un contexto de
negocio y para que sean eficaces requieren de un entorno organizacional adecuado.
F.2.2 Resultados
F.3.1 Propósito
F.3.2 Resultados
F.3.3.1 Preparación del proceso. Esta actividad consta de las siguientes tareas:
F.3.3.3 Investigación y análisis del impacto del cambio. Esta actividad consta de
la siguiente tarea:
F.3.3.3.1 Para la solicitud de cambio del contrato por parte del adquiriente, el
proveedor debe investigar su impacto en los planes, costos, beneficios, calidad y
cronograma del proyecto, y luego documentar y explicar dicha investigación al
adquiriente. En la explicación, el proveedor debería aclarar las bases.
F.3.3.5 Modificación del contrato. Esta actividad consta de las siguientes tareas:
ANEXO G
(INFORMATIVO)
Las relaciones con otras estándares ISO/IEC se describen en el texto principal de esta
Norma. El propósito de este anexo informativo es describir las relaciones con otros
estándares IEEE. La tabla que se presenta a continuación enumera los procesos de esta
Norma. Para muchos de dichos procesos, la tabla sugiere los estándares IEEE que pueden
ser útiles en la implementación o ejecución del proceso. En cada caso, una nota describe la
naturaleza de la relación. La combinación de los estándares frente a procesos particulares
sólo es aproximada. Muchas de los estándares IEEE tienen un alcance mayor que el del
proceso único.
TABLA G.1 ̶ Relación entre el estándar IEEE 12207 y otros estándares IEEE
Estándar
Categoría Apartado Proceso IEEE Notas
relevante
6.1.1 Proceso de 1062 Este documento recomienda un
Adquisición conjunto de prácticas útiles que
6.1 Procesos de
pueden ser seleccionadas y
Contratación del
aplicadas durante la adquisición
Sistema
del software
6.1.2 Proceso de Suministro
6.2.1 Proceso de Gestión 1074 Este estándar describe un
del Modelo de Ciclo enfoque para la definición de
de Vida los procesos del ciclo de vida
del software.
6.2.2 Proceso de Gestión de 1175 Las partes actuales y planeadas
la Infraestructura 1462 del estándar
6.2 Procesos IEEE 1175 describen la
Organizacionales integración de las herramientas
de Habilitación del CASE en un ambiente de
Proyecto ingeniería de software
productivo.
El estándar IEEE 1462
proporciona directrices para la
evaluación y selección de
herramientas CASE. Es muy
similar a la ISO/IEC 14102.
Estándar
Categoría Apartado Proceso IEEE Notas
relevante
6.2.3 Proceso de Gestión
del Portafolio del
Proyecto
6.2.4 Proceso de Gestión de
los Recursos
Humanos
6.2.5 Proceso de Gestión de 90003 Este estándar provee directrices
la Calidad para las organizaciones en la
aplicación de la ISO 9001:2000
al software. Es una adopción de
la ISO/IEC 90003 7 .
6.3 y sus 1490 Este documento es la adopción
apartado de la edición hacia 2000 del
Cuerpo de Conocimiento de la
Gestión del Proyecto
6.3.1 Proceso de 1058 El estándar IEEE 1058 describe
Planificación del (16326) el formato y contenido del plan
Proyecto 1228 de gestión del proyecto de
software. Se espera sea
reemplazada por la ISO/IEC y
estándar IEEE 16326.
El estándar IEEE 1228 describe
el contenido de un plan para los
aspectos de desarrollo,
adquisición, mantenimiento y
retiro de software de un sistema
6.3 Procesos del crítico para la seguridad,
Proyecto del 6.3.2 Proceso de
Sistema Evaluación y Control
del Proyecto
6.3.3 Proceso de Gestión de
Decisiones
6.3.4 Proceso de Gestión 1540 El estándar IEEE 1540 provee
del Riesgo (16085) un proceso para la gestión del
riesgo del software. Se espera
que sea reemplazado por la
ISO/IEC y el estándar
IEEE 16085, el cual trata el
riesgo en el nivel del sistema y
del software.
6.3.5 Proceso de Gestión de
la Configuración
6.3.6 Proceso de Gestión de
la Información
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 211 de 220
Estándar
Categoría Apartado Proceso IEEE Notas
relevante
6.3.7 Proceso de Medición 982.1 El estándar IEEE 982.1 provee
1045 un conjunto de medidas para
1061 pronosticar y evaluar la
14143.1 confiabilidad de un producto
software.
6.4.1 Proceso de Definición 1362 Este documento provee las
de Requisitos de las directrices sobre el formato y
6.4 Procesos Partes Interesadas contenido del documento
Técnicos del Concepto de Operaciones,
sistema describiendo las características
de un sistema propuesto desde
el punto de vista del usuario.
6.4.2 Proceso de Análisis 1233 El estándar IEEE 1233 provee
de Requisitos del 1320.1 directrices sobre el desarrollo de
Sistema 1320.2 la especificación de requisitos
del sistema y las características
y calidades de requisitos.
El estándar IEEE 1320.1 y
1320.2 define dos lenguajes,
IDEF0 e IDEF1X97, que
pueden ser usados para el
modelamiento conceptual
incluyendo la representación de
requisitos.
6.4.3 Proceso de Diseño 1471 El estándar IEEE 1471
Arquitectural del (42010) recomienda un marco de trabajo
Sistema conceptual y el contenido para
la descripción arquitectural de
los sistemas intensivos en
software. Se espera que sea
reemplazado por una revisión
de la ISO/IEC y estándar
IEEE 42010.
6.4.4 Proceso de
Implementación
6.4.5 Proceso de
Integración del
Sistema
6.4.6 Proceso de Pruebas de
Calificación del
Sistema
6.4.7 Proceso de Instalación
del Software
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 212 de 220
Estándar
Categoría Apartado Proceso IEEE Notas
relevante
6.4.8 Proceso de Soporte de
la Aceptación del
Software
6.4.9 Proceso de Operación
del Software
6.4.10 Proceso de 14764 Este estándar, idéntico a la
Mantenimiento del ISO/IEC 14764, provee
Software directrices en la implementación
del proceso de mantenimiento
de la ISO/IEC 12207 4 .
6.4.11 Proceso de Retiro del
Software
7.1.1 Proceso de
Implementación del
Software
7.1.2 Proceso de Análisis 830 Este documento recomienda el
de Requisitos del contenido y características de
Software una especificación de requisitos
de software
7.1.3 Proceso de Diseño 1471 El estándar IEEE 1471
Arquitectural del (42010) recomienda un marco de trabajo
Software conceptual y contenido para la
descripción arquitectural de los
sistemas intensivos en software.
Se espera que sea reemplazado
por una revisión de la ISO/IEC
7.1 Procesos de y estándar IEEE 42010.
Implementación
7.1.4 Proceso de Diseño 1016 Este documento recomienda el
del Software
Detallado del contenido y la organización de
Software una descripción de diseño de
software.
7.1.5 Proceso de 1008 Este documento describe un
Construcción del enfoque de prueba de unidad de
Software software.
7.1.6 Proceso de 829 Este estándar describe la forma
Integración del y contenido de un conjunto
Software básico de documentación para
planificación, ejecución y
reporte de pruebas de software.
7.1.7 Proceso de Pruebas de
Calificación del
Software
Estándar
Categoría Apartado Proceso IEEE Notas
relevante
7.2.1 Proceso de Gestión de 1063 El estándar IEEE 1063 provee
la Documentación del 12207.1 requisitos para la estructura,
Software (15289) contenido y formato de la
documentación del usuario.
El estándar IEEE 12207.1
7.2 Procesos de provee una guía para el registro
Soporte del del resultado de datos de la
Software ejecución de los procesos del
ciclo de vida de la
ISO/IEC 12207 4 . Se espera que
sea reemplazado por una
adopción IEEE de la ISO/IEC
15289.
7.2.2 Proceso de Gestión de 828 Este estándar especifica el
la Configuración del contenido de un plan de gestión
Software de la configuración del software
con los requisitos para
actividades de planificación
específica.
7.2.3 Proceso de 730 El estándar IEEE 730 especifica
Aseguramiento de la 1061 el formato y contenido de un
Calidad del Software 1465 plan de aseguramiento de
(25051) calidad del software.
El estándar IEEE 1061 describe
una metodología ̶ abarcando el
ciclo de vida̶ para establecerlos
requisitos de calidad y para
identificar, implementar y
validar las mediciones
correspondientes.
El estándar IEEE 1465 describe
los requisitos de calidad
específicamente adecuado para
los “paquetes” software. Se
espera que sea reemplazado por
una adopción IEEE de la
ISO/IEC 25051.
7.2.4 Proceso de 1012 Este estándar describe las
Verificación del actividades de verificación y
Software validación del software.
7.2.5 Proceso de Validación 1012 Este estándar describe las
del Software actividades de verificación y
validación del software.
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 214 de 220
Estándar
Categoría Apartado Proceso IEEE Notas
relevante
7.2.6 Proceso de Revisión 1028 Este estándar describe cinco
del Software tipos de revisiones de software,
y los procedimientos para su
ejecución.
7.2.7 Proceso de Auditoría 1028 Este estándar describe cinco
del Software tipos de revisiones de software,
y los procedimientos para su
ejecución.
7.2.8 Proceso de 1044 Este estándar provee un enfoque
Resolución de uniforme para la clasificación
Problemas del de anomalías encontradas en el
Software software y su documentación.
7.3 y sus 1420.1 El estándar IEEE 1420.1 y su
apartados 1517 suplemento describen la
información que las bibliotecas
de reutilización de software
7.3 Procesos de
deberían poder intercambiar con
Reutilización del
el fin de intercambiar activos.
Software
El estándar IEEE 1517 provee
los procesos de ciclo de vida
para la reutilización sistemática
del software.
7.3.1 Proceso de Ingeniería
de Dominio
7.3.2 Proceso de Gestión de
Activos de
Reutilización
7.3.3 Proceso de Gestión de
Programas de
Reutilización
IEEE/EIA 12207.1™-1996
Industry Implementation of International Standard ISO/IEC 12207:1995 1 , Standard for
Information Technology—Software Life Cycle Processes—Life Cycle Data
IEEE P90003 11
Software Engineering—Guidelines for the Application of ISO 9001:2000 Computer
Software
11
Los números precedidos por P son protegidos de normas autorizados por IEEE que no están aprobados por
el consejo normativo IEEE-SA en el momento de la publicación de esta norma. Para obtener estos
borradores, contactar con la IEEE.
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 218 de 220
ANEXO H
(INFORMATIVO)
BIBLIOGRAFÍA
[1] IEEE Std 1517:1999, IEEE Standard for Information Technology. Software Life
Cycle Processes. Reuse Processes.
6
[5] ISO 9004:2000 , Quality Management Systems. Guidance for Performance
Improvement.
8
[6] ISO 10007:2003 Quality Management Systems. Guidelines for Configuration
Management.
[9] ISO/IEC TR 9126-2:2003 12, Software Engineering. Product Quality. Part 2: External
Metrics.
12
La NTP-ISO/IEC TR 9126-2 es equivalente a la ISO/IEC TR 9126-2 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 219 de 220
[10] ISO/IEC TR 9126-3:2003 13, Software Engineering. Product Quality. Part 3: Internal
Metrics.
[11] ISO/IEC TR 9126-4:2004 14, Software Engineering. Product Quality. Part 4: Quality
in Use Metrics.
[12] ISO 9241-11:1998, Ergonomic Requirements for Office Work With Visual Display
Terminals (VDTs). Part 11: Guidance on Usability.
[19] ISO/IEC 15289:2006, Systems and Software Engineering. Content of Systems and
Software Life Cycle Process Information Products (Documentation).
13
La NTP-ISO/IEC-TR 9126-3 es equivalente a la ISO/IEC TR 9126-3 .
14
La NTP-ISO/IEC TR 9126-4 es equivalente a la ISO/IEC TR 9126-4 .
© ISO/IEC 2008 - © INACAL 2016 - Todos los derechos son reservados
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 220 de 220
[22] ISO/IEC 16085:2006, System and Software Engineering. Life Cycle Management.
Risk Management.
[23] ISO/IEC 18019:2004, Software and System Engineering. Guidelines for the Design
and Preparation of User Documentation for Application Software.
[24] ISO PAS 18152:2003, A specification for the Process Assessment of Human-System
Issues.
[27] ISO/IEC 24774:2007, System and Software Engineering -Life Cycle Management.
Guidelines for process definition.
[30] ISO/IEC 25062, Software Engineering. Software Product Quality Requirements and
Evaluation (SQuaRE) - Common Industry Formal (CIF) for Usability Test Reports.
NOTA: La familia de documentos ISO/IEC 25000 está reemplazando a la serie de partes múltiples
ISO/IEC 9126. En esta Norma aparecen selecciones tomadas de ambos grupos.