Ntcisoiectr 29110512

NORMA TÉCNICA NTC-ISO/IEC TR
COLOMBIANA 29110-5-1-2
2014-12-10
INGENIERÍA DE SOFTWARE.
PERFILES DE CICLO DE VIDA PARA PEQUEÑAS
ENTIDADES (PEs). PARTE 5-1-2: GUÍA DE
GESTIÓN E INGENIERÍA: GRUPO DE PERFILES
GENÉRICOS: PERFIL BÁSICO
E: SOFTWARE ENGINEERING. LIFECYCLE PROFILES FOR

VERY SMALL ENTITIES (VSES). PART 5-1-2:
MANAGEMENT AND ENGINEERING GUIDE: GENERIC
PROFILE GROUP: BASIC PROFILE
CORRESPONDENCIA: esta es una adopción idéntica (IDT)

por traducción de la norma ISO/IEC
TR 29110-5-1-2:2011.
DESCRIPTORES: ingeniería de software; perfiles; ciclo

de vida; pequeñas entidades; grupos
de perfil genérico; perfil básico; guía
de gestión.
I.C.S.: 35.080
Editada por el Instituto Colombiano de Normas Técnicas y Certificación (ICONTEC)

Apartado 14237 Bogotá, D.C. - Tel. (571) 6078888 - Fax (571) 2221435
Prohibida su reproducción Editada 2014-12-19

PRÓLOGO
El Instituto Colombiano de Normas Técnicas y Certificación, ICONTEC, es el organismo

nacional de normalización, según el Decreto 2269 de 1993.
ICONTEC es una entidad de carácter privado, sin ánimo de lucro, cuya Misión es fundamental
para brindar soporte y desarrollo al productor y protección al consumidor. Colabora con el
sector gubernamental y apoya al sector privado del país, para lograr ventajas competitivas en
los mercados interno y externo.
La representación de todos los sectores involucrados en el proceso de Normalización Técnica

está garantizada por los Comités Técnicos y el período de Consulta Pública, este último
caracterizado por la participación del público en general.
La norma NTC-ISO/IEC TR 29110-5-1-2 fue ratificada por el Consejo Directivo de 2014-12-10.
Esta norma está sujeta a ser actualizada permanentemente con el objeto de que responda en
todo momento a las necesidades y exigencias actuales.
A continuación se relacionan las empresas que colaboraron en el estudio de esta norma a

través de su participación en el Comité Técnico 31 Ingeniería del software y sistemas.
GREEN SQA PROCESIX

MINISTERIO DE LAS TECNOLOGÍAS Y SQUAL
LAS COMUNICACIONES -MINTIC-
Además de las anteriores, en Consulta Pública el Proyecto se puso a consideración de las

siguientes empresas:
A Y S COMPUTADORES S.A. ILIMITADA INGENIERÍA DE SISTEMAS S.A.S.

ALCALDÍA MAYOR DE BOGOTÁ - INSTITUTO COLOMBIANO DE
SECRETARÍA GENERAL APRENDIZAJE -INCAP.
ALIANZA SINERTIC INSTITUTO DE ORTOPEDIA INFANTIL
CÁMARA DE COMERCIO DE MEDELLÍN ROOSEVELT
CENTRO POLICLÍNICO DEL OLAYA INSUCOMPUTO S.A.
C.P.O. S.A. KAOME ESTUDIO
ENLACE OPERATIVO S.A. MAREIGUA LTDA.
ESCUELA COLOMBIANA DE CARRERAS MINISTERIO DEL TRABAJO
INDUSTRIALES SÁENZ AUDITORES CONSULTORES S.A.
FEDERACIÓN COLOMBIANA DE LA SISTEMAS Y FORMACIÓN S.A.S.
INDUSTRIA DEL SOFTWARE Y SOFTWARE QUALITY ASSURANCE S.A.
TECNOLOGÍAS INFORMÁTICAS SURE COMPUTERS S.A.
RELACIONADAS SYNTOFARMA S.A.
FLAG SOLUCIONES S.A.S. TEAM FOODS COLOMBIA S.A.
FUNDACIÓN PARQUE TECNOLÓGICO VIDYCOM LTDA.
DEL SOFTWARE DE CALI -PARQUESOFT-
ICONTEC cuenta con un Centro de Información que pone a disposición de los interesados
normas internacionales, regionales y nacionales y otros documentos relacionados.
DIRECCIÓN DE NORMALIZACIÓN
NORMA TÉCNICA COLOMBIANA NTC-ISO/IEC TR 29110-5-1-2
PREFACIO
ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica

Internacional) constituyen el sistema especializado para la normalización a nivel mundial. Los
organismos nacionales que son miembros de ISO o IEC participan en el desarrollo de normas
internacionales a través de comités técnicos establecidos por la organización respectiva para
lidiar con campos específicos de la actividad técnica. Los comités técnicos de ISO e IEC
colaboran en campos de interés mutuo. Otras organizaciones internacionales,
gubernamentales y no gubernamentales, relacionadas con ISO e IEC, también participan en el
trabajo. En el campo de las tecnologías de la información, ISO e IEC han establecido un
comité técnico conjunto, denominado ISO/IEC JTC 1.
Las normas internacionales son redactadas de acuerdo a las reglas establecidas en la Parte 2
de las Directivas ISO/IEC.
La principal tarea del comité técnico conjunto es la de preparar normas internacionales. Los
proyectos de normas internacionales adoptados por el comité técnico conjunto se distribuyen
entre los organismos nacionales miembros para su votación. La publicación como Norma
Internacional requiere la aprobación de por lo menos el 75 % de los organismos nacionales
miembros que votan.
En circunstancias excepcionales, cuando el comité técnico conjunto ha recolectado

información de diferentes tipos de aquella que normalmente se publica como una Norma
Internacional (“estado del arte”, por ejemplo), podrá decidir publicar un Informe Técnico. Un
Informe Técnico es de naturaleza enteramente informativa y debe estar sujeto a revisión cada
cinco años de la misma forma que una Norma Internacional.
Cabe resaltar la posibilidad de que algunos de los elementos de esta Norma Internacional
puedan estar sujetos a derechos de patente. ISO e IEC no asumen la responsabilidad por la
identificación de cualquiera o de todos estos derechos de patente.
La Norma ISO/IEC 29110-5-1-2 fue preparada por el Joint Technical Comittee ISO/IEC
JCT 1, Tecnologías de la Información, Subcomité SC 7, Ingeniería de Software y Sistemas.
La Norma ISO/IEC 29110 está conformada por las siguientes partes, bajo el título general
Ingeniería de Software. Perfiles de Ciclo de Vida para Pequeñas Entidades (PEs):
- Parte 1: Visión General [Informe Técnico]
- Parte 2: Marco de trabajo y taxonomía
- Parte 3: Guía para la evaluación [Informe Técnico]
- Parte 4-1: Especificaciones de Perfil: Grupo de Perfiles Genéricos
- Parte 5-1-2: Guía de gestión e ingeniería: Grupo de Perfiles Genéricos: Perfil Básico
[Informe Técnico]
Las Partes 4 y 5 de la Norma pueden ser desarrolladas para presentar nuevas

especificaciones de perfiles y guías de gestión e ingeniería, de la siguiente forma:
- Parte 4-m: Especificaciones de Perfil: Grupo de Perfil aaaaa
- Parte 5-m-n: Guía de Gestión e Ingeniería: Grupo de Perfil aaaaa: Perfil bbbbb
[Informe Técnico]
INTRODUCCIÓN
La industria del software reconoce el valor de las Pequeñas Entidades (PEs) en su

contribución con productos y servicios valiosos. Según la Norma ISO/IEC 29110, una Pequeña
Entidad (PE) es una entidad (empresa, organización, departamento o proyecto) conformada
por no más de 25 personas. Las PEs también desarrollan y/o realizan el mantenimiento de
software utilizado en sistemas más grandes; por este motivo, usualmente se requiere el
reconocimiento de las PEs como proveedores de software de alta calidad.
De acuerdo con el informe de Panorama de Pequeñas y Medianas Empresas y el Espíritu

Empresarial (año 2005) de la Organización para la Cooperación y el Desarrollo Económico
(OCDE), “Las PEs constituyen el sector dominante de las organizaciones empresariales en
todos los países del mundo, llegando a cifras entre el 95 % y el 99 % del total de la población
empresarial, dependiendo del país”. El desafío que los gobiernos miembros de la OCDE
deben enfrentar es proveer un entorno empresarial que apoye la competitividad de esta
extensa y heterogénea población empresarial y que promueva una cultura empresarial
vibrante.
Según estudios y encuestas realizadas, es claro que la mayor parte de las Normas
internacionales no abarcan ni atienden las necesidades de las PEs. La conformidad con estas
normas resulta difícil, cuando no imposible. Es así que las PEs no cuentan con vías para ser
reconocidas como entidades que producen software de calidad en su entorno, o bien las vías
resultan muy limitadas. Por lo tanto, las PEs, a menudo, se encuentran aisladas de algunas
actividades económicas.
Se ha descubierto que resulta difícil para las PEs relacionar las Normas Internacionales con
sus necesidades de negocio y justificar la aplicación de dichas normas a sus prácticas de
negocio. La mayor parte de las PEs o bien no pueden costear los recursos, en términos de
cantidad de empleados, presupuesto y tiempo, o bien no logran ver el beneficio neto de
establecer procesos de ciclo de vida de software. Para enmendar algunas de estas
dificultades, se ha desarrollado un conjunto de guías de acuerdo a una serie de características
de las PEs. Las guías se basan en subconjuntos de elementos apropiados de las normas,
denominados Perfiles PEs. El propósito de un Perfil PE es definir un subconjunto de Normas
internacionales pertinentes al contexto de las PEs, como por ejemplo, procesos y resultados
de la Norma ISO/IEC 12207 y productos de la Norma ISO/IEC 15289.
La serie ISO/IEC 29110, pensada según público objetivo, ha sido desarrollada para mejorar la
calidad de los productos y/o servicios, y el desempeño de los procesos. (Véase la Tabla 1). No
es la intención de la Norma ISO/IEC 29110 evitar el uso de diferentes ciclos de vida como:
cascada, iterativo, incremental, evolutivo o ágil.
i
Tabla 1. Público objetivo de la Norma ISO/IEC 29110
ISO/IEC29110 Título Público objetivo

Parte 1 Visión General PEs, asesores, productores de normas, proveedores de
herramientas y proveedores de metodologías
Parte 2 Marco de Trabajo y Taxonomía Productores de normas, proveedores de herramientas y
proveedores de metodologías. No está pensada para PEs
Parte 3 Guía de Evaluación Asesores y Pes
Parte 4 Especificaciones de Perfil Productores de normas, proveedores de herramientas y
proveedores de metodologías. No está pensada para PEs
Parte 5 Guía de Gestión e Ingeniería Pes
Si es necesario un nuevo perfil, pueden desarrollarse las Normas ISO/IEC 29110-4 e ISO/IEC
TR 29110-5 sin impacto alguno en los documentos ya existentes, y se convierten en las
Normas ISO/IEC 29110-4-m e ISO/IEC 29110-5-m-n, respectivamente, a través del proceso
ISO/IEC.
La Norma NTC-ISO/IEC TR 29110-1 define los términos comunes del Conjunto de

Documentos de Perfiles PE. Presenta los conceptos de procesos, ciclo de vida y
normalización, y la serie ISO/IEC 29110. También presenta las características y requisitos de
una PE y aclara la razón de ser de los perfiles, documentos, normas y guías específicas de las
PEs.
La Norma ISO/IEC 29110-2 presenta los conceptos de Perfiles Normalizados de Ingeniería de

Software para PEs y define los términos comunes al conjunto de los documentos de perfiles
PE. Establece la lógica detrás de la definición y aplicación de perfiles normalizados, especifica
elementos comunes a todos los perfiles normalizados (estructura, conformidad, evaluación) y
presenta la taxonomía (catálogo) de los perfiles ISO/IEC 29110.
La norma NTC-ISO/IEC TR 29110-3 define las guías de evaluación de procesos y los

