Esta norma establece un marco de referencia común para los procesos del ciclo de vida del software, incluyendo 5 procesos principales, 8 de apoyo y 4 organizativos. Describe cada proceso y lista las actividades de Adquisición y Suministro, detallando algunas de sus tareas. El objetivo es promover el uso de este estándar para mejorar la calidad del software a través de un lenguaje y procesos comunes.

1. Estándar IEEE-12207
Marcos Raúl Córdova Bayas
Facultad de Ingeniería de Sistemas, Escuela Politécnica Nacional
Campus “José Rubén Orellana”, Ladrón de Guevara E11-253, Quito, Ecuador
raul.cordova@epn.edu.ec
Resumen
El presente trabajo contiene una descripción del estándar IEEE-12207, que determina los Procesos del Ciclo de
Vida del Software, como parte de la colección de estándares de la IEEE referente a Tecnología de la Información.
Esta norma determina la existencia de 5 procesos principales, 8 procesos de apoyo y 4 procesos organizativos del
Ciclo de Vida del Software, donde cada proceso está dividido en actividades y éstas a su vez en tareas. En este
documento se definen cada uno de esos procesos, se listan las actividades de los procesos de Adquisición y
Suministro y se detallan algunas de las tareas de las principales actividades de estos procesos, lo que permite
ilustrar el uso y aplicación de la norma. El trabajo intenta promover el uso de este estándar dentro de la industria
del software, con el fin de que las empresas, los profesionales, la academia y todos aquellos que estén involucrados
de alguna manera en el área de la Ingeniería del Software y los Sistemas de Información, lo usen como una norma
para dialogar en un lenguaje común y para ejecutar procesos comunes. Se pretende también contribuir a la mejora
de la industria del software en el Ecuador, ya que el uso de esta norma permitiría a las empresas obtener una base
sólida para mejorar la calidad de sus procesos y productos, permitiendo que su competitividad aumente tanto a
nivel nacional como internacional.
Palabras Claves: proceso de adquisición, auditoría, gestión de la configuración, proceso de desarrollo, proceso
de mantenimiento, proceso de operación, aseguramiento de la calidad, proceso de suministro, proceso de
adaptación, validación, verificación.
Abstract
The present work contains a description of the IEEE-12207 standard, used to define Software Life Cycle
Processes, as part of the IEEE Information Technology standards collection. It includes 5 primary life cycle
processes, 8 supporting life cycle processes and 4 organizational life cycle processes, each divided in activities and
tasks. This document define every process, lists the activities of the Acquisition and Supply processes and details
some of the tasks of the principal activities of these processes, allowing illustrate the use and the application of this
standard. The work try to promote the use of this standard into the software industry, with the objective that the
companies, the professionals, the academic and all involved into the Software Engineering and Information
Systems, use it as a regulation that helps to talk in a common language and put in practice common processes. It
tries as well to contribute to improve the Ecuadorian software industry, because the uses of this standard would
allow the companies obtain a solid foundation to improve the processes and products quality, allowing raise their
national and international competitiveness.
Key words: acquisition process, audit, configuration management, development process, maintenance process,
operation process, quality assurance, supply process, tailoring process, validation, verification