requisitos de cumplimiento necesarios para satisfacer el propósito de los Perfiles PE definidos.
La norma NTC-ISO/IEC TR 29110-3 también contiene información que puede ser de utilidad
para los desarrolladores de métodos y herramientas de evaluación. Esta Norma está dirigida a
las personas que tienen relación directa con el proceso de evaluación, por ejemplo el asesor y
el patrocinador de la evaluación, que requieren orientación para asegurar que los requisitos
para llevar a cabo la evaluación han sido cumplidos.
La Norma ISO/IEC 29110-4-1 provee la especificación para todos los perfiles dentro de un
Grupo de Perfiles Genéricos. El grupo de perfiles genéricos es aplicable a los perfiles PEs que
no desarrollan productos de software crítico. Los perfiles se basan en subconjuntos de
elementos apropiados a las normas. Los Perfiles PE aplican y están dirigidos a
autores/proveedores de guías y autores/proveedores de herramientas y otros materiales de
apoyo.
Esta parte de la norma provee una guía de gestión e ingeniería de la implementación para el
Perfil PE Básico del Grupo de Perfiles Genéricos especificado en la Norma NTC-ISO/IEC 29110-
4-1. El Perfil Básico describe el desarrollo de software de una única aplicación por un único
equipo de trabajo sin riesgos específicos o factores circunstanciales.
La Figura 1 describe la serie ISO/IEC 29110 y posiciona las partes dentro del marco de
referencia. Los resúmenes y las guías se publican como Informes Técnicos (TR por su sigla en
inglés), y los perfiles se publican como Normas internacionales (IS por su sigla en inglés).
ii
Figura 1. Serie ISO/IEC 29110
iii
CONTENIDO
Página
INTRODUCCIÓN
1. OBJETO .......................................................................................................................1
1.1 CAMPOS DE APLICACIÓN .........................................................................................1
1.2 PÚBLICO OBJETIVO ...................................................................................................1
2. REFERENCIAS NORMATIVAS ...................................................................................2
3. TÉRMINOS Y DEFINICIONES .....................................................................................2
4. CONVENCIONES Y TÉRMINOS ABREVIADOS.........................................................2
4.1 DENOMINACIONES, DIAGRAMACIÓN Y CONVENCIONES DE DEFINICIÓN .........2
4.2 TÉRMINOS ABREVIADOS ..........................................................................................3
5. VISIÓN GENERAL .......................................................................................................4
6. PROCESO DE GESTIÓN DE PROYECTOS (GP) .......................................................5
6.1 PROPÓSITO DE LA GP ...............................................................................................5
6.2 OBJETIVOS DE LA GP................................................................................................6
6.3 PRODUCTOS DE ENTRADA DE LA GP .....................................................................8
6.4 PRODUCTOS DE SALIDA DE LA GP .........................................................................8
6.5 PRODUCTOS INTERNOS DE LA GP ..........................................................................8
6.6 ROLES INVOLUCRADOS EN LA GP..........................................................................8
6.7 DIAGRAMA DE LA GP ................................................................................................8

Página
7. PROCESO DE IMPLEMENTACIÓN DE SOFTWARE (IS) ........................................14
7.1 PROPÓSITO ...............................................................................................................14
7.2 OBJETIVOS DE LA IS ...............................................................................................15
7.3 PRODUCTOS DE ENTRADA DE LA IS ....................................................................17
7.4 PRODUCTOS DE SALIDA DE LA IS .........................................................................17
7.5 PRODUCTOS INTERNOS DE LA IS .........................................................................18
7.6 ROLES INVOLUCRADOS EN LA IS .........................................................................18
7.7 DIAGRAMA DE IS ......................................................................................................18
8. ROLES ........................................................................................................................28
9. DESCRIPCIÓN DEL PRODUCTO .............................................................................29
10. REQUISITOS DE HERRAMIENTAS DE SOFTWARE ..............................................36
10.1 PROCESO DE GESTIÓN DE PROYECTOS .............................................................36
10.2 PROCESO DE IMPLEMENTACIÓN DE SOFTWARE ...............................................36
BIBLIOGRAFÍA ......................................................................................................................39
ANEXO A (Informativo)
PAQUETES DE DESPLIEGUE ..............................................................................................37
FIGURAS
Figura 1. Serie ISO/IEC 29110 ...............................................................................................iii
Figura 2. Procesos de la guía del perfil básico....................................................................5
Figura 3. Diagrama del proceso de Gestión de Proyectos .................................................9

Página
Figura 4. Diagrama del proceso de Implementación de Software ...................................19
TABLAS
Tabla 1. Público objetivo de la Norma ISO/IEC 29110 .........................................................ii
Tabla 2. Productos de entrada de la GP ...............................................................................8
Tabla 3. Productos de salida de la GP ..................................................................................8
Tabla 4. Productos internos de la GP Nombre ....................................................................8
Tabla 5. Roles involucrados en la GP ...................................................................................8
Tabla 6. Lista de tareas del GP.1 .........................................................................................10
Tabla 10. Productos del repositorio de la GP ....................................................................14
Tabla 11. Productos de entrada de la IS .............................................................................17
Tabla 12. Productos de salida de la IS................................................................................17
Tabla 13. Productos internos de la IS Nombre ..................................................................18
Tabla 14. Roles involucrados en la IS.................................................................................18
Tabla 15. Lista de tareas de la IS.1......................................................................................20

Página
Tabla 21. Productos del repositorio de la IS ......................................................................28
Tabla 22. Roles......................................................................................................................28
Tabla 23. Descripciones del Producto ................................................................................29
Tabla 24. Herramientas de gestión de proyectos ..............................................................36
Tabla 25. Herramientas de Implementación de Software .................................................36

INGENIERÍA DE SOFTWARE.
PERFILES DE CICLO DE VIDA PARA PEQUEÑAS ENTIDADES (PEs).
PARTE 5-1-2: GUÍA DE GESTIÓN E INGENIERÍA:
GRUPO DE PERFILES GENÉRICOS: PERFIL BÁSICO
1. OBJETO
1.1 CAMPOS DE APLICACIÓN
Esta parte de la Norma ISO/IEC 29110 es aplicable a Pequeñas Entidades (PEs). Las PEs son
empresas, organizaciones, departamentos o proyectos de hasta 25 personas. No es la
intención de los procesos de ciclo de vida que se describen en la Norma ISO/IEC 29110
impedir o desalentar su uso por empresas más grandes que las PEs.
Esta parte de la Norma ISO/IEC 29110 brinda una guía de gestión e ingeniería para el Perfil PE
Básico especificado en la norma NTC-ISO/IEC 29110-4-1 a través de procesos de gestión e
implementación de software. Esta parte de la Norma ISO/IEC 29110 es una guía
independiente; no se pretende que una PE utilice el perfil normalizado para implementar esta
parte de la Norma ISO/IEC 29110.
Esta parte de la Norma ISO/IEC 29110 aplica a los proyectos de desarrollo de software, los
cuales pueden ser para cumplir un contrato externo o interno. El contrato interno no necesita
ser explícito entre el equipo de proyecto y sus Clientes.
Utilizando esta parte de la Norma ISO/IEC 29110, una PE puede obtener los siguientes
beneficios:
- Se le entrega al Cliente un conjunto acordado de requisitos de proyecto y productos

esperados.
- Se lleva a cabo un proceso disciplinado de gestión que brinda visibilidad del proyecto y
acciones correctivas de problemas y desviaciones del proyecto.
- Se sigue un proceso sistemático de implementación de software que satisface las

necesidades del Cliente y asegura la calidad de los productos.
1.2 PÚBLICO OBJETIVO
Esta parte de la Norma ISO/IEC 29110 está dirigida a las PEs.
La intención es que sea utilizada con cualquier proceso, técnica o método que mejore la
satisfacción del Cliente y productividad de la PE.
1 de 39
2. REFERENCIAS NORMATIVAS
Los siguientes documentos a los que se hace referencia son indispensables para la aplicación
de este documento. Para las referencias con fecha sólo aplica la edición citada. Para
referencias sin fecha aplica la última edición del documento al que se hace referencia
(incluyendo cualquier documento de corrección).
NTC-ISO/IEC TR 29110-1, Ingeniería de software. Perfiles de ciclo de vida para Pequeñas

Entidades (PEs). Parte 1: Visión General.
3. TÉRMINOS Y DEFINICIONES
Para los propósitos de este documento, aplican los términos y definiciones dados en la Norma
NTC-ISO/IEC TR 29110-1.
4. CONVENCIONES Y TÉRMINOS ABREVIADOS
4.1 CONVENCIONES DE DENOMINACIÓN, DIAGRAMACIÓN Y DEFINICIÓN
Las siguientes descripciones y notaciones de la estructura de un proceso, se utilizan para

describir los procesos.
Nombre. Identificador del proceso, seguido de su abreviación entre paréntesis “()”.
Propósito. Metas generales y resultados esperados de la implementación eficaz del proceso.

La implementación del proceso debería proporcionar beneficios tangibles a las partes
involucradas. El propósito se identifica por la abreviación del nombre del proceso.
Objetivos. Metas específicas para asegurar el cumplimiento del propósito del proceso. Los
objetivos se identifican por la abreviación del nombre del proceso, seguido de la letra “O” y un
número consecutivo, por ejemplo, GP.O1, IS.O2, etc. Cada objetivo es seguido por un recuadro
que incluye una lista de los procesos para el perfil básico, escogidos de la NTC 4243:2009
(ISO/IEC 12207:2008) y sus resultados asociados al objetivo.
Productos de entrada. Son productos requeridos para llevar a cabo el proceso y sus fuentes
correspondientes, que pueden ser otros procesos o una entidad externa al proyecto, tales
como el Cliente. Se identifican por la abreviación del nombre del proceso y se muestran como
una tabla de dos columnas, con nombres de producto y fuentes.
Productos de salida. Son productos generados por el proceso y su destino correspondiente,

que puede ser otro proceso o una entidad externa al proyecto, tales como el Cliente o la
Gerencia Organizativa. Se identifican por la abreviación del nombre del proceso y se muestran
como una tabla de dos columnas, con nombres de producto y destinos.
Productos Internos. Son productos generados y consumidos por el proceso. Se identifican por
la abreviación del nombre del proceso y se muestran como una tabla de una sola columna con
nombres de producto.
Todos los nombres de productos se imprimen en cursiva e inician con letra mayúscula. Algunos
productos tienen uno o más estados relacionados al nombre del producto indicados entre
paréntesis recto “[ ]” y separados por “,”. El estado del producto puede cambiar durante la
ejecución del proceso. Ver el Capítulo 9 para la lista alfabética de productos, sus descripciones,
2
posibles estados y la fuente del producto. La fuente puede ser otro proceso o una entidad
externa al proyecto, tal como el Cliente.
Roles involucrados. Nombres y abreviaciones de las funciones que serán desempeñadas por
los miembros del equipo de proyecto. Una única persona puede desempeñar varios roles y un
rol puede ser desempeñado por varias personas. Los roles se asignan a los participantes del
proyecto de acuerdo con las características del proyecto. La lista de roles se identifica por la
abreviación del nombre del proceso y se muestra como una tabla de dos columnas. Ver en el
Capítulo 8 la lista alfabética de roles, sus abreviaciones y la descripción de las habilidades
requeridas.
Diagrama. Representación gráfica de los procesos. Los grandes rectángulos de vértices

redondeados indican procesos o actividades y los rectángulos más pequeños de vértices en
punta indican los productos. Las flechas gruesas de una dirección o bidireccionales indican el
fuljo principal de información entre procesos o actividades. Las flechas finas de una dirección o
bidireccionales indican los productos de entrada o salida. La notación usada en los diagramas
no implica el uso de ningún proceso de ciclo de vida específico.
Actividad. Conjunto de tareas cohesivas. Una tarea es un requisito, una recomendación o una
acción permitida, cuya intención es contribuir al cumplimiento de uno o más objetivos de un
proceso. La actividad de un proceso es el primer nivel de descomposición del flujo de trabajo
del proceso y el segundo es la tarea. Las actividades se identifican por la abreviación del
nombre del proceso seguida por un número consecutivo y el nombre de la actividad.
Descripción de la actividad. Cada descripción de una actividad se identifica por el nombre de

la actividad y la lista de objetivos relacionados escritos entre paréntesis “()”. Por ejemplo, GP.1
Planificación de Proyecto (GP.O1, GP.O5, GP.O6, GP.O7) significa que la actividad GP.1
Planificación de Proyecto contribuye a cumplir con los objetivos listados: GP.O1, GP.O5,
GP.O6 y GP.O7. La descripción de la actividad comienza con un resumen de tareas y continúa
con la tabla de descripciones de tareas. La descripción de la tarea no impone técnica o método
alguno para ser realizada. La selección de técnicas y métodos se deja para la PE o equipo de
proyecto.
La tabla de descripción de la tarea contiene cuatro columnas correspondientes con:
- Rol. La abreviación de roles involucrados en la ejecución de las tareas.
- Tareas. Descripción de la tarea a ser realizada. Cada tarea se identifica por el ID de la

actividad y un número consecutivo, por ejemplo, GP1.1, GP1.2 y así sucesivamente.
- Productos de entrada. Productos necesarios para ejecutar la tarea.
- Productos de salida. Productos creados o modificados mediante la ejecución de la

tarea.
Incorporación al Repositorio del Proyecto. Lista de productos a ser guardados en el