2. 1. Introducción están incluidos en este estándar, como los procesos de
Adquisición y Suministro del software, vitales para la
La industria del software ha logrado un gran avance adecuada relación entre clientes y proveedores de
en los últimos 40 años. Nuevos métodos, software.
metodologías, procesos, técnicas y herramientas han
aparecido con el fin de mejorar los procesos de De igual manera, se incluyen en la norma como
desarrollo y mantenimiento del software, procesos de apoyo, algunos procesos que no siempre
fundamentalmente. Desde la aparición del primer son considerados como esenciales durante la
modelo de ciclo de vida de desarrollo del software, se ejecución de los procesos de Desarrollo, Operación o
han impuesto como grandes fases del proceso de Mantenimiento de software, tales como los procesos
desarrollo las de Análisis, Diseño, Implementación y de Auditoria, Revisiones Conjuntas y Solución de
Pruebas del Software (Pressman, 2005). Algunas han Problemas.
incluido al proceso de Mantenimiento como parte de
este ciclo de vida, pero se ha comprobado que este Adicionalmente, existen procesos que no son
proceso no está incluido dentro de él (Bohem, 1988) técnicos sino de Gestión y que contribuyen a una
(IEEE, 1993), por lo que desde hace algún tiempo, se mejor planificación, ejecución, control y evaluación
lo ha considerado como un proceso separado, aunque de los procesos técnicos. Estos también están
cuando se incluyen nuevos requerimientos para un incluidos en la norma como Procesos Organizativos
sistema ya elaborado, se debe seguir el mismo ciclo de del Ciclo de Vida del Software, y son definidos como
vida anterior, pero como un proceso propio de procesos de Gestión (básicamente de proyectos),
mantenimiento de software. Infraestructura, Mejora y Formación (de recursos
humanos).
Los procesos anteriores, sin embargo, no han sido
suficientes para conseguir una mejora en la calidad de Por otra parte, existe una amplia gama de términos
los procesos del software, lo que ha redundado que se usan dentro del SLC, pero que no todos los
también en que no se alcance una mejora en la calidad actores involucrados dentro de la Ingeniería del
de los productos de software. Por esta causa, se han Software y de los Sistemas de Información los usan
agregado nuevos procesos al ciclo de vida del con la misma acepción, lo cual dificulta la
software (Software Life Cycle – SLC: ciclo que comunicación adecuada entre ellos. Así, el término
comienza cuando se tiene la idea inicial del producto a Desarrollo (del inglés Development) tiene varias
elaborar y que termina cuando el producto deja de ser acepciones: todo el proceso de creación de un nuevo
utilizado), entre los cuales los más conocidos son el producto, solamente una fase (la de Implementación o
proceso de Aseguramiento de la Calidad (Quality Codificación o Programación), o incluso alguna otra
Assurance), el de Gestión de la Configuración (como Análisis o Diseño). Esta confusión y uso
(Configuration Management) y los de Verificación y indiscriminado de términos ha ocasionado que tanto
Validación (Verification and Validation) las empresas como los profesionales involucrados en
(Sommerville, 2006), todos los cuales han contribuido la creación y uso del software, así como la propia
a mejorar la calidad del proceso y, potencialmente, del academia no puedan usar un lenguaje común, ni estar
producto software. de acuerdo en procesos comunes a ser utilizados para
el software.
También, la generación de la Documentación que
permita documentar la forma como se llevan los Por todas estas razones, el estándar IEEE-12207,
procesos, así como el contenido de los productos intenta estandarizar los procesos del Ciclo de Vida del
elaborados a lo largo de esos procesos, ha generado Software, así como la terminología utilizada dentro de
serias dificultades en los desarrolladores de software. esos procesos.
Muchos no documentan los procesos porque
consideran que es una pérdida de tiempo, otros porque Este trabajo describe el estándar IEEE-12207, y
no tienen tiempo y otros documentan de manera tiene por propósito difundirlo y promoverlo como el
parcial y no completa. Ha sido necesario, pues, estándar a ser utilizado en la industria del software y
determinar que el Proceso de Documentación es en el ámbito académico, con el fin de que todos
indispensable también para mejorar procesos y quienes participan en la producción, comercialización
productos software (Thayer, 1990). Y este proceso y enseñanza del software en el Ecuador, lo utilicen
está incluido en la norma que se va a describir, lo cual como el medio que permita tener un lenguaje común y
asegura su importancia. Asimismo, algunos procesos unos procesos comunes, que atenúen la complejidad
que no han sido considerados a lo largo del tiempo inherente del software (Brooks, 1987), permitiendo

3. elevar la calidad del software, componente Esta norma es aplicable a la adquisición de sistemas,
fundamental de la tecnología en la época actual. productos y servicios software, al suministro,
desarrollo, operación y mantenimiento de productos
2. Condiciones generales para el uso de la software, y a la parte software del firmware,
norma independientemente de que sea hecho interna o
externamente a una organización. Incluye también
A continuación se describe el ámbito de la norma, el aquellos aspectos de la definición del sistema
objeto de la misma, el campo de aplicación, la necesario para proporcionar el contexto de los
adaptación de la norma para su uso, qué significa su productos y servicios software.
cumplimiento y las limitaciones para su aplicación
(IEEE/EIA 12207.0-1996, 2003). NOTA - Es necesario que los procesos usados
durante el ciclo de vida del software sean compatibles
2.1 Ámbito con los procesos usados durante el ciclo de vida del
sistema.
Este estándar o marco de referencia cubre el ciclo de
vida del software desde la conceptualización de ideas Esta norma está orientada para ser usada en
hasta su retirada, y consta de procesos para adquirir y situaciones en las que haya dos partes, incluido el caso
suministrar productos y servicios software. Cubre en que estas dos partes pertenezcan a la misma
además el control y la mejora de estos procesos. organización. La situación puede ir desde un acuerdo
informal, hasta un contrato con responsabilidades
Los procesos que hay en esta norma forman un legales. Esta norma puede ser usada por una sola parte
conjunto exhaustivo. Una organización, dependiendo como una auto imposición.
de sus necesidades, puede seleccionar un subconjunto
apropiado para satisfacer dichas necesidades. Esta Esta norma no está dirigida a productos software pre
norma está, así pues, diseñada para ser adaptada a una elaborados, a no ser que formen parte de un producto
organización, proyecto o aplicación concreta. Está entregable.
también diseñada para ser usada tanto cuando el
software es una entidad independiente, como cuando Esta norma está escrita para adquisidores de
está empotrado o forma parte del sistema total. sistemas y productos y servicios software, y para
suministradores, desarrolladores, operadores,
2.2. Objeto mantenedores, gerentes, responsables de
aseguramiento de calidad y usuarios de productos
 Esta norma establece un marco de referencia software.
común para los procesos del ciclo de vida del
software, con una terminología bien definida 2.4 Adaptación de esta norma
a la que puede hacer referencia la industria
del software. Esta norma contiene un conjunto de procesos,
actividades y tareas pensadas para ser adaptadas a los
 Contiene procesos, actividades y tareas para proyectos software. El proceso de adaptación consiste
aplicar durante la adquisición de un sistema en la eliminación de los procesos, actividades y tareas
que contiene software, un producto software no aplicables.
puro o un servicio software, y durante el
suministro, desarrollo, operación y NOTA - Los contratos pueden contemplar la
mantenimiento de productos software. El adición de procesos, actividades o tareas únicas o
software incluye la parte software del especiales.
firmware.
2.5 Cumplimiento
 Esta norma incluye también un proceso que
puede emplearse para definir, controlar y Se define como cumplimiento de esta norma la
mejorar los procesos del ciclo de vida del ejecución de todos los procesos, actividades y tareas
software. seleccionados de esta norma para el proyecto
software, mediante un Proceso de Adaptación. La
2.3 Campo de aplicación ejecución de un proceso o una actividad es completa
cuando todas las tareas requeridas por el proceso o
actividad se llevan a cabo de acuerdo con los criterios

4. prestablecidos y los requisitos especificados en el cada actividad se subdivide a su vez en un conjunto de
contrato como aplicables. tareas. A continuación se hace una introducción de
cada proceso, apareciendo representados en la Figura
Cualquier organización (nacional, asociación 1 (IEEE/EIA 12207.0-1996, 2003). La numeración
industrial, compañía, etc.) que imponga esta norma corresponde al aparecimiento del proceso dentro de la
como condición para tener relaciones comerciales, es norma. Así, el proceso de Adquisición aparece en el
responsable de especificar y hacer público el conjunto capítulo 5 de la norma como 5.1, mientras que el
mínimo de procesos, actividades y tareas que proceso de Gestión aparece en el capítulo 7 como 7.1.
constituyen el cumplimiento de esta norma por parte Las actividades se numeran dentro de los procesos y
del suministrador. las tareas dentro de las actividades. Así, la primera
actividad dentro del proceso de Adquisición se
2.6 Limitaciones numera como 5.1.1, mientras que la primera tarea
dentro de esta actividad se numera como 5.1.1.1.
Esta norma describe la arquitectura de los procesos
del ciclo de vida del software, pero no especifica los 3.1 Procesos principales del ciclo de vida.
detalles de cómo implementar o llevar a cabo las
actividades y tareas incluidas en los procesos. Esta  Los procesos principales del ciclo de vida
norma no pretende prescribir el nombre, el formato o son cinco procesos que dan servicio a las
el contenido explícito de la documentación que se partes principales durante el ciclo de vida del
genere. Si bien esta norma puede requerir la software.
elaboración de diversos documentos de parecido tipo  Una parte principal es la que inicia o lleva a
o clase (un ejemplo son los distintos tipos de planes), cabo el desarrollo, operación o
esto no implica que dichos documentos se desarrollen, mantenimiento de productos software.
agrupen o se mantengan separados de alguna manera.  Estas partes principales son el adquisidor, el
Estas decisiones se dejan para el usuario de esta suministrador, el desarrollador, el operador y
norma. el mantenedor de productos software.
Esta norma no prescribe un método o un modelo de
ciclo de vida concreto para el desarrollo del software.
Las partes en esta norma son las responsables de
seleccionar un modelo de ciclo de vida para el
proyecto software, y de elaborar una correspondencia
entre los procesos, actividades y tareas de esta norma
y los de dicho modelo.
Las partes son también responsables de seleccionar
y aplicar los métodos de desarrollo del software, y de
llevar a cabo las actividades y tareas adecuadas para el
proyecto software.
Esta norma no pretende entrar en conflicto con las
políticas, normas o procedimientos actualmente en
vigor en ninguna organización. Sin embargo, es
necesario resolver cualquier conflicto que surja,
documentando por escrito en forma de excepción
cualquier incumplimiento autorizado de esta norma.
3. Procesos del Ciclo de Vida del Software
Esta norma agrupa las actividades que pueden
llevarse a cabo durante el ciclo de vida del software en
cinco procesos principales, ocho procesos de apoyo y
cuatro procesos organizativos. Cada proceso del ciclo
de vida está dividido en un conjunto de actividades; Figura 1. Esquema estructural norma IEEE-12207