Repositorio del Proyecto; la Estrategia de Control de Versiones debe ser aplicada a alguno de
ellos (véanse los numerales 6.7.2 y 7.7.2). Sirve como lista de verificación para el gerente de
proyecto y el líder técnico.
NOTA Las tablas usadas en la descripción del proceso son solamente para propósitos de presentación.
4.2 TÉRMINOS ABREVIADOS
PE Pequeña Entidad.
3
5. VISIÓN GENERAL
La Guía de Gestión e Ingeniería del Perfil PE Básico aplica a Pequeñas Entidades (PEs)
(empresa, organización, departamento o proyecto de hasta 25 personas) dedicadas al
desarrollo de software. El proyecto puede cumplir con un contrato externo o interno. El contrato
interno entre el equipo de proyecto y su Cliente no necesita ser explícito.
La Guía proporciona procesos de Gestión de Proyectos y de Implementación de Software que

integran prácticas basadas en la selección de elementos estándar de las Normas NTC 4243
(ISO/IEC 12207:2008), Ingeniería de software y sistemas. Procesos de ciclo de vida de
Software e ISO/IEC 15289:2006, Ingeniería de software y sistemas. Contenido de los productos
de información del proceso de ciclo de vida de sistemas y software. El Anexo A brinda
información sobre los Paquetes de Despliegue que facilitan la implementación de los procesos.
La intención de esta parte de la Norma ISO/IEC 29110 es ser utilizada por una PE para
establecer procesos a fin de implementar cualquier enfoque o metodología de desarrollo
incluyendo, por ejemplo, enfoques o metodologías ágiles, evolutivos, incrementales, desarrollo
dirigido por pruebas, etc., basados en las necesidades de negocio o proyecto de la PE.
Mediante la utilización de la Guía, la PE puede obtener beneficios en los siguientes aspectos:
- Se le entrega al cliente un conjunto acordado de requisitos de proyecto y productos

esperados.
- Se lleva a cabo un proceso disciplinado de gestión que brinde visibilidad del proyecto y
acciones correctivas para los problemas y desviaciones del proyecto.
- Un proceso sistemático de implementación de software que satisfaga las necesidades

del Cliente y se asegure que se busca la calidad del producto.
Para utilizar esta Guía, la PE debe cumplir con las siguientes condiciones iniciales:
- la Declaración de Trabajo del proyecto se encuentra documentada;
- la viabilidad del proyecto se estudió antes de su inicio;
- se asigna y entrena al equipo de proyecto, incluyendo al gerente de proyecto; y
- se encuentran disponibles los bienes, servicios e infraestructura para dar inicio al

proyecto.
El propósito del proceso de Gestión de Proyectos es establecer y llevar a cabo de forma

sistemática las Tareas del proyecto de implementación de software, lo cual permite cumplir con
los Objetivos del proyecto en los tiempos, calidad y costos esperados.
El propósito del proceso de Implementación de Software es llevar a cabo de forma sistemática

las actividades de análisis, diseño, construcción, integración y pruebas para productos nuevos
o modificados de acuerdo con los requisitos especificados.
Ambos procesos se encuentran interrelacionados (véase la Figura 2).
4
NOTA La notación del diagrama se explica en el capítulo 4.1
Figura 2. Procesos de la guía del perfil básico
El proceso de GP (Gestión de Proyectos) utiliza la Declaración de Trabajo del Cliente para

elaborar el Plan de Proyecto. Las tareas de evaluación y control del proyecto de la GP
comparan los progresos del proyecto con el Plan de Proyecto y se toman acciones para
eliminar las desviaciones o incorporar cambios al Plan de Proyecto. La actividad de cierre de
proyecto de la GP entrega la Configuración de Software, producida por la IS, y recibe la
aceptación del Cliente para formalizar el fin del proyecto. Se establece un Repositorio de
Proyecto para guardar los productos de trabajo y para controlar sus versiones durante el
proyecto.
La ejecución del proceso de IS es manejada por el Plan de Proyecto. El proceso de IS da inicio

al comenzar con la actividad de revisión del Plan de Proyecto. El Plan de Proyecto guiará la
ejecución del análisis de requisitos de software, el diseño arquitectónico y detallado del
software, la construcción del software, la integración y las pruebas de software y las actividades
de entrega de productos.
Para eliminar defectos del producto, se incluyen en el flujo de trabajo de actividades las Tareas
de verificación, validación y prueba.
El Cliente proporciona la Declaración de Trabajo como una entrada para el proceso de Gestión
de Proyectos y recibe una Configuración de Software como resultado de la ejecución del
proceso de Implementación de Software (véase la Figura 2).
6. PROCESO DE GESTIÓN DE PROYECTOS (GP)
6.1 PROPÓSITO DE LA GP
El propósito del proceso de Gestión de Proyectos es establecer y llevar a cabo de forma

sistemática las Tareas del proyecto de implementación de software, que posibilita cumplir con
los Objetivos del proyecto en los tiempos, calidad y costos esperados.
establecer procesos a fin de implementar cualquier enfoque o metodología de desarrollo,
incluyendo, por ejemplo, ágil, evolutiva, incremental, desarrollo dirigido por pruebas, etc.,
basados en las necesidades de la organización o del proyecto de la PE.
5
6.2 OBJETIVOS DE LA GP
GP.O1 El Plan de Proyecto para la ejecución del proyecto se desarrolla de acuerdo con la
Declaración de Trabajo y es revisado y aceptado por el Cliente. Las Tareas y Recursos
necesarios para completar el trabajo son dimensionados y estimados.
6.3.1 Proceso de Planificación de Proyecto

a) se define el alcance del trabajo para el proyecto;
c) se estiman y dimensionan las tareas y los recursos necesarios para completar el
trabajo;
e) desarrollan los planes para la ejecución del proyecto, y
f) se activan los planes para la ejecución del proyecto.
6.3.7 Proceso de medición
a) se identifican las necesidades de información de los procesos técnicos y de gestión
[NTC 4243:2009 (ISO/IEC 12207:2008, 6.3.1, 6.3.7)]
GP.O2 Se realiza el seguimiento del progreso del proyecto contra el Plan de Proyecto y es
registrado en el Registro de Estado de Progreso. Las correcciones para remediar problemas y
desviaciones del plan son realizadas cuando los objetivos del proyecto no son alcanzados. El
cierre del proyecto se realiza para lograr la aceptación documentada en el Registro de
Aceptación.
6.3.2 Proceso de Evaluación y Control del Proyecto

a) monitorea y reporta el progreso del proyecto;
c) se toman las acciones para corregir las desviaciones con respecto al plan y para evitar
la recurrencia de problemas identificados en el proyecto, cuando no se cumplen los
objetivos del proyecto;
d) se cumplen y registran los objetivos del proyecto.
6.3.7 Proceso de Medición
d) se reúnen, almacenan, analizan los datos exigidos y se interpretan los resultados;
e) se utilizan los productos de información para apoyar las decisiones y proporcionar una
base objetiva para la comunicación;
6.4.8 Proceso de Soporte para la Aceptación del Software
a) el producto se finaliza y entrega al comprador;
7.2.8 Proceso de Resolución de problemas de software
b) los problemas se registran, identifican y clasifican
e) se hace seguimiento de los problemas hasta su cierre
[NTC 4243:2009 (ISO/IEC 12207:2008, 6.3.2, 6.3.7, 6.4.8, 7.2.8)]
GP.O3 Las Solicitudes de Cambio se tratan a través de su recepción y análisis. Los cambios a
los requisitos de software se evalúan por costo, cronograma e impacto técnico.
7.1.2 Proceso de Análisis de Requisitos de Software

g) se evalúan los cambios en los requisitos del software para determinar el impacto de
costos, cronograma y técnicos.
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.1.2)]
6
GP.O4 Se realizan reuniones de revisión con el Equipo de Trabajo y el Cliente. Los acuerdos
son registrados y se les hace seguimiento.
7.2.6 Proceso de Revisión de Software

a) se realizan revisiones técnicas y de la gestión con base en las necesidades del
proyecto.
c) los resultados de la revisión se dan a conocer a todas las partes afectadas.
d) se hace el seguimiento de los elementos de acción resultantes de las revisiones hasta
el cierre.
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.2.6)]
GP.O5 Los Riesgos son identificados a medida que se producen y durante la realización del
proyecto.
6.3.4 Proceso de Gestión de Riesgos

c) se determina el alcance de la gestión de riesgos que ha de realizar;
7.2.6 Proceso de Revisión de Software
e) se identifican y registran los riesgos y problemas.
[NTC 4243:2009 (ISO/IEC 12207:2008, 6.3.4, 7.2.6)]
GP.O6 Se desarrolla Estrategia de Control de Versiones. Los elementos de Configuración de

Software son identificados y definidos y su línea base es fijada. Las modificaciones y
liberaciones de elementos son controladas y puestas a disposición del Cliente y el Equipo de
Trabajo. Se controla el almacenamiento, manejo y entrega de los elementos.
7.2.2 Proceso de Gestión de la Configuración de Software

a) desarrolla una estrategia para la gestión de la configuración del software;
b) se identifica, define y establece la línea base de los elementos generados por el
proceso o proyecto;
c) se controlan las modificaciones y versiones de los elementos;
d) las modificaciones y versiones se ponen a disposición de las partes afectadas;
g) se controla el almacenamiento, manipulación y entrega de los elementos.
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.2.2)]
GP.O7 El Aseguramiento de la Calidad del Software se realiza para asegurar que los productos
de trabajo y los procesos cumplen con el Plan de Proyecto y la Especificación de Requisitos.
NOTA La implementación del proceso de Aseguramiento de la Calidad del Software se lleva a cabo mediante la
realización de Tareas de verificación, validación y revisión, realizadas en los procesos de Gestión de Proyectos e
Implementación de Software.
7.2.3 Proceso de Aseguramiento de la Calidad del Software

a) se desarrolla una estrategia para llevar a cabo el aseguramiento de la calidad ;
b) se produce y conserva la evidencia sobre el aseguramiento de la calidad del software;
c) se identifican y registran los problemas y/o no conformidades con los requisitos; y
d) se verifica el cumplimiento de los productos, los procesos y las actividades con las
normas, los procedimientos y los requisitos aplicables.
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.2.3)]
7
6.3 PRODUCTOS DE ENTRADA DE LA GP
Tabla 2. Productos de entrada de la GP
Nombre Fuente
Declaración de Trabajo Cliente
Configuración del Software Implementación de Software
Solicitud de Cambio Cliente
Implementación de Software
6.4 PRODUCTOS DE SALIDA DE LA GP
Tabla 3. Productos de salida de la GP
Nombre Destino
Plan de Proyecto Implementación de Software
Registro de Aceptación Gestión Organizativa
Repositorio del Proyecto Implementación de Software
Registro de Reuniones Cliente
Configuración del Software Cliente
6.5 PRODUCTOS INTERNOS DE LA GP
Tabla 4. Productos internos de la GP
Nombre
Solicitud de Cambio
Registro de Corrección
Registro de Reuniones
Resultados de la Verificación
Registro de Estado de Progreso
Respaldo del Repositorio del Proyecto
6.6 ROLES INVOLUCRADOS EN LA GP
Tabla 5. Roles involucrados en la GP
Rol Abreviación
Cliente CLI
Gerente de Proyecto GP
Líder Técnico LT
Equipo de Trabajo ET
6.7 DIAGRAMA DE LA GP
El siguiente diagrama muestra el flujo de información entre las actividades del Proceso de
Gestión de Proyectos incluyendo los productos de trabajo más importantes y sus relaciones.
8
Figura 3. Diagrama del proceso de Gestión de Proyectos
6.7.1 Actividades de la GP
El Proceso de Gestión de Proyectos cuenta con las siguientes actividades:
- GP.1 Planificación del Proyecto
- GP.2 Ejecución del Plan de Proyecto
- GP.3 Evaluación y Control del Proyecto
- GP.4 Cierre del Proyecto

9
GP.1 Planificación del Proyecto (GP.O1, GP.O5, GP.O6, GP.O7)
La actividad de Planificación del Proyecto documenta los detalles de planificación necesarios

para la gestión del proyecto. La actividad brinda:
- Declaración de Trabajo revisada y tareas necesarias para proporcionar los Entregables

del contrato y satisfacer los requisitos del cliente.
- Ciclo de vida del proyecto, incluyendo las dependencias y duración de las tareas.
- Estrategia de aseguramiento de la calidad a través de la verificación y validación de los