5. 4. Proceso de verificación. Define las
actividades (para el adquisidor, suministrador
Los procesos principales son:
o una parte independiente) para verificar
1. Proceso de adquisición. Define las hasta un nivel de detalle dependiente del
actividades del adquisidor, organización que proyecto software, los productos software.
adquiere un sistema, producto software o 5. Proceso de validación. Define las actividades
servicio software. (para el adquisidor, suministrador o parte
2. Proceso de suministro. Define las actividades independiente) para validar los productos
del suministrador, organización que software del proyecto software.
proporciona el sistema, producto software o 6. Proceso de revisiones conjuntas. Define las
servicio software al adquisidor. actividades para evaluar el estado y
3. Proceso de desarrollo. Define las actividades productos de una actividad. Este proceso
del desarrollador, organización que define y puede ser empleado por dos partes
desarrolla el producto software cualesquiera, donde una de las partes (la
4. Proceso de operación. Define las actividades revisora) revisa a la otra parte (la revisada),
del operador, organización que proporciona de una manera conjunta.
el servicio de operar un sistema informático 7. Proceso de auditoría. Define las actividades
en su entorno real, para sus usuarios. para determinar el cumplimiento de los
5. Proceso de mantenimiento. Define las requisitos, planes y contrato. Este proceso
actividades del mantenedor, organización que puede ser empleado por dos partes
proporciona el servicio de mantenimiento del cualesquiera, donde una parte (la auditora)
producto software; esto es, la gestión de las audita los productos software o actividades
modificaciones al producto software para de otra parte (la auditada).
mantenerlo actualizado y operativo. Este 8. Proceso de solución de problemas. Define un
proceso incluye la migración y retirada del proceso para analizar y eliminar los
producto software. problemas (incluyendo las no
conformidades) que sean descubiertos
3.2 Procesos de apoyo del ciclo de vida. durante la ejecución del proceso de
desarrollo, operación, mantenimiento u otros
 Hay ocho procesos de apoyo del ciclo de procesos, cualesquiera que sea su naturaleza
vida. o causa.
 Un proceso de apoyo es el que apoya a otro
proceso como parte esencial del mismo, con 3.3 Procesos organizativos del ciclo de vida.
un propósito bien definido, y contribuye al
éxito y calidad del proyecto software.  Se emplean por una organización para
 Un proceso de apoyo se emplea y ejecuta por establecer e implementar una infraestructura
otro proceso según sus necesidades. constituida por procesos y personal asociados
al ciclo de vida, y para mejorar
Los procesos de apoyo son: continuamente esta estructura y procesos.
 Se usan habitualmente fuera del ámbito de