productos de trabajo/Entregables, revisiones de Clientes y del Equipo de Trabajo.
- Roles y responsabilidades del Equipo de Trabajo y del Cliente.
- Recursos del Proyecto y necesidades de formación.
- Estimaciones de esfuerzo, costo y plazos.
- Riesgos identificados del proyecto.
- Estrategia de línea base y control de versiones del proyecto.
- Repositorio del Proyecto para almacenar, manipular y entregar líneas base y versiones
controladas de productos y documentos.
Tabla 6. Lista de tareas del GP.1
Productos de
Rol Lista de Tareas Productos de Salida
Entrada
GP LT GP.1.1 Revisión de la Declaración de Trabajo Declaración de Declaración de Trabajo
Trabajo [revisada]
GP CLI GP.1.2 Definir con el Cliente las Instrucciones de Declaración de Plan de Proyecto
Entrega de cada uno de los Entregables Trabajo [revisada] - Instrucciones de
especificados en la Declaración de Trabajo. Entrega
GP LT GP.1.3 Identificar las Tareas específicas a ser Declaración de Plan de Proyecto
llevadas a cabo para producir los Entregables y Trabajo [revisada] - Tareas
sus Componentes de Software identificados en la
Declaración de Trabajo. Incluye Tareas en el
proceso IS junto con las Tareas de verificación,
validación y revisión con la Documentación de
Mantenimiento y con el Equipo de Trabajo para
asegurar la calidad de los productos de trabajo.
Identificar las Tareas para realizar las
Instrucciones de Entrega. Documentar las Tareas.
GP LT GP.1.4 Establecer la Duración Estimada para Plan de Proyecto Plan de Proyecto
llevar a cabo cada tarea. - Tareas - Duración Estimada
GP LT GP.1.5 Identificar y documentar los Recursos: Declaración de Plan de Proyecto
humanos, materiales, de equipamiento y Trabajo - Recursos
herramientas, normas, incluyendo el
entrenamiento requerido del Equipo de Trabajo
para llevar a cabo el proyecto. Incluir en el
cronograma las fechas en las que serán
necesarios los Recursos y el entrenamiento.
GP LT GP.1.6 Establecer la Composición del Equipo de Plan de Proyecto Plan de Proyecto
Trabajo asignando roles y responsabilidades de - Recursos - Composición del
acuerdo a los Recursos. Equipo de Trabajo
Continúa…
10
Tabla 6. (Final)
Rol Lista de Tareas Productos de Entrada Productos de Salida

GP LT GP.1.7 Asignar las fechas estimadas Plan de Proyecto Plan de Proyecto
de inicio y finalización para cada una - Tareas - Cronograma de Tareas
de las Tareas para crear el - Duración Estimada del Proyecto
Cronograma de Tareas del Proyecto
tomando en cuenta los Recursos, - Composición del Equipo
secuencia y dependencias de las de Trabajo
Tareas.
GP GP.1.8 Calcular y documentar el Plan de Proyecto Plan de Proyecto
Esfuerzo y Costo Estimados del - Cronograma de Tareas - Esfuerzo y Costo
proyecto. del Proyecto Estimados
- Recursos
GP LT GP.1.9 Identificar y documentar los Todos los elementos Plan de Proyecto
riesgos que puedan afectar al definidos previamente - Identificación de los
proyecto. Riesgos del Proyecto
GP LT GP.1.10 Documentar la Estrategia de Plan de Proyecto
Control de Versiones en el Plan de - Estrategia de Control de
Proyecto. Versiones
GP GP.1.11 Generar el Plan de Proyecto Todos los elementos Plan de Proyecto
integrando los elementos previamente definidos previamente - Tareas
identificados y documentados. - Duración Estimada
- Recursos
- Composición del
Equipo de Trabajo
- Cronograma de Tareas
del Proyecto
- Esfuerzo y Costo
Estimados
- Identificación de los
Riesgos del Proyecto
- Estrategia de Control
de Versiones
- Instrucciones de Entrega
GP LT GP.1.12 Incluir Descripción del Declaración de Trabajo Plan de Proyecto
Producto, Alcance, Objetivos y - Descripción del Producto - Descripción del Producto
Entregables en el Plan de Proyecto. - Alcance - Alcance
- Objetivos - Objetivos
- Entregables - Entregables
GP LT GP.1.13 Verificar y obtener Plan de Proyecto Resultados de la
aprobación del Plan de Proyecto. Verificación
Verificar que todos los elementos del Plan de Proyecto
Plan de Proyecto son viables y [verificado]
consistentes. Los resultados
encontrados se documentan en los
Resultados de la Verificación y las
correcciones se realizan hasta que el
documento es aprobado por el GP.
GP CLI GP.1.14 Revisar y aceptar el Plan de Plan de Proyecto Registro de Reuniones
Proyecto. [verificado] Plan de Proyecto
El Cliente realiza las revisiones y [aceptado]
aceptaciones del Plan de Proyecto,
asegurándose que los elementos del
Plan de Proyecto coinciden con la
Declaración de Trabajo.
GP LT GP.1.15 Establecer el Repositorio del Estrategia de Control de Repositorio del Proyecto
Proyecto usando la Estrategia de Versiones
Control de Versiones.
11
GP.2 Ejecución del Plan de Proyecto (GP.O2, GP.O3, GP.O4, GP.O5, GP.O7)
La actividad de Ejecución del Plan de Proyecto implementa el plan documentado sobre el

proyecto. La actividad brinda:
- Registro de Estado de Progreso del proyecto actualizado.
- Solicitudes de cambio al plan analizadas y evaluadas, las cuales impactan en los

costos, plazos y requisitos técnicos.
- Cambios aprobados al plan.
- Revisiones y acuerdos con el Equipo de Trabajo (ET) y el Cliente (CLI).
- Respaldo del Repositorio del Proyecto, y su recuperación si es necesario.

GP GP 2.2 Analizar y evaluar la Solicitud Solicitud de Cambio Solicitud de Cambio
LT de Cambio en cuanto a costo, plazos [iniciada] [evaluada]
e impacto técnico. Plan de Proyecto Plan de Proyecto
La Solicitud de Cambio puede ser [actualizado]
iniciada externamente por el Cliente o
internamente por el Equipo de
Trabajo. Actualizar el Plan de
Proyecto si el cambio aceptado no
afecta los acuerdos con el Cliente.
Una Solicitud de Cambio que afecte
dichos acuerdos debe ser negociada
por ambas partes (ver GP.2.4).
GP GP.2.3 Llevar a cabo reuniones de Plan de Proyecto Registro de Reuniones
LT revisión con el Equipo de Trabajo, Registro de Estado de [actualizado]
ET identificar problemas, revisar estado Progreso
de riesgos, registrar acuerdos y Registro de Correcciones
hacerles seguimiento hasta su cierre.
GP GP.2.4 Llevar a cabo reuniones de Plan de Proyecto Registro de Reuniones
CLI revisión con el Cliente, registrar los Registro de Estado de [actualizado]
LT acuerdos y hacerles seguimiento Progreso Solicitud de Cambio
hasta su cierre. Solicitud de Cambio [aceptada]
ET
Una Solicitud de Cambio iniciada por [evaluada] Plan de Proyecto
el Cliente o por el Equipo de Trabajo [actualizado]
que afecte al Cliente, debe ser
negociada para lograr la aceptación Registro de Reuniones
de ambas partes.
En caso de ser necesario, se actualiza
el Plan de Proyecto de acuerdo al
nuevo acuerdo con el Cliente.
GP GP.2.5 Realizar respaldos de acuerdo Estrategia de Control de Respaldo del Repositorio
con la Estrategia de Control de Versiones del Proyecto
Versiones.
GP GP.2.6 Realizar la recuperación del Respaldo del Repositorio Repositorio del Proyecto
Repositorio del Proyecto usando el del Proyecto [recuperado]
Respaldo del Repositorio del
Proyecto, si es necesario.
12
GP.3 Evaluación y Control del Proyecto (GP.O2)
La actividad de Evaluación y Control del Proyecto evalúa el desempeño del plan contra los
compromisos documentados. La actividad brinda:
- Evaluación del desempeño y progreso real del plan contra los objetivos.
- Desviaciones y problemas importantes de costo, plazos y desempeño técnico

identificados y evaluados.
- Revisión de los riesgos del proyecto e identificación de nuevos riesgos.
- Solicitudes de cambios documentadas, las acciones correctivas apropiadas definidas y

los cambios con su correspondiente seguimiento hasta su cierre.

GP.2.1 Hacer seguimiento de la Plan de Proyecto Registro de Estado de
ejecución del Plan de Proyecto y Progreso
registrar los datos reales en el
Registro de Estado de Progreso.
GP GP.3.1 Evaluar el progreso del Plan de Proyecto Registro de Estado de
LT proyecto con respecto al Plan de Registro de Estado de Progreso [evaluado]
ET Proyecto, comparando: Progreso
- Tareas reales contra Tareas
planificadas
- resultados reales contra los
Objetivos establecidos del
proyecto
- asignación real de recursos contra
los Recursos planificados
- costo real contra las estimaciones
de presupuesto
- tiempo real contra el cronograma
planificado
- riesgos reales contra los riesgos
previamente identificados
GP GP.3.2 Establecer, si es necesario, Registro de Estado de Registro de Correcciones
LT acciones para corregir desviaciones o Progreso [evaluado]
ET problemas y riesgos identificados
respecto al cumplimiento del plan,
documentarlas en el Registro de
Correcciones y hacerles seguimiento
hasta su cierre.
GP GP.3.3 Identificar cambios a los Registro de Estado de Solicitud de Cambio
LT requisitos y/o al Plan de Proyecto para Progreso [evaluado] [iniciada]
ET abordar desviaciones importantes,
riesgos potenciales o problemas
respecto al cumplimiento del plan,
documentarlos en la Solicitud de
Cambio y hacerles seguimiento hasta
su cierre.
13
GP.4 Cierre del Proyecto (GP.O2)
La actividad de Cierre del Proyecto proporciona la documentación y productos del proyecto de

acuerdo a los requisitos del contrato. La actividad brinda:
- Entrega del producto tal y como se especifica en las Instrucciones de Entrega.
- Soporte de la aceptación del producto por parte del Cliente de acuerdo con las
Instrucciones de Entrega.
- Finalización del proyecto y firma del Registro de Aceptación.
Rol Lista de Tareas Entrada Salida

GP GP.4.1. Formalizar la finalización del Plan de Proyecto Registro de Aceptación
CLI proyecto de acuerdo con las Instrucciones - Instrucciones de Entrega Configuración del
de Entrega establecidas en el Plan de Configuración del Software Software [aceptada]
Proyecto, brindando apoyo a la aceptación [entregada]
y firmando Registro de Aceptación.
GP GP.4.2 Actualizar el Repositorio del Configuración del Software Repositorio del Proyecto
Proyecto. [aceptada] [actualizado]
Repositorio del Proyecto
6.7.2 Incorporación de la GP al Repositorio del Proyecto
Es la lista de productos a ser guardada en el Repositorio del Proyecto. Luego de la

incorporación, la Estrategia de Control de Versiones debe ser aplicada al Plan de Proyecto.
Tabla 10. Productos del repositorio de la GP
Producto
Plan de Proyecto
Solicitud de Cambio
Registro de Aceptación
Registro de Correcciones
Registro de Estado de Progreso
7. PROCESO DE IMPLEMENTACIÓN DE SOFTWARE (IS)
7.1 PROPÓSITO
El propósito del proceso de Implementación de Software es la realización sistemática de las

actividades de análisis, diseño, construcción, integración y prueba para productos de software
nuevos o modificados, de acuerdo con los requisitos especificados.
establecer procesos a fin de implementar cualquier enfoque o metodología de desarrollo
incluyendo, por ejemplo, ágil, evolutiva, incremental, desarrollo dirigido por pruebas, etc.,
basados en las necesidades de negocio o de proyecto de la PE.
14
7.2 OBJETIVOS DE LA IS
IS.O1 Las Tareas de las actividades se llevan a cabo mediante el cumplimiento del Plan de
Proyecto actual.
IS.O2 Los requisitos de software son definidos, analizados para su exactitud y prueba,
aprobados por el Cliente, se les fija la línea base y son comunicados.
6.4.1 Proceso de Definición de los Requisitos de las Partes Interesadas

a) se especifican las características requeridas y el contexto de uso de los servicios.
7.1.2 Proceso de Análisis de los Requisitos del Software
a) se definen los requisitos asignados a los elementos de software del sistema y sus
interfaces;
b) se analizan los requisitos del software en cuanto a su adecuación y capacidad de
prueba;
f) se aprueban y actualizan, como sea necesario, los requisitos del software;
h) se fija la línea de base de los requisitos del software y se los comunica a todas las
partes afectadas
[NTC 4243:2009 (ISO/IEC 12207:2008, 6.4.1, 7.1.2)]
IS.O3 Se desarrolla y se fija la línea base al diseño arquitectónico y detallado. Describe los
Componentes de Software y sus interfaces externas e internas. Se establece la trazabilidad y
consistencia de los requisitos del software.
7.1.3 Proceso de Diseño de la Arquitectura del Software