1. Proceso de documentación. Define las proyectos y contratos específicos; sin
actividades para el registro de la información embargo, la experiencia adquirida mediante
producida por un proceso del ciclo de vida. dichos proyectos y contratos contribuye a la
2. Proceso de gestión de la configuración. mejora de la organización.
Define las actividades de gestión de la
configuración. Los procesos organizativos son:
3. Proceso de aseguramiento de la calidad.
Define las actividades para asegurar, de una 1. Proceso de gestión. Define las actividades básicas
manera objetiva, que los productos software de gestión, incluyendo la gestión de proyectos,
y los procesos son conformes a sus requisitos durante un proceso del ciclo de vida.
especificados y se ajustan a sus planes 2. Proceso de infraestructura. Define las
establecidos. Se pueden emplear Revisiones actividades básicas para establecer la
Conjuntas, Auditorías, Verificación y infraestructura de un proceso del ciclo de vida.
Validación como técnicas de Aseguramiento 3. Proceso de mejora. Define las actividades básicas
de la Calidad. que una organización (adquisidor, suministrador,

6. desarrollador, operador, mantenedor o el gestor sistema, el adquisidor aprobará los requisitos
de otro proceso) lleva a cabo para establecer, analizados.
medir, controlar y mejorar su proceso del ciclo de 5.1.1.4 El adquisidor puede llevar a cabo él mismo
vida. la definición y análisis de los requisitos software, o
4. Proceso de formación. Define las actividades puede contratar a un suministrador para llevar a cabo
para conseguir personal adecuadamente formado. dicha actividad.
5.1.1.5 Conviene que se use el Proceso de
Desarrollo (5.3) para llevar a cabo las tareas de los
4. Actividades y tareas de los procesos de apartados 5.1.1.2 y 5.1.1.4.
5.1.1.6 El adquisidor considerará las opciones para
Adquisición y Suministro la adquisición a partir del análisis de los criterios
apropiados para incluir los riesgos, costes y beneficios
En esta sección se listarán las actividades de dos de de cada opción.
los procesos principales del ciclo de vida del software:
el de Adquisición y el de Suministro, así como Posibles opciones son:
también algunas de las tareas asociadas a esas
actividades (IEEE/EIA 12207.0-1996, 2003). El a) Comprar un producto software preelaborado que
propósito es ilustrar la forma como la norma lista las satisfaga los requisitos.
actividades y describe las tareas de los procesos del b) Desarrollar el producto software u obtener el
ciclo de vida, de tal manera que las organizaciones o servicio software internamente.
personas interesadas en adoptarla, profundicen su c) Desarrollar el producto software u obtener el
conocimiento y la apliquen en los proceso de software servicio software mediante un contrato.
que llevan a cabo. d) Una combinación de a, b y c.
. e) Mejorar un producto o servicio software ya
existente.
Actividades del Proceso de Adquisición (5.1):
5.1.1.7 Cuando se vaya a adquirir un producto
Este proceso consta de las siguientes actividades: software preelaborado, el adquisidor se asegurará de
que se satisfacen las siguientes condiciones:
5.1.1 Inicio.
5.1.2 Preparación de la petición de ofertas a) Se satisfacen los requisitos del producto
[licitación]. software.
5.1.3 Preparación y actualización del contrato. b) La documentación está disponible.
5.1.4 Seguimiento del suministrador. c) Se satisfacen los derechos de marca, uso,
5.1.5 Aceptación y finalización. propiedad, garantía y licencia.
d) Se ha planificado el soporte futuro al producto
A continuación se muestran las tareas de la actividad software.
de Inicio, para mostrar la forma en que se detallan las
tareas en el estándar. 5.1.1.8 Conviene que el adquisidor prepare,
documente y ejecute un plan de adquisición. El plan
5.1.1 Inicio. Esta actividad consta de las debería incluir lo siguiente:
siguientes tareas:
a) Requisitos del sistema.
5.1.1.1 El adquisidor inicia el proceso de b) Empleo previsto del sistema.
adquisición describiendo un concepto o una necesidad c) Tipo de contrato a emplear.
de adquirir, desarrollar o mejorar un sistema, producto d) Responsabilidades de las organizaciones
software o servicio software. involucradas.
5.1.1.2 El adquisidor definirá y analizará los e) Tipo de soporte que se va a usar.
requisitos del sistema. Conviene que los requisitos del f) Riesgos considerados y procedimientos para
sistema incluyan requisitos de negocio, organizativos, gestionar dichos riesgos.
de usuario, así como de seguridad física y de acceso y
otros requisitos críticos, junto con los procedimientos 5.1.1.9 Conviene que el adquisidor defina y
y normas de diseño, pruebas y conformidad documente la estrategia y condiciones (criterios) de
relacionados. aceptación.
5.1.1.3 Si el adquisidor contrata a un suministrador
para llevar a cabo el análisis de los requisitos del

7. Actividades del Proceso de Suministro (5.2): Actividades del Proceso de Suministro (5.2):
Este proceso consta de las siguientes actividades: Este proceso consta de las siguientes actividades:
1) Inicio. 1) Inicio.
2) Preparación de la petición de ofertas [licitación]. 2) Preparación de la respuesta.
3) Preparación y actualización del contrato. 3) Contrato.
4) Seguimiento del suministrador. 4) Planificación.
5) Aceptación y finalización. 5) Ejecución y control.
6) Revisión y evaluación.
A continuación se muestran las tareas 5.1.16 a la 7) Suministro y finalización.
5.1.1.8, consideradas de las más importantes para la
actividad de inicio, A continuación se muestran dos tareas para la
actividad 4 de este proceso, Planificación del
5.1.1.6 El adquisidor considerará las opciones para la Suministro:
adquisición a partir del análisis de los criterios
apropiados para incluir los riesgos, costes y beneficios 5.2.4.4 Una vez están establecidos los requisitos para
de cada opción. los planes, el suministrador deberá considerar las
opciones para desarrollar el producto software o
Posibles opciones son: proporcionar el servicio software, a partir del análisis
de los riesgos asociados con cada opción. Posibles
a) Comprar un producto software preelaborado que opciones son:
satisfaga los requisitos.
b) Desarrollar el producto software u obtener el a) Desarrollar el producto software o proporcionar el
servicio software internamente. servicio software usando recursos internos.
c) Desarrollar el producto software u obtener el b) Desarrollar el producto software o proporcionar el
servicio software mediante un contrato. servicio software subcontratándolo.
d) Una combinación de a, b y c. c) Obtener productos software preelaborados de
e) Mejorar un producto o servicio software ya fuentes internas o externas.
existente. d) Una combinación de a, b y c.
5.1.1.7 Cuando se vaya a adquirir un producto 5.2.4.5 El suministrador deberá desarrollar y
software preelaborado, el adquisidor se asegurará de documentar el plan o planes de gestión del proyecto
que se satisfacen las siguientes condiciones: basados en los requisitos para los planes y en las
opciones seleccionadas en 5.2.4.4. Los aspectos a
a) Se satisfacen los requisitos del producto software. considerar en el plan incluyen (pero no están limitados
b) La documentación está disponible. a) lo siguiente:
c) Se satisfacen los derechos de marca, uso,
propiedad, garantía y licencia. a) Estructura organizativa del proyecto y autoridad y
d) Se ha planificado el soporte futuro al producto responsabilidad de cada unidad organizativa,
software. incluyendo las organizaciones externas.
b) Entorno de ingeniería (para desarrollo, operación, o
5.1.1.8 Conviene que el adquisidor prepare, mantenimiento, según proceda), incluyendo el entorno
documente y ejecute un plan de adquisición. El plan de pruebas, bibliotecas, equipos, instalaciones,
debería incluir lo siguiente: normas, procedimientos y herramientas.
c) Descomposición estructurada del trabajo de los
a) Requisitos del sistema. procesos y actividades del ciclo de vida, incluyendo
b) Empleo previsto del sistema. los productos software, servicios software y elementos
c) Tipo de contrato a emplear. no entregables que deban desarrollarse, junto con los
d) Responsabilidades de las organizaciones presupuestos, personal, recursos físicos, tamaño del
involucradas. software y plazos asociados a las tareas.
e) Tipo de soporte que se va a usar. d) Gestión de las características de calidad de los
f) Riesgos considerados y procedimientos para productos o servicios software. Se pueden elaborar
gestionar dichos riesgos planes separados para la calidad.

8. e) Gestión de la seguridad física y de acceso, y otros
requisitos críticos de los productos o servicios Las demás actividades y tareas de los procesos del
software. Se pueden elaborar planes por separado para ciclo de vida del software, tanto principales, como de
la seguridad, tanto física como de acceso. apoyo y organizativos se las puede encontrar en el
f) Gestión de subcontratistas, incluyendo su selección, documento que describe el estándar (IEEE/EIA
y la relación entre el subcontratista y el adquisidor, si 12207.0-1996, 2003).
existe.
g) Aseguramiento de la calidad (véase 6.3). 5. Definiciones
h) Verificación (véase 6.4) y validación (véase 6.5);
incluyendo el enfoque para la interacción con el Puesto que a lo largo de este documento, así como a
agente de verificación y validación, si está lo largo del estándar descrito, se encuentra un
especificado. apreciable número de términos que deberían definirse
i) Involucración del adquisidor; esto puede hacerse de manera única, a continuación se hace una
por medios tales como revisiones conjuntas (véase recopilación de las definiciones más importantes
6.6), auditorías (véase 6.7), reuniones informales, (IEEE/EIA 12207.0-1996,2003):
informes, modificaciones y cambios; implementación,
aprobación, aceptación y acceso a instalaciones. acuerdo: Definición de los términos y condiciones
j) Involucración del usuario; esto puede hacerse por bajo las cuales se ha de desarrollar una relación de
medio de ejercicios de establecimiento de requisitos,
trabajo.
demostración de prototipos y evaluaciones.
k) Gestión de riesgos; esto es, gestión de las áreas del adquisición: Proceso de obtener un sistema, producto
proyecto que conllevan riesgos potenciales software o servicio software.
relacionados con aspectos técnicos, costes y plazos. adquisidor: Organización que adquiere u obtiene un
l) Política de seguridad de acceso; esto es, reglas para sistema, producto software o servicio software, de un
lo que necesita saber y a la información que puede suministrador.
acceder cada nivel de la organización del proyecto. NOTA - Adquisidor podría ser el:
m) Aprobación requerida por regulaciones,
comprador, cliente, propietario, usuario,
certificaciones requeridas y derechos de marca, uso,
propiedad, y garantía y licencia. pagador.
n) Mecanismos para preparar los plazos, hacer el aseguramiento de la calidad: Todas las actividades
seguimiento y hacer los informes. planificadas y sistemáticas, implementadas dentro del
o) Formación del personal (véase 7.4). sistema de calidad, y que se demuestren como
necesarias para proporcionar la confianza adecuada en
Como se observa, las actividades se detallan en
que una entidad cumplirá los requisitos de calidad.
tareas a realizarse, las mismas que entregan una guía
bastante completa de qué se debe hacer para cumplir NOTAS:
en la actividad y a su vez, en el correspondiente 1 Hay motivos tanto internos como externos
proceso del ciclo de vida del software. Esto garantiza para el aseguramiento de la calidad:
un alto grado de calidad en el proceso, lo que a) Aseguramiento de la calidad interno:
seguramente desembocará en obtener un producto de dentro de una organización, el aseguramiento
alta calidad. de la calidad proporciona confianza a los
gerentes; o
Es importante recalcar que las actividades y las
tareas no se llevan a cabo de manera aislada, sino que b) Aseguramiento de la calidad externo: en
con frecuencia están relacionadas a otros procesos, situaciones contractuales, el aseguramiento
actividades o tareas, ya sea dentro del mismo proceso de la calidad proporciona confianza al cliente
o con otros procesos. Esto se lo puede observar en la o a otros.
tarea 5.1.1.5, en la que se indica que se debe usar otro 2 Hay actividades de aseguramiento de la
proceso, en este caso, el de Desarrollo, para realizar calidad interrelacionadas con actividades de
las tareas indicadas en los apartados 5.1.1.2 y 5.1.1.4.
control de la calidad.
Lo mismo acontece con la tarea 5.2.4.5, en los
literales g), h), i) y o), donde se hace mención a los 3 A no ser que los requisitos de calidad
procesos de Aseguramiento de la Calidad (6.3), reflejen completamente las necesidades de
Verificación (6.4), Validación (6.5), Revisiones los usuarios, el aseguramiento de la calidad
Conjuntas (6.6) y Auditorías (6.7).