a) se desarrolla un diseño de la arquitectura del software y se fija la línea de base que
describe los elementos de software que implementarán los requisitos de software;
b) se definen las interfaces internas y externas de cada ítem de software y
c) se establece la consistencia y trazabilidad entre los requisitos del software y el diseño
del software.
7.1.4 Proceso del Diseño Detallado del Software
a) se desarrolla un diseño detallado de cada componente de software, que describa las
unidades de software por construir;
b) se definen las interfaces externas de cada unidad de software y
c) se establece la consistencia y trazabilidad entre el diseño detallado y los requisitos y
entre el diseño detallado y el diseño de la arquitectura.
7.1.5 Proceso de Construcción del Software
a) se definen los criterios de verificación con respecto a sus requisitos para todas las
unidades de software.
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.1.3, 7.1.4, 7.1.5)]
NOTA El diseño de la arquitectura del software y el diseño detallado pueden ser realizados de forma separada
de acuerdo al cronograma del proyecto.
IS.O4 Se producen los Componentes de Software definidos por el diseño. Se definen y realizan
las pruebas unitarias para verificar la consistencia con los requisitos y con el diseño. Se
establece la trazabilidad para los requisitos y el diseño.
15
7.1.5 Proceso de Construcción del Software

b) se producen las unidades de software definidas por el diseño;
c) se establece la consistencia y trazabilidad entre las unidades de software y los
requisitos y el diseño y
d) se consigue la verificación de las unidades de software con respecto a los requisitos y
al diseño.
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.1.5)]
IS.O5 El Software se produce realizando la integración de los Componentes de Software y se

verifican usando Casos de Prueba y Productores de Pruebas. Los resultados se registran en el
Informe de Pruebas. Los defectos son corregidos y se establece la consistencia y la
trazabilidad para el Diseño del Software.
7.1.6 Proceso de Integración del Software

c) se verifican los elementos de software utilizando los criterios definidos;
d) se producen los elementos de software definidos por la estrategia de integración;
e) se registran los resultados de las pruebas de integración;
f) se establece la consistencia y trazabilidad entre el diseño del software y los elementos
de software;
7.1.7 Proceso de Pruebas de Calificación del Software
a) se desarrollan criterios para el software integrado que demuestren el cumplimiento con
los requisitos del software;
b) se verifica el software integrado utilizando los criterios definidos;
c) se registran los resultados de las pruebas;
[NTC 4243:2009 (ISO/IEC 12207:2008, 7.1.6, 7.1.7)]
IS.O6 Una Configuración de Software que cumpla con la Especificación de Requisitos tal y
como se acuerda con el Cliente, que incluya documentación de usuarios, de operación y de
mantenimiento, con dicha documentación integrada, con la línea base fijada y almacenada en
el Repositorio del Proyecto. Las necesidades de cambio a la Configuración de Software son
detectadas y se inician las solicitudes de cambio relacionadas.
6.1.2 Proceso de Abastecimiento

d) el proveedor desarrolla un producto y/o servicio que cumple los requisitos acordados;
e) se entrega el producto y/o servicio al adquiriente de acuerdo con los requisitos
acordados y
f) se instala el producto de acuerdo con los requisitos acordados.
7.2.1 Proceso de Gestión de la Documentación del Software
a) se elabora una estrategia identificando la documentación que se ha de elaborar
durante el ciclo de vida del producto o servicio de software;
c) se identifica la documentación que el proceso o proyecto ha de elaborar;
e) se elabora la documentación y se la pone a disposición de acuerdo con los estándares
identificados.
[NTC 4243:2009 (ISO/IEC 12207:2008, 6.1.2, 7.2.1)]
16
IS.O7 Las Tareas de Verificación y Validación de todos los productos de trabajo se llevan a
cabo utilizando los criterios definidos para lograr la consistencia entre productos de entrada y
de salida en cada actividad. Los defectos son identificados y corregidos; los registros se
guardan en los Resultados de Verificación/Validación.
7.2.4 Proceso de Verificación del Software

a) se elabora e implementa una estrategia de verificación;
b) se identifican los criterios para la verificación de todos los productos de trabajo de
software requeridos;
c) se llevan a cabo las actividades requeridas de verificación;
d) se identifican y registran los defectos y
e) se ponen a disposición del cliente y otras partes involucradas los resultados de las
actividades de verificación.
7.2.5 Proceso de Validación del Software
a) se elabora e implementa una estrategia de validación;
b) se identifican los criterios para la validación de todos los productos de trabajo de
software requeridos;
c) se llevan a cabo las actividades requeridas de validación;
d) se identifican y registran los problemas;
f) se ponen a disposición del cliente y otras partes involucradas los resultados de las
actividades de validación.
[NTC 4243: 2009 (ISO/IEC 12207:2008, 7.2.4, 7.2.5)]
NOTA No se pretende que todas las actividades de verificación y todos los productos de trabajo sean puestos a
disposición del Cliente. Las verificaciones deben ser realizadas por individuos con libertad y autoridad en la
organización, para permitir evaluaciones objetivas e iniciar, efectuar, resolver y verificar la resolución del problema.
7.3 PRODUCTOS DE ENTRADA DE LA IS

Tabla 11. Productos de entrada de la IS
Nombre Fuente
Plan de Proyecto Gestión del Proyecto
Repositorio del Proyecto Gestión del Proyecto
7.4 PRODUCTOS DE SALIDA DE LA IS

Tabla 12. Productos de salida de la IS
Nombre Destino
Configuración del Software Gestión del Proyecto
• Especificación de Requisitos
• Diseño de Software
• Registro de Trazabilidad
• Componentes de Software
• Software
• Casos de Prueba y Procedimientos de Prueba
• Informe de Prueba
• Guía de Operación de Producto
• Documentación de Software del Usuario
• Documentación de Mantenimiento
Solicitud de Cambio Gestión del Proyecto
17
7.5 PRODUCTOS INTERNOS DE LA IS
Tabla 13. Productos internos de la IS Nombre
Nombre
Resultados de la Validación
7.6 ROLES INVOLUCRADOS EN LA IS

Tabla 14. Roles involucrados en la IS
Rol Abreviación
Cliente CLI
Analista AN
Diseñador DIS
Programador PR
Gerente del Proyecto GP
Líder Técnico LT
Equipo de Trabajo ET
7.7 DIAGRAMA DE IS
El siguiente diagrama muestra el flujo de información entre las actividades del Proceso de
Implementación de Software incluyendo los productos de trabajo relevantes y sus relaciones.
18
Figura 4. Diagrama del proceso de Implementación de Software
19
7.7.1 Actividades de la IS
El Proceso de Implementación de Software tiene las siguientes actividades:
- IS.1 Iniciación de la Implementación de Software
- IS.2 Análisis de Requisitos de Software
- IS.3 Diseño Arquitectónico y Detallado del Software
- IS.4 Construcción del Software
- IS.5 Integración y Pruebas de Software
- IS.6 Entrega del Producto
IS.1 Iniciación de la Implementación de Software (IS.O1)
La actividad de Iniciación de la Implementación de Software asegura que el Plan de Proyecto

establecido en la actividad de Planificación del Proyecto es cumplido por todo el Equipo de
Trabajo. La actividad brinda:
- Revisión del Plan de Proyecto por parte del Equipo de Trabajo para determinar la
asignación de tareas.
- Compromiso con el Plan de Proyecto por parte del Equipo de Trabajo y del Gerente de
Proyecto.
- Un ambiente de implementación establecido.
Tabla 15. Lista de tareas de la IS.1

GP IS.1.1 Revisión del Plan de Proyecto actual Plan de Proyecto Plan de Proyecto
LT con los miembros del Equipo de Trabajo [revisado]
ET para lograr un entendimiento común y
lograr su compromiso con el proyecto.
LT IS. 1..2 Configurar o actualizar el ambiente Plan de Proyecto
ET de implementación. [revisado]
IS.2 Análisis de Requisitos de Software (IS.02, IS.06, IS.07)
La actividad de Análisis de Requisitos de Software analiza los requisitos acordados del Cliente
y establece los requisitos de validación del proyecto. La actividad brinda:
- Obtención, análisis y especificación de los requisitos del Cliente.
- Acuerdo sobre los requisitos del Cliente.
- Verificación y validación de requisitos.
- Control de versiones de los productos de requisitos de software.

20

LT IS.2.1 Asignar Tareas a los miembros del Equipo Plan de Proyecto
ET de Trabajo de acuerdo con su rol, basado en el [revisado]
Plan de Proyecto actual. - Tareas
AN IS.2.2 Documentar o actualizar la Especificación Plan de Proyecto Especificación de
CLI de Requisitos. - Descripción del Requisitos
Identificar y consultar las fuentes de información Producto
(Cliente, usuarios, sistemas previos,
documentos, etc.) para obtener nuevos
requisitos.
Analizar los requisitos identificados para
determinar el Alcance y la viabilidad.
Generar o actualizar la Especificación de
Requisitos.
AN IS.2.3 Verificar y obtener la aprobación de la Especificación de Resultados de la
LT Especificación de Requisitos. Requisitos Verificación
Verificar la exactitud de la Especificación de Plan de Proyecto Especificación de
Requisitos, si es correcta y su consistencia con - Descripción del Requisitos [verificada]
la Descripción del Producto. Además, revisar Producto Solicitud de Cambio
que los requisitos sean completos, no ambiguos [iniciada]
y no contradictorios. Los resultados encontrados
se documentan en los Resultados de la
Verificación y las correcciones no se llevan a
cabo hasta que el documento es aprobado por el
AN. Si se requieren cambios significativos, iniciar
una Solicitud de Cambio.
CLI IS.2.4 Validar y obtener la aprobación de la Especificación de Resultados de la
AN Especificación de Requisitos Requisitos Validación
Validar que la Especificación de Requisitos [verificada] Especificación de
satisface las necesidades y las expectativas Requisitos
acordadas, incluyendo la facilidad de uso de la [validada]
interfaz de usuario. Los resultados encontrados
se documentan en los Resultados de la
Validación y las correcciones no se aplican hasta
que el documento sea aprobado por el CLI.
AN IS.2.5 Documentar la versión preliminar de la Especificación de *Documentación de
*Documentación de Software del Usuario o Requisitos Software del Usuario
actualizar el manual vigente, si es necesario. [validada] [preliminar]
AN IS.2.6 Verificar y obtener aprobación de la *Documentación de Resultados de la
LT *Documentación de Software del Usuario, en Software del Usuario Verificación
caso necesario. [preliminar] *Documentación de
Verificar la consistencia de la *Documentación Especificación de Software del Usuario
de Software del Usuario con la Especificación de Requisitos [preliminar, verificada]
Requisitos. Solicitud de Cambio
Los resultados encontrados se documentan en [iniciada]
los Resultados de la Verificación y las
correcciones no se aplican hasta que el
documento sea aprobado por el AN. Si se
requieren cambios importantes, debe iniciarse
una Solicitud de Cambio.
LT IS.2.7 Incorporar la Especificación de Requisitos Especificación de Configuración del Software
y la *Documentación de Software del Usuario a Requisitos [validado] - Especificación de
la Configuración del Software en las líneas base. *Documentación de Requisitos [validada,
Software del Usuario líneas base establecidas]
[preliminar, verificada] - *Documentación de
Software del Usuario
[preliminar, verificada,
líneas base establecidas]
* Opcional.
21
IS.3 Diseño Arquitectónico y Detallado del Software (IS.O3, IS.O6, IS.O7)
La actividad de Diseño Arquitectónico y Detallado del Software transforma los requisitos de

software en la arquitectura del sistema de software y en el diseño detallado del software. La
actividad brinda:
- Revisión del Plan de Proyecto por parte del Equipo de Proyecto para determinar la
- Diseño de la arquitectura del software, los Componentes de Software y las interfaces

asociadas.
- Diseño detallado de los Componentes de Software y las interfaces.
- Revisión de la Especificación de Requisitos por parte del Equipo de Trabajo.
- El Diseño del Software verificado y sus defectos corregidos.
- Casos de Prueba y Procedimientos de Prueba verificados para las pruebas de

integración.
- Trazabilidad de los requisitos de software con el Diseño del Software, Casos de Prueba
y Procedimientos de Prueba.
- Diseño de productos y documentos bajo el control de versiones.
NOTA La Arquitectura del Software y el Diseño Detallado pueden ser llevados a cabo de forma separada de
acuerdo con el cronograma del proyecto.

LT IS.3.1 Asignar Tareas a los miembros del Plan de Proyecto
AN Equipo de Trabajo de acuerdo con su rol, - Tareas
DIS basado en el Plan de Proyecto actual.
AN IS.3.2 Entender la Especificación de Especificación de

DIS Requisitos Requisitos [validada,
líneas base
establecidas]
AN IS.3.3 Documentar o actualizar el Diseño de Especificación de Diseño de Software
DIS Software. Requisitos Registro de Trazabilidad
Analizar la Especificación de Requisitos para [validada, líneas base
generar el diseño arquitectónico, su establecidas]
disposición en los subsistemas y los
Componentes de Software que definen las
interfaces internas y externas. Describir en
detalle la apariencia y el comportamiento de
la interfaz, basándose en la Especificación
de Requisitos de forma que los Recursos
para su implementación puedan ser
previstos.
Brindar el detalle de los Componentes de
Software y sus interfaces para permitir su
construcción en forma clara.
Generar o actualizar el Registro de
Trazabilidad.
Continúa…
22
Tabla 17. (Final)

AN IS.3.4 Verificar y obtener la aprobación del Diseño de Software Resultados de la
DIS Diseño de Software. Registro de Trazabilidad Verificación
Verificar si la documentación del Diseño de Especificación de Diseño de Software
Software es correcta, su viabilidad y si es Requisitos [verificado]
consistente con su Especificación de
Requisitos. Verificar que el Registro de [validada, líneas base Registro de Trazabilidad
Trazabilidad contiene las relaciones establecidas] [verificado]
adecuadas entre los requisitos y los Solicitud de Cambio
elementos del Diseño de Software. Los
[iniciada]
resultados obtenidos son documentados en
correcciones no se realizan hasta que el
documento sea aprobado por el DIS. Si se
requieren cambios significativos, debe
iniciarse una Solicitud de Cambio.
DIS IS.3.5 Establecer o actualizar los Casos de Especificación de Casos de Prueba y
Prueba y Procedimientos de Prueba para las Requisitos Procedimientos de Prueba
pruebas de integración basadas en la [validada, líneas base
Especificación de Requisitos y el Diseño de establecidas]
Software.
Diseño de Software
En caso de ser necesario, el Cliente puede
brindar datos de prueba. [verificada, líneas base
establecidas]
DIS IS.3.6 Verificar y obtener la aprobación de Casos de Prueba y Resultados de la
AN los Casos de Prueba y Procedimientos de Procedimientos de Prueba Verificación
Prueba. Especificación de Casos de Prueba y
Verificar la consistencia entre la Requisitos [validada, Procedimientos de Prueba
Especificación de Requisitos, el Diseño de líneas base establecidas] [verificados]
Software y los Casos de Prueba y Diseño de Software
Procedimientos de Prueba. Los resultados [verificado, líneas base
obtenidos se documentan en los Resultados establecidas]
de la Verificación y las correcciones no se
realizan hasta que el documento sea
aprobado por el AN.
DIS IS.3.7 Actualizar el Registro de Trazabilidad Casos de Prueba y Registro de Trazabilidad
incorporando los Casos de Prueba y Procedimientos de Prueba [actualizado]
Procedimientos de Prueba. [verificados]
Registro de Trazabilidad
[actualizado]
LT IS.3.8 Incorporar el Diseño de Software y el Diseño de Software Configuración del
Registro de Trazabilidad a la Configuración [verificado] Software
del Software como parte de las líneas base. - Diseño de Software
Casos de Prueba y
Incorporar los Casos de Prueba y Procedimientos de Prueba [verificado, líneas base
Procedimientos de Prueba al Repositorio del establecidas]
Proyecto. [verificados]
- Casos de Prueba y
Registro de Trazabilidad Procedimientos de
[verificado] Prueba [verificados]
- Registro de Trazabilidad
[verificado, líneas base
establecidas]
23
IS.4 Construcción del Software (IS.O4, IS.O6, IS.O7)
La actividad de Construcción del Software desarrolla el código y los datos del software a partir
del Diseño del Software. La actividad brinda:
- Revisión del Diseño del Software por parte del Equipo de Trabajo para determinar la
secuencia de construcción del software.
- Componentes de Software codificados y pruebas unitarias aplicadas.
- Trazabilidad entre los Componentes de Software y el Diseño del Software.

PR Equipo de Trabajo de acuerdo con su rol, - Tareas
basado en el Plan de Proyecto actual.
PR IS.4.2 Entender el Diseño de Software. Diseño de Software
establecidas]
PR IS.4.3 Construir o actualizar los Componentes Diseño de Software Componentes de Software
de Software basándose en la parte detallada [verificado, líneas base
del Diseño de Software. establecidas],
establecidas]
PR IS.4.4 Diseño o actualización de pruebas Componentes de Software Componentes de Software
unitarias y su aplicación para verificar que los [probados mediante
Componentes de Software implementan la pruebas unitarias]
parte detallada del Diseño de Software.
PR IS.4.5 Corregir los defectos encontrados Componentes de Software Componentes de Software
hasta que se logre que la prueba unitaria sea [probados mediante [corregidos]
exitosa (se alcanzan los criterios de salida). pruebas unitarias]
PR IS.4.6 Actualizar el Registro de Trazabilidad Componentes de Software Registro de Trazabilidad
incorporando Componentes de Software [corregidos] [actualizado]
construidos o modificados.
establecidas]
LT IS.4.7 Incorporar los Componentes de Componentes de Software Configuración del Software
Software y el Registro de Trazabilidad a la [corregidos] - Componentes de
Configuración del Software como parte de las Software [corregidos,
líneas base. Registro de Trazabilidad
líneas base
[actualizado] establecidas]
- Registro de
Trazabilidad
[actualizado, líneas
base establecidas]
24
IS.5 Integración y Pruebas de Software (IS.O5, IS.O6, IS.O7)
La actividad de Integración y Pruebas de Software asegura que los Componentes de Software

integrados satisfacen los requisitos de software. La actividad proporciona:
- Entendimiento de los Casos y Procedimientos de Prueba y el ambiente de integración.
- Componentes de Software integrados, defectos corregidos y resultados documentados.
- Trazabilidad de los requisitos y el diseño con el producto de software integrado.
- Documentos operativos y de software del usuario documentados y verificados.
- Líneas base del Software verificadas.

PR Equipo de Trabajo de acuerdo con su rol, - Tareas
PR IS.5.2 Entender los Casos de Prueba y Casos de Prueba y
Procedimientos de Prueba. Procedimientos de
Prueba [verificados]
Establecer o actualizar el ambiente de
prueba.
PR IS.5.3 Integrar el Software usando los Componentes de Software
Componentes de Software y actualizar los Software Casos de Prueba y
Casos de Prueba y Procedimientos de [corregidos, líneas base Procedimientos de Prueba
Prueba para las pruebas de integración, en establecidas]
caso de ser necesario.
Casos de Prueba y
Procedimientos de
Prueba
[verificados]
base establecidas]
PR IS.5.4 Realizar las pruebas de Software Software Software
CLI usando los Casos de Prueba y Casos de Prueba y [probado]
Procedimientos de Prueba para la Procedimientos de
integración y documentar los resultados en el Informe de Prueba
Prueba
Informe de Prueba.
PR IS.5.5 Corregir los defectos encontrados y Software [probado] Software
realizar pruebas de regresión hasta que se Informe de Prueba [corregido]
alcancen los criterios de salida.
Casos de Prueba y Informe de Prueba
Procedimientos de [defectos eliminados]
Prueba Registro de
Trazabilidad
[actualizada, líneas
base establecidas]
Continúa…
25
Tabla 19. (Final)

PR IS.5.6 Actualización del Registro de Software [corregido] Registro de Trazabilidad
Trazabilidad, si es necesario. Registro de Trazabilidad [actualizado]
base establecidas]
PR IS.5.7 Documentar la *Guía de Operación de Software [probado] *Guía de Operación de
Producto o actualizar la vigente, si es Producto
necesario.
PR IS.5.8 Verificar y obtener la aprobación de la *Guía de Operación de Resultados de la Verificación
DIS *Guía de Operación de Producto, si es Producto *Guía de Operación de
necesario (ver IS.5.7) Software [probado] Producto
Verificar la consistencia de la Guía de [verificada]
Operación de Producto con el Software. Los
resultados obtenidos se documentan en los
Resultados de la Verificación y las
documento es aprobado por el DIS.
AN IS.5.9 Documentar la *Documentación de Software *Documentación de Software
Software del Usuario o actualizar la vigente, [probado] del Usuario
si es necesario.
*Documentación de
[preliminar]
AN IS.5.10 Verificar y obtener la aprobación de *Documentación de Resultados de la Verificación
CLI la *Documentación de Software del Usuario, Software del Usuario *Documentación de Software
si es necesario (ver IS.5.9) Software del Usuario
Verificar la consistencia de la [probado] [verificada]
*Documentación de Software del Usuario con
el Software. Los resultados obtenidos se
documentan en los Resultados de la
Verificación y las correcciones no se realizan
hasta que el documento sea aprobado por el
CLI.
LT IS.5.11 Incorporar los Casos de Prueba y Casos de Prueba y Configuración del Software
Procedimientos de Prueba, Software, Procedimientos de - Casos de Prueba y
Registro de Trazabilidad, Informe de Prueba, Prueba Procedimientos de Prueba
*Guía de Operación de Producto y Software [líneas base establecidas]
*Documentación de Software del Usuario a la [probado] - Software [probado, líneas
Configuración del Software como parte de Informe de Prueba base establecidas]
las líneas base. Registro de Trazabilidad - Registro de Trazabilidad
[actualizado] [actualizado, líneas base
establecidas]
*Guía de Operación de
Producto - Informe de Prueba [líneas
base establecidas]
[verificada]
- *Guía de Operación de
*Documentación de Producto [verificada, líneas
Software del Usuario base establecidas]
[verificada] - *Documentación de
[verificada, líneas base
establecidas]
* Opcional
26
IS.6 Entrega del Producto (IS.O6, IS.O7)
La actividad de Entrega del Producto proporciona al Cliente un producto de software integrado.

La actividad brinda:
- Documentación de Mantenimiento verificada.
- Entrega del producto de software y documentación aplicable de acuerdo con las

Instrucciones de Entrega.

ET Equipo de Trabajo de acuerdo con su rol, - Tareas
DIS IS.6.2 Entender la Configuración del Configuración del Software
Software.
DIS IS.6.3 Documentar la Documentación de Configuración del Software Documentación de
Mantenimiento o actualizar la Mantenimiento
documentación vigente.
DIS IS.6.4 Verificar y obtener aprobación de la Documentación de Resultados de la Verificación
LT Documentación de Mantenimiento. Mantenimiento Documentación de
Verificar la consistencia de la Configuración del Software Mantenimiento
Documentación de Mantenimiento con la [verificada]
Configuración del Software. Los
resultados obtenidos se documentan en
documento sea aprobado por el LT.
LT IS.6.5 Incorporar la Documentación de Configuración del Software Configuración del Software
Mantenimiento como línea base de la Documentación de - Documentación de
Configuración del Software. Mantenimiento Mantenimiento [verificada,
[verificada] líneas base establecidas]
LT LT IS.6.6 Llevar a cabo la entrega de Plan de Proyecto Configuración del Software

acuerdo con las Instrucciones de Entrega. - Instrucciones de [entregada]
Entrega
Configuración del Software
7.7.2 Incorporación de la IS al Repositorio del Proyecto
La lista de productos a ser guardada en el Repositorio del Proyecto. Luego de la incorporación,

la Estrategia de Control de Versiones debe aplicarse a: la Especificación de Requisitos, el
Diseño del Software, el Registro de Trazabilidad, los Casos de Prueba y los Procedimientos de
Prueba, los Componentes del Software, el Software, la Guía de Operación del Producto, la
Documentación de Software del Usuario y la Documentación de Mantenimiento.
27
Tabla 21. Productos del repositorio de la IS
Producto
Especificación de Requisitos
Documentación de Software del Usuario
Diseño de Software
Casos de Prueba y Procedimientos de Prueba
Componentes de Software
Software
Guía de Operación de Producto
Documentación de Mantenimiento
Informe de Prueba
Resultados de la Validación
8. ROLES
Esta es una lista alfabética de los roles, sus abreviaciones y la descripción de las competencias
sugeridas. Por motivos de presentación, esta lista se muestra como una tabla de cuatro
columnas.
Tabla 22. Roles
Rol Abreviación Competencias

1. Analista AN Conocimiento y experiencia en la identificación, especificación y
análisis de requisitos.
Conocimiento sobre diseño de interfaces de usuario y sobre los
criterios ergonómicos.
Conocimiento sobre técnicas de revisión.
Conocimiento sobre técnicas de edición.
Experiencia en desarrollo y mantenimiento de software.
2. Cliente CLI Conocimiento de los procesos del Cliente y habilidad para explicar los
requisitos del Cliente.
El (representante del) Cliente debe tener la suficiente autoridad para
aprobar los requisitos y sus cambios.
El Cliente incluye representantes de los usuarios para asegurar que
el ambiente de operación sea tomado en consideración.
Conocimiento y experiencia en el dominio de aplicación.
3. Diseñador DIS Conocimiento y experiencia en el diseño de los Componentes de
Software y de la arquitectura.
Conocimiento y experiencia en la planificación y desempeño de las
pruebas de integración.
Conocimiento de técnicas de edición.
Continúa…
28
Tabla 22. (Final)
Rol Abreviación Competencias