9. puede no proporcionar la confianza sustitución total o parcial por un nuevo sistema, o
adecuada. instalación de un sistema mejorado.
seguridad de acceso: Protección de información y
auditoría: Conducida por una persona autorizada con datos de manera que las personas o sistemas no
el propósito de proporcionar una evaluación autorizados no puedan leerlos o modificarlos, al
independiente de productos y procesos software, con tiempo que no se deniega el acceso a las personas o
el fin de evaluar cumplimiento de requisitos. sistemas autorizados.
contrato: Acuerdo vinculante entre dos partes, servicio software: Ejecución de actividades, trabajos
especialmente exigible por ley, o acuerdo del mismo o tareas ligadas a un producto software, tales como su
estilo totalmente interno a una organización, para el desarrollo, operación y mantenimiento.
suministro de un servicio software, o para el sistema: Agregado de elementos consistente en uno o
suministro, desarrollo, producción, operación o más de los procesos, hardware, software, instalaciones
mantenimiento de un producto software. y personal que proporcionan la capacidad de satisfacer
desarrollador: Organización que lleva a cabo una necesidad u objetivo definido.
actividades de desarrollo (incluyendo análisis de los software: Soporte lógico.
requisitos, diseño y pruebas hasta la aceptación) suministrador: Organización que contrata con el
durante el proceso del ciclo de vida del software. adquisidor el suministro de un sistema, producto
firmware: Combinación de un dispositivo hardware e software o servicio software, bajo los términos del
instrucciones o datos de computadora que residen contrato.
como software de solo lectura en el dispositivo NOTAS:
hardware. Este software no puede modificarse 1 El término “suministrador” es sinónimo de
fácilmente bajo el control del programa. contratista, fabricante, productor o vendedor.
mantenedor: Organización que lleva a cabo 2 El adquisidor puede designar a parte de su
actividades de mantenimiento. organización como suministrador.
modelo de ciclo de vida: Marco de referencia que usuario: Individuo u organización que usa un sistema
contiene los procesos, actividades y tareas en operación para llevar a cabo una función
involucradas en el desarrollo, operación y específica.
mantenimiento de un producto software, y que abarca NOTA - El usuario puede llevar a cabo otros
toda la vida del sistema, desde la definición de sus papeles tales como el de adquisidor,
requisitos hasta el final de su uso. desarrollador o mantenedor.
operador: Organización que opera el sistema. validación: Confirmación mediante el examen y la
petición de ofertas [licitación]: Documento usado aportación de evidencia objetiva, de que se cumplen
por el adquisidor como mecanismo para anunciar su los requisitos particulares para un uso previsto
intención a potenciales ofertantes, de adquirir un específico.
sistema especificado, un producto software o un NOTAS:
servicio software. 1 En el diseño y el desarrollo, la validación
proceso: Conjunto de actividades interrelacionadas se refiere al proceso de examinar un producto
que transforman entradas en salidas. para determinar su conformidad con las
NOTA - El término “actividades” incluye necesidades del usuario.
uso de recursos. [Véase UNE-EN ISO 2 La validación se lleva normalmente a cabo
8402:1994, 1.2.] sobre el producto final bajo condiciones de
producto preelaborado: Producto ya desarrollado y operación definidas. Puede ser necesaria
disponible, utilizable “tal cual” o con modificaciones. también en etapas anteriores.
producto software: Conjunto de programas de 3 El término “validado” se usa para designar
computadora, procedimientos y posiblemente el estado correspondiente.
documentación y datos asociados. 4 Se pueden llevar a cabo múltiples
retirada: Cese del soporte activo por parte de la validaciones si hay diferentes usos previstos.
organización de operación y mantenimiento,