4. Programador PR Conocimiento y/o experiencia en programación, integración y
pruebas unitarias.
Conocimiento sobre técnicas de edición.
5. Gerente del Proyecto GP Capacidad de liderazgo con experiencia en la toma de
decisiones, planificación, gestión de personal, delegación y
supervisión, finanzas y desarrollo de software.
6. Líder Técnico LT Conocimiento y experiencia en el dominio del proceso de
software.
7. Equipo de Trabajo ET Conocimiento y experiencia de acuerdo a sus roles en el
proyecto: LT, AN, DIS y/o PR.
Conocimiento sobre normas utilizadas por el Cliente y/o la PE.
9. DESCRIPCIÓN DEL PRODUCTO
Esta es una lista alfabética de los productos de entrada, salida y de procesos internos, sus
descripciones, posibles estados y fuentes del producto. La fuente puede ser otro proceso o una
entidad externa al proyecto, tal como el Cliente. Por motivos de presentación, esta lista se
muestra como una tabla de cuatro columnas. Los elementos de producto en las siguientes
tablas se basan en los Elementos de Información de la Norma ISO/IEC 15289, con algunas
excepciones.
Tabla 23. Descripciones del Producto
Nombre Descripción Fuente

1. Registro de Documenta la aceptación de los Entregables del proyecto por Gestión del
Aceptación parte del Cliente. Puede presentar las siguientes Proyecto
características:
- Registro de la recepción de la entrega
- Identifica la fecha de recibo
- Identifica los elementos entregados
- Registra la verificación de cualquier criterio de aceptación
definido del Cliente
- Identifica cualquier problema abierto (si aplica)
- Firma del Cliente que recibe
2. Solicitud de Identifica un problema o mejora deseada del Software o de la Implementación
Cambio documentación y solicita las modificaciones. Puede presentar de Software
las siguientes características: Cliente
- Identifica el propósito del cambio Gestión del
- Identifica el estado de la solicitud Proyecto
- Identifica la información de contacto del solicitante
- Sistema/s impactado/s
- Se encuentra definido el impacto sobre la operación de
sistemas existentes
- Se encuentra definido el impacto sobre la documentación
asociada
- Criticidad de la solicitud, fecha requerida
Los estados aplicables son: iniciada, evaluada y aceptada.
Continúa…
29
Tabla 23. (Continuación)

3. Registro de Identifica las actividades establecidas para corregir una Gestión del
Correcciones desviación o problema respecto al cumplimiento de un plan. Proyecto
Puede presentar las siguientes características:
- Identifica el problema inicial
- Define una solución
- Identifica acciones correctivas tomadas
- Identifica la propiedad para la realización de las acciones
definidas
- Identifica la fecha de apertura y la fecha de cierre objetivo
- Contiene un indicador de estado
- Indica acciones subsiguientes
4. Documentación Describe la Configuración del Software y los ambientes usados Implementación
de Mantenimiento para el desarrollo y las pruebas (compiladores, herramientas de Software
de diseño, construcción y pruebas). Puede presentar las
siguientes características:
- Incluye o refiere a todos los elementos de Configuración
del Software desarrollados durante la implementación
- Identifica los ambientes utilizados para desarrollo y
pruebas (compiladores, herramientas diseño,
construcción y herramientas de pruebas)
Se encuentra redactada en términos que puedan ser
entendidos por el personal de mantenimiento.
Los estados aplicables son: verificada y líneas base
establecidas.
5. Registro de Registra los acuerdos establecidos con el Cliente y/o el Equipo Gestión del
Reuniones de Trabajo. Puede presentar las siguientes características: Proyecto
- Propósito de la reunión
- Participantes
- Fecha y lugar donde se llevó a cabo
- Referencia a minutas anteriores
- Logros de la reunión
- Identifica problemas planteados
- Trata cualquier problema abierto
- Acuerdos
- Siguiente reunión, si se da el caso.
El estado aplicable es: actualizado.
6. Guía de Contiene la información necesaria para instalar y manejar el Implementación
Operación de Software. Puede incluir las siguientes características: de Software
Producto - Criterios de uso operativo
- Una descripción de cómo operar el producto, incluyendo:
- ambiente operativo requerido
- herramientas y material de soporte requeridos
(por ejemplo, manuales de usuario)
- posibles advertencias de seguridad
- preparación y secuencia de la puesta en marcha
- Preguntas Frecuentes (FAQ, por su sigla en inglés)
- fuentes de información y ayuda adicional para la
operación del producto
- Aprobaciones de certificación y seguridad
- Instrucciones de reemplazo y garantía
- Debe ser redactada en términos que el personal
responsable de la operación pueda entender.
Los estados aplicables son: verificada y líneas base
establecidas
30

7. Registro de Registros del estado del proyecto contra el Plan de Proyecto. Puede Gestión del
Estado de presentar las siguientes características: Proyecto
Progreso - Estado de Tareas reales contra las Tareas planificadas
- Estado de resultados reales contra los Objetivos / metas establecidos
- Estado de asignación real de recursos contra los Recursos
planificados
- Estado de costos reales contra las estimaciones de presupuesto
- Estado de tiempo real contra el cronograma planificado
- Estado de riesgos reales contra los riesgos identificados previamente
- Registro de cualquier desviación en las Tareas planificadas y las
razones de la desviación.
El estado aplicable es: evaluado.
8. Plan de Muestra cómo serán ejecutados los procesos y actividades del proyecto Gestión del
Proyecto para asegurar que el proyecto se completa exitosamente y asegurar la Proyecto
calidad de los productos entregados. Incluye los siguientes elementos que
pueden presentar características como las que se describen a
continuación:
- Descripción del Producto
- Propósito
- Requisitos Generales del Cliente
- Descripción del Alcance de lo que está incluido y lo que no
- Objetivos del proyecto
- Entregables - lista de productos a ser entregados al Cliente
- Tareas, incluyendo verificación, validación y revisiones con el Cliente y
el Equipo de Trabajo, para asegurar la calidad de los productos de
trabajo. Las Tareas pueden ser representadas como una Estructura
de Descomposición del Trabajo (EDT).
- Duración Estimada de las tareas
- Recursos (humanos, materiales, normativos, equipamiento y
herramientas) incluyendo la capacitación requerida y el cronograma
que indique cuándo son necesarios los Recursos.
- Composición del Equipo de Trabajo
- Cronograma de Tareas del Proyecto, las fechas de inicio y finalización
esperadas para cada tarea y las relaciones y dependencias de las
Tareas.
- Esfuerzo y Costo Estimados
- Identificación de los Riesgos del Proyecto
- Estrategia de Control de Versiones
- Herramientas o mecanismos de repositorio de producto identificados
- Ubicación y mecanismos de acceso para el repositorio especificado
- Identificación y control de versiones definidos
- Mecanismos de respaldo y recuperación definidos
- Mecanismos de almacenamiento, manipulación y entrega
(incluyendo archivo y recuperación) especificados
- Instrucciones de Entrega
- Elementos identificados requeridos para la liberación del producto
(p. e., hardware, software, documentación etc.)
- Requisitos de entrega
- Orden secuencial de las Tareas a ser realizadas
- Liberaciones aplicables identificadas
- Identifica todos los Componentes de Software entregados con la
información de la versión
- Identifica cualquier procedimiento necesario de respaldo y
recuperación
Los estados aplicables son: verificado, aceptado, actualizado y revisado.
31

9. Repositorio del Contenedor electrónico para almacenar por productos de trabajo y los Gestión del
Proyecto entregables del proyecto. Puede presentar las siguientes Proyecto
características:
- Almacena productos de trabajo del proyecto
- Almacena productos Entregables liberados
- Capacidad de almacenamiento y recuperación
- Habilidad para navegar por el contenido
- Listado de contenidos con la descripción de atributos
- Posibilidad de compartir y transferir productos de trabajo entre los
grupos afectados
- Control eficaz sobre el acceso
- Mantenimiento de las descripciones de los productos de trabajo
- Recuperación de versiones archivadas de productos de trabajo
- Habilidad para informar sobre el estado del producto de trabajo
- A los cambios a los productos de trabajo se les hace seguimiento
mediante una Solicitud de Cambios
Los estados aplicables son: recuperado y actualizado.
10. Respaldo del Repositorio usado como respaldo del Repositorio del Proyecto y, si Gestión del
Repositorio del fuera necesario, para recuperar información. Proyecto
Proyecto
11. Especificación Identifica los requisitos de software. Puede presentar las siguientes Implementa-
de Requisitos características: ción de
- Introducción - descripción general del Software y su uso dentro Software
del Alcance del negocio del Cliente;
- Descripción de requisitos:
- Funcionalidad - necesidades establecidas que deben ser
satisfechas por el Software cuando se utilice en condiciones
específicas. La Funcionalidad debe ser adecuada, precisa y
segura
- Interfaz de usuario - definición de aquellas características de
interfaz de usuario que permiten al usuario entender y aprender
fácilmente el Software para que pueda realizar sus Tareas
eficientemente incluyendo la descripción del modelo de interfaz
- Interfaces externas - definición de las interfaces con otro software
o hardware
- Confiabilidad - especificación del nivel de ejecución de software
respecto a la madurez, tolerancia a fallos y recuperación
- Eficiencia - especificación del nivel de ejecución de software con
respecto al tiempo y uso de los Recursos
- Mantenimiento - descripción de los elementos que facilitan el
entendimiento y ejecución de las modificaciones de Software
futuras
- Portabilidad - descripción de las características del Software que
permiten su transferencia de un lugar a otro.
- Limitaciones/restricciones de diseño y construcción - necesidades
impuestas por el Cliente
- Interoperabilidad - capacidad de dos o más sistemas o
Componentes de Software para intercambiar información entre sí
y utilizarla
- Capacidad de reutilización - aspecto de cualquier
producto/subproducto, o parte del mismo, de forma tal que pueda
ser usado por varios usuarios como producto final en el propio
desarrollo del software o en la ejecución de otro producto de
software
- Aspectos legales y reglamentarios - necesidades impuestas por
leyes, reglamentaciones, etc.
Cada requisito es identificado, único y es verificable o puede ser
evaluado.
Los estados aplicables son: verificada, validada y líneas base
establecidas.
32

12. Software Elementos de Software (código fuente y código ejecutable del Implementación
Software) para un Cliente, constituidos por un conjunto de de Software
Componentes de Software integrados.
Los estados aplicables son: probado y líneas base establecidas
13. Componentes Un conjunto de unidades de código relacionadas. Implementación
de Software Los estados aplicables son: probadas mediante pruebas unitarias, de Software
corregidas y líneas base establecidas.
14. Configuración Un conjunto que identifica de manera única y consistente productos Implementación
del Software de software incluyendo: de Software
- Especificación de Requisitos
- Diseño de Software
- Registro de Trazabilidad
- Componentes de Software
- Software
- Casos de Prueba y Procedimientos de Prueba
- Informe de Prueba
- Guía de Operación de Producto
- Documentación de Software del Usuario
- Documentación de Mantenimiento
Los estados aplicables son: entregada y aceptada.
15. Diseño de Información textual y gráfica sobre la estructura del Software. Esta Implementación
Software estructura puede incluir las siguientes partes: de Software
Diseño arquitectónico de alto nivel del software - Describe la
estructura general del Software:
- Identifica los Componentes de Software requeridos
- Identifica las relaciones entre Componentes de Software
- Deben considerarse cualquier:
- Características de desempeño de Software requerida
- Interfaces de hardware, software y humanas requeridas
- Características de seguridad requeridas
- Requisitos de diseño de la base de datos
- Atributos de manejo de errores y recuperación requeridos
Diseño detallado de bajo nivel del software - incluye detalles de los
Componentes de Software para facilitar su construcción y prueba
dentro del ambiente de programación:
- Brinda diseño detallado (puede ser representado como un
prototipo, diagrama de flujo, diagrama de relación de
entidades, pseudocódigo, etc.)
- Brinda los formatos de datos de entrada/salida
- Proporciona especificaciones de las necesidades de
almacenamiento de datos
- Establece las convenciones de denominación de datos
requeridas
- Define el formato de las estructuras de datos requeridas
- Define los campos de datos y los propósitos de cada elemento
de datos requerido
- Proporciona las especificaciones de la estructura del programa
Los estados aplicables son: verificado y líneas base establecidas.
33