10. verificación: Confirmación mediante el examen y la IEEE-12207.0. No se han tratado las otras
aportación de evidencias objetivas, de que se han variantes por cuestiones de tiempo y porque
satisfecho unos requisitos especificados. inicialmente sería más complicado el
NOTAS: entendimiento de la norma.
1 En el diseño y el desarrollo, la verificación
se refiere al proceso de examinar el resultado  Este estándar define la existencia de 5 procesos
de una actividad dada, para determinar su principales del ciclo de vida del software,
conformidad con los requisitos establecidos añadiendo a los ya conocidos Desarrollo y
para dicha actividad. Mantenimiento, uno más bien técnico, como el de
2 El término “verificado” se usa para Operación, y dos más bien de gestión, como los
designar el estado correspondiente. procesos de Adquisición y Suministro de
versión: Ejemplar identificado de un elemento. sistemas, productos software y servicios software.
NOTA - Modificar una versión de un producto
software dando como resultado una nueva versión,  La norma incluye 8 procesos de apoyo,
requiere una actuación de gestión de la configuración. denominados así porque sirven justamente de
apoyo a cualquiera de los 5 procesos principales o
Estas definiciones no son todas las que incluye el
estándar, solamente aquellas que están relacionadas a alguno de los otros procesos de apoyo del ciclo
con los procesos, actividades y tareas descritas en de vida del software.
este trabajo. Adicionalmente, se recomienda usar el
estándar IEEE-610.12, IEEE Standard Glossary of  Los 4 procesos organizativos se aplican a todos
Software Engineering Terminology - Glosario los demás procesos que incluye la norma, es
estándar para la terminología en Ingeniería del decir, a los procesos principales y a los procesos
Software (Estándares IEEE, 2003), para acceder a de apoyo del ciclo de vida del software. Estos
toda la terminología estándar de la Ingeniería del están más bien relacionados a cuestiones de
Software, lo que permitirá a quienes se desenvuelven administración involucradas en todos los procesos
en este campo y en el de los Sistemas de del software.
Información, usar e intercambiar términos con un
solo significado, contribuyendo a que todas las
 El nivel de descripción de las actividades y tareas
entidades, profesionales y usuarios del software
de cada proceso es de alto detalle, lo que
trabajen en un ambiente de terminología común,
ampliamente beneficioso para el progreso de la convierte a la norma en fácil de usar y de aplicar.
industria del software en el Ecuador.
 Algo que se debe resaltar es el hecho de que esta
7. Conclusiones norma, a semejanza de todas las que existen en
cualquier campo de la tecnología, solamente
 El estándar IEEE-12207 está formado por tres define el “qué” hacer y no el “cómo” hacerlo.
variantes: IEEE-12207.0, IEEE-12207.1 e IEEE- Esto implica que las organizaciones y personas
12207.2. La primera describe los procesos del que la adopten, deberán especificar de manera
ciclo de vida del software con sus actividades y detallada cómo implementar la norma para usarla
tareas, la segunda describe la forma de de manera adecuada.
administrar los datos obtenidos a lo largo de los
procesos del ciclo de vida del software y la  La norma incluye un anexo denominado Proceso
tercera contiene las consideraciones de de Adaptación, que permite a los interesados en
implementación del estándar, que es una guía de usarla, seguir un proceso bien definido para
cómo aplicar cada uno de los procesos, adaptarla a su realidad.
actividades y tareas definidas.
 En este documento se han descrito los procesos,
actividades y tareas correspondientes a la variante

11. 8. Referencias
[1] IEEE/EIA 12207.0-1996. Industry
Implementation of International Standard
ISO/IEC 12207 : 1995. 2003
[2] Pressman, Roger. Ingeniería del Software:
un enfoque práctico. 6a. edición. Editorial
McGraw-Hill, Madrid, 2005.
[3] Bohem, Barry. A Spiral Model of Software
Development and Enhancement.
Computer, vol. 21, n. 5, Mayo 1988.
[4] IEEE. Software Engineering: Standards
Collection. 1993
[5] Sommerville, Ian. Ingeniería del Software.
7ma. Edición. Pearson Addison Wesley.
Madrid. 2005
[6] Thayer, Richard. Software System
Engineering. System and Software
Requirements Engineering, IEEE Computer
Society Press Tutorial, 1990.
[7] Brooks, Frederick. No Silver Bullet:
Essence and Accidents of Software
Engineering. Computer, vol. 20, n.4, abril
1987.