16. Documentación Describe la forma en que se utiliza el Software basándose en la Implementación
de Software del interfaz de usuario. Puede presentar las siguientes características de Software
Usuario - Procedimientos de usuario para realizar las Tareas
especificadas utilizando el Software
- Procedimientos de instalación y desinstalación
- Breve descripción del uso previsto del Software (el concepto
de las operaciones)
- Los Recursos provistos y requeridos
- Ambiente de operación necesario
- Disponibilidad de informes de problemas y asistencia
- Procedimientos para acceder y salir del Software
- Lista y explica los comandos de Software y mensajes
provistos por el sistema al usuario
- Incluye advertencias, precauciones y notas con correcciones
de forma apropiada para los riesgos identificados
- Incluye procedimientos de solución de problemas y corrección
de errores.
Se encuentra redactado en términos entendibles para el usuario.
Los estados aplicables son: preliminar, verificada y líneas base
establecidas.
17. Declaración de Descripción del trabajo realizado relativo al desarrollo del Software. Cliente
Trabajo Puede incluir:
- Descripción del Producto
- Propósito
- Requisitos generales del Cliente
- Descripción del Alcance de lo que se incluye y lo que no
- Objetivos del proyecto
- Lista de productos Entregables a ser entregada al Cliente
El estado aplicable es: revisada.
18. Casos de Elementos necesarios para probar el código. Los Casos de Prueba Implementación
Prueba y pueden incluir: de Software
Procedimientos - Identificador del caso de prueba
de Prueba
- Elementos de prueba
- Especificaciones de entrada
- Especificaciones de salida
- Necesidades del ambiente
- Requisitos especiales de procedimiento
- Dependencias de las interfaces
Los Procedimientos de Prueba pueden incluir:
- Nombre de la prueba, descripción y fecha en la que será
completada
- Problemas potenciales de implementación identificados
- La persona que completó el procedimiento de prueba
- Prerrequisitos identificados
- Pasos de los procedimientos incluyendo el número de paso, la
acción requerida por quien realiza la prueba y los resultados
esperados
Los estados aplicables son: verificado y líneas base establecidas.
34
Tabla 23. (Final)

19. Informe de Documenta la ejecución de las pruebas. Puede incluir: Implementación
Prueba - Un resumen de cada defecto de Software
- El caso de prueba relacionado al defecto
- El encargado de pruebas que encontró cada defecto
- Severidad de cada defecto encontrado
- Funciones afectadas por cada defecto
- Fecha en la que se originó cada defecto
- Fecha en la que se resolvió cada defecto
- Persona que resolvió cada defecto
Los estados aplicables son: líneas base establecidas.
20. Registro de Documenta la relación entre los requisitos incluidos en la Implementación
Trazabilidad Especificación de Requisitos, los elementos del Diseño de Software, de Software
Componentes de Software, Casos de Prueba y Procedimientos de
Prueba. Puede incluir:
- Requisitos de la Especificación de Requisitos a los que debe
hacérseles seguimiento
- Brinda mapeo hacia delante y hacia atrás de los requisitos para
los elementos de Diseño de Software, los Componentes de
Software, los Casos de Prueba y Procedimientos de Prueba.
Los estados aplicables son: verificado, líneas base establecidas y
actualizado.
21. Resultados de Documenta la ejecución de la verificación. Puede incluir el registro Gestión del
la Verificación de: Proyecto
- Participantes Implementación
- Fecha de Software
- Lugar
- Duración
- Lista de verificación
- Elementos de verificación que pasaron exitosamente la misma
- Elementos de verificación que fallaron
- Elementos de verificación pendientes
- Defectos identificados durante la verificación
22. Resultados de Documenta la ejecución de la validación. Puede incluir el registro de: Implementación
la Validación - Participantes de Software
- Fecha
- Lugar
- Duración
- Lista de validación
- Elementos de validación que pasaron exitosamente la misma
- Elementos de validación que fallaron
- Elementos de validación pendientes
- Defectos identificados durante la validación
35
10. REQUISITOS DE HERRAMIENTAS DE SOFTWARE
Pueden utilizarse herramientas de software para llevar a cabo las actividades del proceso.
10.1 PROCESO DE GESTIÓN DE PROYECTOS
Tabla 24. Herramientas de gestión de proyectos
Actividad Lista de Recursos

Planificación de Proyecto Herramientas que permiten documentar,
Ejecución del Plan de Proyecto gestionar y controlar el Plan de Proyecto y el uso
y gestión del Repositorio del Proyecto
Evaluación y Control del Proyecto
Cierre del Proyecto
10.2 PROCESO DE IMPLEMENTACIÓN DE SOFTWARE
Tabla 25. Herramientas de Implementación de Software
Actividad Lista de Recursos

Inicio de la Implementación de Software Herramientas de documentación
Análisis de Requisitos de Software
Diseño Arquitectónico y Detallado del Software
Construcción del Software
Integración y Pruebas de Software
Entrega del Producto
Análisis de Requisitos de Software Herramientas de Especificación de Requisitos
Diseño Arquitectónico y Detallado del Software Herramientas de Diseño de Software
Construcción del Software Herramientas de construcción
Integración y Pruebas de Software Herramientas de pruebas, herramientas de rastreo de fallos
36
ANEXO A
(Informativo)
PAQUETES DE DESPLIEGUE
Se encuentran a disposición de las PEs un conjunto de Paquetes de Despliegue para facilitar la

implementación de un Perfil. Un paquete de despliegue es un conjunto de artefactos
desarrollados para facilitar la implementación de un conjunto de prácticas, del marco de trabajo
seleccionado, en una PE. Pero el paquete de despliegue no es un modelo de referencia de
procesos completo. No es la intención de los paquetes de despliegue evitar o desalentar el uso
de guías adicionales que las PEs consideren de ayuda.
Los elementos de un paquete de despliegue típico son: descripción técnica, relaciones con la
Norma ISO/IEC 29110, definiciones clave, descripción detallada de los procesos, actividades,
tareas, roles y productos, plantillas, listas de verificación, ejemplos, referencias y mapeo con
otras normas y modelos y una lista de herramientas. El mapeo sólo se proporciona a modo de
informativo para mostrar que el Paquete de Despliegue tiene un vínculo explícito con la Parte 5,
con Normas de ISO, tales como la Norma ISO/IEC 12207, o con modelos tales como CMMI,
desarrollado por el Software Engineering Institute. Por lo tanto, mediante el despliegue e
implementación de un paquete, una PE puede ver los pasos concretos para lograr o demostrar
que cubre la Parte 5. Los Paquetes de Despliegue son diseñados de forma tal que una PE
pueda implementar su contenido sin tener que implementar el marco de trabajo completo al
mismo tiempo. La tabla de contenidos de un paquete de despliegue se ilustra en la Tabla A.1.
Tabla A.1 Tabla de contenido de un paquete de despliegue
1. Descripción Técnica
Propósito de este documento
¿Por qué es importante este Tópico?
2. Definiciones
3. Relaciones con la Norma ISO/IEC 29110
4. Visión General de los Procesos, Actividades, Tareas, Roles y Productos
5. Descripción de Procesos, Actividades, Tareas, Pasos, Roles y Productos
Descripción del Rol
Descripción del Producto
Descripción del Artefacto
6. Plantilla/s
7. Ejemplo/s
8. Lista/s de Verificación
9. Herramienta/s
10. Referencias a Otras Normas y Modelos (p. e., ISO 9001, ISO/IEC 12207, CMMI)
11. Referencias
12. Formulario de Evaluación
Para el Perfil PE Básico, se encuentra disponible en Internet, sin costo alguno, un conjunto de
Paquetes de Despliegue:
a) Análisis de Requisitos
b) Diseño Arquitectónico y Detallado
37
c) Construcción y Pruebas Unitarias
d) Integración y Pruebas
e) Verificación y Validación
f) Control de Versiones
g) Gestión del Proyecto
h) Entrega del Producto
i) Auto-Evaluación
38
BIBLIOGRAFÍA
[1] NTC 4243:2009 (ISO/IEC 12207:2008), Ingeniería de Sistemas y de Software. Procesos

del ciclo de vida del software.
[2] NTC-ISO/IEC TR 29110-1, Ingeniería de Software. Perfiles de ciclo de vida para

pequeñas entidades (PEs). Parte 1: Visión general.
[3] ISO/IEC 15289:2006, Ingeniería de Sistemas y de Software. Contenido de los productos

de información de los procesos de ciclo de vida de sistemas y software.
(Documentación).
[4] ISO/IEC TR 29110-4-1, Ingeniería de Software. Perfiles de ciclo de vida para pequeñas
entidades (PEs). Parte 4-1: Especificaciones del perfil. Perfil del grupo genérico.
[5] Panorama de Pequeñas y Medianas Empresas y Espíritu Empresarial, edición 2005,

Organización para la Cooperación y el Desarrollo Económico, OCDE, París, 2005.
39

Ntcisoiectr 29110512

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ntcisoiectr 29110512

Cargado por

Copyright:

Formatos disponibles

NORMA TÉCNICA NTC-ISO/IEC TR

E: SOFTWARE ENGINEERING. LIFECYCLE PROFILES FOR

CORRESPONDENCIA: esta es una adopción idéntica (IDT)

DESCRIPTORES: ingeniería de software; perfiles; ciclo

Editada por el Instituto Colombiano de Normas Técnicas y Certificación (ICONTEC)

Prohibida su reproducción Editada 2014-12-19

El Instituto Colombiano de Normas Técnicas y Certificación, ICONTEC, es el organismo

La representación de todos los sectores involucrados en el proceso de Normalización Técnica

La norma NTC-ISO/IEC TR 29110-5-1-2 fue ratificada por el Consejo Directivo de 2014-12-10.

A continuación se relacionan las empresas que colaboraron en el estudio de esta norma a

GREEN SQA PROCESIX

Además de las anteriores, en Consulta Pública el Proyecto se puso a consideración de las

A Y S COMPUTADORES S.A. ILIMITADA INGENIERÍA DE SISTEMAS S.A.S.

ISO (Organización Internacional de Normalización) e IEC (Comisión Electrotécnica

En circunstancias excepcionales, cuando el comité técnico conjunto ha recolectado

- Parte 1: Visión General [Informe Técnico]

- Parte 2: Marco de trabajo y taxonomía

- Parte 3: Guía para la evaluación [Informe Técnico]

- Parte 4-1: Especificaciones de Perfil: Grupo de Perfiles Genéricos

Las Partes 4 y 5 de la Norma pueden ser desarrolladas para presentar nuevas

- Parte 4-m: Especificaciones de Perfil: Grupo de Perfil aaaaa

La industria del software reconoce el valor de las Pequeñas Entidades (PEs) en su

De acuerdo con el informe de Panorama de Pequeñas y Medianas Empresas y el Espíritu

Tabla 1. Público objetivo de la Norma ISO/IEC 29110

ISO/IEC29110 Título Público objetivo

La Norma NTC-ISO/IEC TR 29110-1 define los términos comunes del Conjunto de

La Norma ISO/IEC 29110-2 presenta los conceptos de Perfiles Normalizados de Ingeniería de

La norma NTC-ISO/IEC TR 29110-3 define las guías de evaluación de procesos y los

Figura 1. Serie ISO/IEC 29110

1.1 CAMPOS DE APLICACIÓN .........................................................................................1

1.2 PÚBLICO OBJETIVO ...................................................................................................1

2. REFERENCIAS NORMATIVAS ...................................................................................2

3. TÉRMINOS Y DEFINICIONES .....................................................................................2

4. CONVENCIONES Y TÉRMINOS ABREVIADOS.........................................................2

4.1 DENOMINACIONES, DIAGRAMACIÓN Y CONVENCIONES DE DEFINICIÓN .........2

4.2 TÉRMINOS ABREVIADOS ..........................................................................................3

5. VISIÓN GENERAL .......................................................................................................4

6. PROCESO DE GESTIÓN DE PROYECTOS (GP) .......................................................5

6.1 PROPÓSITO DE LA GP ...............................................................................................5

6.2 OBJETIVOS DE LA GP................................................................................................6

6.3 PRODUCTOS DE ENTRADA DE LA GP .....................................................................8

6.4 PRODUCTOS DE SALIDA DE LA GP .........................................................................8

6.5 PRODUCTOS INTERNOS DE LA GP ..........................................................................8

6.6 ROLES INVOLUCRADOS EN LA GP..........................................................................8

6.7 DIAGRAMA DE LA GP ................................................................................................8

7. PROCESO DE IMPLEMENTACIÓN DE SOFTWARE (IS) ........................................14

7.1 PROPÓSITO ...............................................................................................................14

7.2 OBJETIVOS DE LA IS ...............................................................................................15

7.3 PRODUCTOS DE ENTRADA DE LA IS ....................................................................17

7.4 PRODUCTOS DE SALIDA DE LA IS .........................................................................17

7.5 PRODUCTOS INTERNOS DE LA IS .........................................................................18

7.6 ROLES INVOLUCRADOS EN LA IS .........................................................................18

7.7 DIAGRAMA DE IS ......................................................................................................18

9. DESCRIPCIÓN DEL PRODUCTO .............................................................................29

10. REQUISITOS DE HERRAMIENTAS DE SOFTWARE ..............................................36

10.1 PROCESO DE GESTIÓN DE PROYECTOS .............................................................36

10.2 PROCESO DE IMPLEMENTACIÓN DE SOFTWARE ...............................................36

Figura 1. Serie ISO/IEC 29110 ...............................................................................................iii

Figura 2. Procesos de la guía del perfil básico....................................................................5

Figura 3. Diagrama del proceso de Gestión de Proyectos .................................................9

Figura 4. Diagrama del proceso de Implementación de Software ...................................19

Tabla 1. Público objetivo de la Norma ISO/IEC 29110 .........................................................ii